From nobody Mon Sep 2 09:58:16 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1B512013A; Mon, 2 Sep 2019 03:20:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1567419611; bh=TN3iHb+EQYzSlmqBMoOqMQP1nqHzWpyEvZapHTOYTHI=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=aqZg1R3jBvyzXwv1XZCOLmRl7I6YPixkPkLIYm7lqcrIDZtwWcuxXYWKuwMu2jkzX hhdYvY2DlUyRxTKgaX6XrOFwhmp1H48cAA3kXq2D2nhK/3KUDEKQBc4UE+GD1Fb8J6 dGrQxV6DsO93msW7o46uD+FcSz3V/86FQ4baFO7I= X-Mailbox-Line: From new-work-bounces@ietf.org Mon Sep 2 03:20:11 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1271512012A; Mon, 2 Sep 2019 03:20:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1567419611; bh=TN3iHb+EQYzSlmqBMoOqMQP1nqHzWpyEvZapHTOYTHI=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=aqZg1R3jBvyzXwv1XZCOLmRl7I6YPixkPkLIYm7lqcrIDZtwWcuxXYWKuwMu2jkzX hhdYvY2DlUyRxTKgaX6XrOFwhmp1H48cAA3kXq2D2nhK/3KUDEKQBc4UE+GD1Fb8J6 dGrQxV6DsO93msW7o46uD+FcSz3V/86FQ4baFO7I= 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 A3D9012012A for ; Mon, 2 Sep 2019 03:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, 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 JiCb_6F1MbPw for ; Mon, 2 Sep 2019 03:20:06 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (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 B92C7120073 for ; Mon, 2 Sep 2019 03:20:06 -0700 (PDT) Received: from [42.100.7.85] (helo=[192.168.1.4]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1i4jRM-0006h2-On for new-work@ietf.org; Mon, 02 Sep 2019 10:20:05 +0000 To: new-work@ietf.org From: xueyuan Message-ID: Date: Mon, 2 Sep 2019 18:20:01 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Mon, 02 Sep 2019 09:58:14 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Web Authentication Working Group (until 2019-09-30) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2019 10:20:14 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgV2ViIEF1 dGhlbnRpY2F0aW9uIFdvcmtpbmcgR3JvdXA6CiDCoCBodHRwczovL3d3dy53My5vcmcvMjAxOS8w OC93ZWJhdXRobi1wcm9wb3NlZC1jaGFydGVyLmh0bWwKCkFzIHBhcnQgb2YgZW5zdXJpbmcgdGhh dCB0aGUgY29tbXVuaXR5IGlzIGF3YXJlIG9mIHByb3Bvc2VkIHdvcmsKYXQgVzNDLCB0aGlzIGRy YWZ0IGNoYXJ0ZXIgaXMgcHVibGljIGR1cmluZyB0aGUgQWR2aXNvcnkKQ29tbWl0dGVlIHJldmll dyBwZXJpb2QuCgpXM0MgaW52aXRlcyBwdWJsaWMgY29tbWVudHMgdGhyb3VnaCAyMDE5LTA5LTMw IG9uIHRoZQpwcm9wb3NlZCBjaGFydGVyLiBQbGVhc2Ugc2VuZCBjb21tZW50cyB0bwpwdWJsaWMt bmV3LXdvcmtAdzMub3JnLCB3aGljaCBoYXMgYSBwdWJsaWMgYXJjaGl2ZToKIMKgIGh0dHA6Ly9s aXN0cy53My5vcmcvQXJjaGl2ZXMvUHVibGljL3B1YmxpYy1uZXctd29yay8KCk90aGVyIHRoYW4g Y29tbWVudHMgc2VudCBpbiBmb3JtYWwgcmVzcG9uc2VzIGJ5IFczQyBBZHZpc29yeQpDb21taXR0 ZWUgUmVwcmVzZW50YXRpdmVzLCBXM0MgY2Fubm90IGd1YXJhbnRlZSBhIHJlc3BvbnNlIHRvCmNv bW1lbnRzLiBJZiB5b3Ugd29yayBmb3IgYSBXM0MgTWVtYmVyIFsxXSwgcGxlYXNlIGNvb3JkaW5h dGUKeW91ciBjb21tZW50cyB3aXRoIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0 aXZlLiBGb3IKZXhhbXBsZSwgeW91IG1heSB3aXNoIHRvIG1ha2UgcHVibGljIGNvbW1lbnRzIHZp YSB0aGlzIGxpc3QgYW5kCmhhdmUgeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRp dmUgcmVmZXIgdG8gaXQgZnJvbSBoaXMKb3IgaGVyIGZvcm1hbCByZXZpZXcgY29tbWVudHMuCgpU aGUgV29ya2luZyBHcm91cCBpcyBhbHNvIGV4dGVuZGVkIHVudGlsIDMwIE9jdG9iZXIgMjAxOQp0 byBhY2NvbW1vZGF0ZSBmb3IgdGhlIGNoYXJ0ZXIgcmV2aWV3IHBlcmlvZC4KCklmIHlvdSBzaG91 bGQgaGF2ZSBhbnkgcXVlc3Rpb25zIG9yIG5lZWQgZnVydGhlciBpbmZvcm1hdGlvbiwgcGxlYXNl CmNvbnRhY3QgV2VuZHkgU2VsdHplciwgV2ViIEF1dGhlbnRpY2F0aW9uIFdHIFRlYW0gQ29udGFj dCwgYXQKPHdzZWx0emVyQHczLm9yZz4uCgpUaGFuayB5b3UsCgpYdWV5dWFuIEppYSwgVzNDIE1h cmtldGluZyAmIENvbW11bmljYXRpb25zCgpbMV0gaHR0cDovL3d3dy53My5vcmcvQ29uc29ydGl1 bS9NZW1iZXIvTGlzdAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCm5ldy13b3JrIG1haWxpbmcgbGlzdApuZXctd29ya0BpZXRmLm9yZwpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldy13b3JrCg== From nobody Mon Sep 2 19:58:58 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3046C1200CC; Mon, 2 Sep 2019 19:58:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Paul Wouters via Datatracker To: Cc: draft-klensin-idna-rfc5891bis.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Paul Wouters Message-ID: <156747952912.12965.18139183538869398923@ietfa.amsl.com> Date: Mon, 02 Sep 2019 19:58:49 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-klensin-idna-rfc5891bis-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2019 02:58:50 -0000 Reviewer: Paul Wouters Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document collects IDNA information from Errata's, external information such as ICANN, and some wisdom gathered since RFC 5891 was published and presents this set of information for operations of domains to make their domains more secure with respect to IDNA and its (ab)use. The Security Section is a clear summary that states the operators should really heed the advise of this document (and the documents references and updated) Issue: It seems the document asks for the IANA Consideration section to be removed. Instead, it should keep the Section but use the text along the lines of " This document has no IANA actions.". This helps people who are looking through various RFC's to find IANA considerations. Minor issues: I find the term "For-profit domain" very confusing as .pizza is a very much for profit domain. Normally, the terms "Generic domain" and "Brand domain" although I guess the latter is usually avoided in written text. While the term is described to mean a Generic Domain, I think it would be better to use Generic domain instead of For-profit domain. Registries choosing to make exceptions -- allow code points that recommendations such as the MSR do not allow -- should make such decisions only with great care and only if they have considerable understanding of, and great confidence in, their appropriateness. This paragraph seems really to say "Registries SHOULD NOT make exceptions" and seems a good place for some RFC 2119 wording. I find the term "registry" in this document confusing, as it could refer to an "IANA registry", "script registry" or "domain registry". Perhaps always spell this out to make the context clearer? Or alternatively, perhaps introduce the term Registry (with captial R) and use that to refer to domain registries. [ID.draft-klensin-idna-unicode-review] is in progress. Its status should be checked in conjunction with application of the present specification. I think this is meant as informational to the RFC Editor ? Perhaps these documents should go out as a cluster? Note I find some documents are references within [square brackets] but not all of them, even some RFC's are in brackets and others are not. Please make this consistent. The algorithm and rules of RFCs 5891 and 5892 missing xref's to the RFCs? registries SHOULD normally consult Either use "SHOULD" or "normally", not both? It's a little odd. to fully satisfy the mandate set out above Instead of mandate, which is a bit generic and confusing, why not refer to the mentioned "IAB guidance", which I think it is referring to ? may provide useful guidance. Remove the word "may" From nobody Tue Sep 3 00:00:42 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2845E12021D; Tue, 3 Sep 2019 00:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 Y3Y6CjEPBcB4; Tue, 3 Sep 2019 00:00:25 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 7A53C1201E4; Tue, 3 Sep 2019 00:00:25 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id x4so33415670iog.13; Tue, 03 Sep 2019 00:00:25 -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:content-transfer-encoding; bh=1xf+v81TeaD+Gg+FFVOjhg/jc2Y9NaL1OCMxJJPcNEU=; b=WM/XLBX6X6wS+c+ZkS+to3Ms/nJgw9fp1Q9xYxG0Xt/uGrmoc/QJd7yGilLXJOfq8t R7Zh+BaNk7tLbj9eQ+dqzZNHZ51PB5XWR+kO3X12VMMN7hSHWM+uf+cB9CKWlA+T8/Tl nPbyr/BuIdpVItdNHLNBfGPgj+CKz/5neT/9iOlnqib/3E1C9C6xvSv6djkZw061R4w+ q1JDmX22jOyF+gDWxC2u1ub0ZX1XSfv3k3BHFXznyj16QcdI+yt35dFZ+sJmEBkPJkKB yFuoOnYczI03TRHzGlnl4685pt7XCunjOPT53CHjdbQnPk0TyOt2ycBDIBRzv8A8TUQR pq8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1xf+v81TeaD+Gg+FFVOjhg/jc2Y9NaL1OCMxJJPcNEU=; b=MYL3L9VJD97tmTUs7x3CeI05jZDUH7d527wxiooyUCFATtCNJVeEbSaub4GoRJ4Mpf r7Q7175T8wm42dLTnbgnlB2Go/D65Ov25hHt7v+n9/RivmCLKLD9zy8Ux3RKYpCLCWkm 5oGluhcc4IU2dczZmI3bDj+n3M+z45/3MH2Hon1ZTZ+3XaHHfzBkSNmyd8aUW2J5As1s WgnvOS17DaFieyJj9ovpzAYEVso+tKPfknAr/gHxJnm/T2uKXK2D4Ozv22kTm1sthwLU Qhcwqh2mJXHBFnsyLDngFSG4og1tpTwT4bC+QoLgoIB7gcI29sPMj/MJevcNW4B3qxtl mPwg== X-Gm-Message-State: APjAAAUDBy0MSC5aEP/4j4WIbBMpIwTZVlEnIKaZ4Abvp4JJq2OuAqxt xvbGhXcq+VVzn3YSHtpu6RvbfLwsMwXfQ8X5spw= X-Google-Smtp-Source: APXvYqysMBsdei7s5RQyY2/2aTSFS8DO8OVAlYakAStEjFB5NFfzycuJtjEvLLGGlx8w+VCEXsdXmlje4ovItoICqF4= X-Received: by 2002:a6b:c38f:: with SMTP id t137mr3920168iof.137.1567494024497; Tue, 03 Sep 2019 00:00:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dhruv Dhody Date: Tue, 3 Sep 2019 12:29:48 +0530 Message-ID: To: Donald Eastlake Cc: "iesg@ietf.org" , draft-ietf-pce-stateful-path-protection.all@ietf.org, secdir , pce@ietf.org, Mahend Negi Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-pce-stateful-path-protection X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2019 07:00:27 -0000 Hi Donald, Thanks for your review. On Thu, Aug 29, 2019 at 8:21 PM Donald Eastlake wrote: > > I have reviewed this document as part of the Security Directorate's ongoi= ng effort to review all IETF documents being processed by the IESG. Docume= nt editors and WG chairs should treat these comments just like any other la= st call comments. > > The summary of the review is Almost Ready. > > This document specifies an extension to the stateful Path Computation Ele= ment Communication Protocol to associate two or more Label Switched Paths f= or the purpose of setting up path protection. > > This is not at all my area of expertise. The Security Considerations sect= ion primarily refers to the Security Considerations in existing RFCs and on= e draft, draft-ietf-pce-association-group (which is already in the RFC Edit= or queue). I think these references are pretty thorough and provide good se= curity coverage and advice with one possible exception. Given that this doc= ument specifies a new facility, it seems likely that a few narrow sentences= would be in order about the damage an adversary could cause by specificall= y monkeying with that new facility. > I see that authors have posted a new revision (-10) that has this sentence = - Adding a spurious protection LSP to the Path Protection Association group could give false sense of network reliability, which leads to issues when the working LSP is down and the protection LSP fails as well. https://tools.ietf.org/html/draft-ietf-pce-stateful-path-protection-10#sect= ion-7 Does this work for you? Thanks! Dhruv > Tiny nits: > In abstract and other places when referring to what this standards track = draft does: "describes" -> "specifies" or "defines" > Draft references draft-ietf-pce-association-diversity-08 when latest vers= ion is -09 > > 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) > 1424 Pro Shop Court, Davenport, FL 33896 USA > d3e3e3@gmail.com From nobody Tue Sep 3 11:17:19 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D088212023E; Tue, 3 Sep 2019 11:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 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_NONE=-0.0001, SPF_HELO_NONE=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 c6pBnF08Nm-e; Tue, 3 Sep 2019 11:17:03 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 1BBC712013D; Tue, 3 Sep 2019 11:17:03 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id u185so34279841iod.10; Tue, 03 Sep 2019 11:17:03 -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=uGCAiz4TAWOhAFpH19Kj+PJYDPle7to29PcMTBcRwPI=; b=hrn5Lx0SPMm8wHNNVoVnF78CTWLXuzCcEBHF3q2XH26Xm247EQtR05GR9/uG5EVEXp /WMeA67y1ARnvmpCGAuQaW6SJAc3SkjBPAgPXdix5dJuLFHy24qEhj8rDkYddyF7iZuH S6VrZ/2eOuZjv9+OiQFh0+WgVoUnMDU/cJ6EPzT7Ij59w1HhKvOS2YVqu4yE1BdwyUAd WtUxTJzXUPPd2y0tAR6IB1WLOh6r4BmyvYiXZ87W4Rhk25LxksMGvBH08hj3zQ/1J6T/ IW27S1rdnV7bhlpqGWEOiQtoPUO8zff8neN9ScvoVux64vbPOAeoyuhx1E+wS7PQcew7 Pf4Q== 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=uGCAiz4TAWOhAFpH19Kj+PJYDPle7to29PcMTBcRwPI=; b=s3z+RfssC1Xd2YdoTk5ZDoIDkkiesGXRiV6au5QipZy7wJOOfeLnWfkauHY9axqaYl LHC1/eH6XVDF5Tn63W9yprl7idS+sdy17Kz8lp3N6VVDME58nb4Zbo4W+kH2PsrAEPEy xHqO/IbC8yBNszxp31f7ZrKXfMr9medm3mbLPBaf1PZuCD6yVD3nZnIWovtOIwfUrfeN zPZS5yHY77JKDdAap2APTO/ntpc9aBPt6FIKsQBlOl0Ct8C07wGnxiMEXZ0WMJT3pS7l ZXbJ3jjEchR4n2wYXh9KIN0T2xoqAWFpgpzI0iOhe2oQN/DuuByD//bRRXg0l13d3ADe I9iA== X-Gm-Message-State: APjAAAUvxdQeFTb9GxWr3YnUF+JZ/3ZCEcpYDjAfx9a902Sp7vY5bk1L DODbT234Up1IU0JzS3NQOGul708uMu0XOiS2cLM= X-Google-Smtp-Source: APXvYqxh3bUaom6Nno9TddRePgOw4JS0A5j1dCDWp11mYW2mJi9YJfVsfl1EFIQToUx9XS2zOZ/cfJhA8+ShaavWN0U= X-Received: by 2002:a6b:6a15:: with SMTP id x21mr22248735iog.40.1567534622252; Tue, 03 Sep 2019 11:17:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Donald Eastlake Date: Tue, 3 Sep 2019 14:16:51 -0400 Message-ID: To: Dhruv Dhody Cc: "iesg@ietf.org" , draft-ietf-pce-stateful-path-protection.all@ietf.org, secdir , pce@ietf.org, Mahend Negi Content-Type: multipart/alternative; boundary="0000000000005525570591aa18e9" Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-pce-stateful-path-protection X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2019 18:17:05 -0000 --0000000000005525570591aa18e9 Content-Type: text/plain; charset="UTF-8" Hi, That change looks good to me. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com On Tue, Sep 3, 2019 at 3:00 AM Dhruv Dhody wrote: > Hi Donald, > > Thanks for your review. > > On Thu, Aug 29, 2019 at 8:21 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 summary of the review is Almost Ready. > > > > This document specifies an extension to the stateful Path Computation > Element Communication Protocol to associate two or more Label Switched > Paths for the purpose of setting up path protection. > > > > This is not at all my area of expertise. The Security Considerations > section primarily refers to the Security Considerations in existing RFCs > and one draft, draft-ietf-pce-association-group (which is already in the > RFC Editor queue). I think these references are pretty thorough and provide > good security coverage and advice with one possible exception. Given that > this document specifies a new facility, it seems likely that a few narrow > sentences would be in order about the damage an adversary could cause by > specifically monkeying with that new facility. > > > > I see that authors have posted a new revision (-10) that has this sentence > - > > Adding a spurious protection LSP > to the Path Protection Association group could give false sense of > network reliability, which leads to issues when the working LSP is > down and the protection LSP fails as well. > > > https://tools.ietf.org/html/draft-ietf-pce-stateful-path-protection-10#section-7 > > Does this work for you? > > Thanks! > Dhruv > > > > Tiny nits: > > In abstract and other places when referring to what this standards track > draft does: "describes" -> "specifies" or "defines" > > Draft references draft-ietf-pce-association-diversity-08 when latest > version is -09 > > > > Thanks, > > Donald > > =============================== > > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > 1424 Pro Shop Court, Davenport, FL 33896 USA > > d3e3e3@gmail.com > --0000000000005525570591aa18e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

That change looks good to me.
=

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 (cell)
=C2=A01424 P= ro Shop Court, Davenport, FL 33896 USA
=C2=A0d3e3e3@gmail.com

=
On Tue= , Sep 3, 2019 at 3:00 AM Dhruv Dhody <dhruv.ietf@gmail.com> wrote:
Hi Donald,

Thanks for your review.

On Thu, Aug 29, 2019 at 8:21 PM Donald Eastlake <d3e3e3@gmail.com> wrote:
>
> I have reviewed this document as part of the Security Directorate'= s ongoing effort to review all IETF documents being processed by the IESG.= =C2=A0 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 document specifies an extension to the stateful Path Computation = Element Communication Protocol to associate two or more Label Switched Path= s for the purpose of setting up path protection.
>
> This is not at all my area of expertise. The Security Considerations s= ection primarily refers to the Security Considerations in existing RFCs and= one draft, draft-ietf-pce-association-group (which is already in the RFC E= ditor queue). I think these references are pretty thorough and provide good= security coverage and advice with one possible exception. Given that this = document specifies a new facility, it seems likely that a few narrow senten= ces would be in order about the damage an adversary could cause by specific= ally monkeying with that new facility.
>

I see that authors have posted a new revision (-10) that has this sentence = -

=C2=A0 =C2=A0Adding a spurious protection LSP
=C2=A0 =C2=A0to the Path Protection Association group could give false sens= e of
=C2=A0 =C2=A0network reliability, which leads to issues when the working LS= P is
=C2=A0 =C2=A0down and the protection LSP fails as well.

https://tools.ietf.o= rg/html/draft-ietf-pce-stateful-path-protection-10#section-7

Does this work for you?

Thanks!
Dhruv


> Tiny nits:
> In abstract and other places when referring to what this standards tra= ck draft does: "describes" -> "specifies" or "d= efines"
> Draft references draft-ietf-pce-association-diversity-08 when latest v= ersion is -09
>
> 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=A0 Donald E. Eastlake 3rd=C2=A0 =C2=A0+1-508-333-2270 (cell)
>=C2=A0 1424 Pro Shop Court, Davenport, FL 33896 USA
>=C2=A0 d3e3e3@gma= il.com
--0000000000005525570591aa18e9-- From nobody Tue Sep 3 12:37:06 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E901200D5; Tue, 3 Sep 2019 12:36:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christian Huitema via Datatracker To: Cc: ietf@ietf.org, core@ietf.org, draft-ietf-core-senml-etch.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Christian Huitema Message-ID: <156753941202.21156.13374047126124906978@ietfa.amsl.com> Date: Tue, 03 Sep 2019 12:36:52 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-core-senml-etch-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2019 19:36:53 -0000 Reviewer: Christian Huitema Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The draft draft-ietf-core-senml-etch-05 defines new media types for the CoAP iPATCH, PATCH, and FETCH methods for resources represented with the SenML data model defined in RFC 8428. The security considerations appropriately refer to the general considerations of SenML. The document is ready. From nobody Tue Sep 3 14:48:22 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081161200B6; Tue, 3 Sep 2019 14:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 Jnx4OI03OWpc; Tue, 3 Sep 2019 14:47:30 -0700 (PDT) Received: from bsa2.jck.com (ns.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 0EF7F12002E; Tue, 3 Sep 2019 14:47:30 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1i5Ge8-000L3c-M4; Tue, 03 Sep 2019 17:47:28 -0400 Date: Tue, 03 Sep 2019 17:47:23 -0400 From: John C Klensin To: Paul Wouters , secdir@ietf.org cc: draft-klensin-idna-rfc5891bis.all@ietf.org, iesg@ietf.org, i18ndir@ietf.org Message-ID: <3B79ACC1CBCD8540E819481A@PSB> In-Reply-To: <156747952912.12965.18139183538869398923@ietfa.amsl.com> References: <156747952912.12965.18139183538869398923@ietfa.amsl.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [secdir] Secdir last call review of draft-klensin-idna-rfc5891bis-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2019 21:47:34 -0000 Paul, Noting the arrival of this review 4 1/2 days after the IETF Last Call nominally closed, and copying the IESG rather than the IETF list as a result... I also would have tried to write a shorter and less complete response had there been a week or so for any remaining issues or lack or clarify to be the subject of additional discussion. --On Monday, September 2, 2019 19:58 -0700 Paul Wouters via Datatracker wrote: > Reviewer: Paul Wouters > Review result: Has Nits > > I have reviewed this document as part of the security > directorate's ongoing effort to review all IETF documents > being processed by the IESG. These comments were written > primarily for the benefit of the security area directors. > Document editors and WG chairs should treat these comments > just like any other last call comments. > > This document collects IDNA information from Errata's, > external information such as ICANN, and some wisdom gathered > since RFC 5891 was published and presents this set of > information for operations of domains to make their domains > more secure with respect to IDNA and its (ab)use. > > The Security Section is a clear summary that states the > operators should really heed the advise of this document (and > the documents references and updated) > > Issue: > > It seems the document asks for the IANA Consideration section > to be removed. Instead, it should keep the Section but use the > text along the lines of " This document has no IANA > actions.". This helps people who are looking through various > RFC's to find IANA considerations. Until and unless the rules are changed to require IANA Considerations sections in all IETF Stream documents, this is a judgment call. Your preference is noted but at least this author believes that the omission of an essentially trivial statement is more helpful to many users then including it and keeps documents shorter. I note that we have several section titles, including one for Internationalization, that are routinely omitted if the document has nothing to say that would call for such a section. > Minor issues: > > I find the term "For-profit domain" very confusing as .pizza > is a very much for profit domain. Normally, the terms "Generic > domain" and "Brand domain" although I guess the latter is > usually avoided in written text. While the term is described > to mean a Generic Domain, I think it would be better to use > Generic domain instead of For-profit domain. "For-profit" was chosen after multiple discussions about the best term and was chosen, in part, because it is not in common use. IIR, we started with "public domain", a term that is widely used but, unfortunately, use inconsistently wrt definitions. I've personally never seen or heard "brand domain" used prior to your note but I travel in different circles than the domainer community. "Generic" does not work for several reasons. First, the term has been used since RFC 1591 and earlier to make the distinction at the top level from country-code domains (see https://www.iana.org/domains/root/db as an example) . If "sponsored" (a term ICANN started using around 2000) or "brand" are useful at the top level, they are presumably subsets of "generic". Second, to use your example, a "pizza" TLD is generic in the "not a ccTLD" sense, but not in others (I gather than there are places where a claim that something was a "generic pizza" would be considered culturally offensive). In the interest of time and space, I won't go on much further, but remember that this document, like all of the IDNA core documents, is intended to be applicable to every zone in the DNS, not just the root or maybe the behavior of TLDs vis-a-via the names they allocate or delegate. The main point of this document, the relevant text in the base IDNA documents, and some of the language in RFC 1591 is that registries (a term that comes from early DNS documents is that is repeated in RFC 1591, and that appears in RFC 8499) are responsible for whatever strings they register and that they should take that responsibility seriously. For IDN purposes and in the core IDNA documents, that statement took the form of "if you don't understand the implications of a particular string, including the writing system implications, don't allow it". While rarely explicit, that rule is followed in an overwhelming fraction of the zones in the DNS. Most enterprise and organization zones allocate subdomains using names and terms (or abbreviations for them) that make sense to them. They are doing the right thing and don't need this I-D or the language in the base IDNA documents to tell them to do that or help with it. The problems mostly seem to occur in domains (gTLD, ccTLD, and deeper in the tree alike) that are dependent on the number of domains they sell for their income and support. Probably because they have incentives to sell more and more names that a registry that is operated as a public service or on a strict cost recovery basis typically does not, the former groups have far less incentive to push boundaries. Again the offenders include both traditional ccTLDs, traditional gTLDs, and many or most of the "new TLDs" created by ICANN in recent years as well as some situations deeper in the tree -- not all of them, clearly, but some. So, for any zone that naturally behaves as the documents being updated by this one specify, i.e., that doesn't delegate anything the registry doesn't understand thoroughly, this document is a non-issue. It is important for domains that don't intend to follow that guidance but who intend to register IDNs anyway. This is guidance primarily for them and to keep them and the Internet out of horrible trouble, and "for-profit" is the closest we could get. And, before you ask, we didn't say that in so many words because we are aware that the boundaries are not absolute and we didn't want to be over-broad. If you have better suggestions about terminology, they would be welcome... at least as long as they do not result in delaying processing and approval of this document. > Registries choosing to make exceptions -- allow code points > that recommendations such as the MSR do not allow -- should > make such decisions only with great care and only if they > have considerable understanding of, and great confidence in, > their appropriateness. > > This paragraph seems really to say "Registries SHOULD NOT make > exceptions" and seems a good place for some RFC 2119 wording. While the language was a compromise -- Asmus is inclined to be somewhat more restrictive and directive than I am -- "SHOULD NOT" is definitely not appropriate. One of my favorite examples, and one that came up several times in the discussions leading to IDNA2008, has to do with characters from archaic scripts. IDNA2008, after long discussion, allows them. ICANN won't allow them in the root (for good reason) and discourages them at the second level (also for good reason, although it is more controversial) and hence they are not in the MSR. But, if one had a museum or academic department with a specialty in those scripts or the languages and cultures with which they are associated, subdomains with those characters might make perfectly good sense (and the "understand what you register" requirement is probably easily met). > I find the term "registry" in this document confusing, as it > could refer to an "IANA registry", "script registry" or > "domain registry". Perhaps always spell this out to make the > context clearer? Or alternatively, perhaps introduce the term > Registry (with captial R) and use that to refer to domain > registries. See above. > [ID.draft-klensin-idna-unicode-review] is in progress. Its > status should be checked in conjunction with application of > the present specification. > > I think this is meant as informational to the RFC Editor ? > Perhaps these documents should go out as a cluster? Yes, it is informational to the RFC Editor. And, yes, it is not an accident that the two documents went out for Last Call at the same time and are being evaluated concurrently. My hope is to see both to them in the RFC Editor's hands at the same time, whether they are explicitly handled as a cluster or not. > Note I find some documents are references within [square > brackets] but not all of them, even some RFC's are in brackets > and others are not. Please make this consistent. I think you will find that all documents are cited (with the square brackets) at least once. After many discussions over the years with the RFC Editor, subsequent mentions of the same document are not handled as citations if that would make the text awkward (in the opinion of the authors). The RFC Editor certainly has the right to dispute those choices during their editing pass. If you have identified references to documents that do no appear in citations at all, please tell us about them and they will be fixed. If you are disputing the policy, take it up with the RFC Editor. On checking on your comment, I did catch one instance of a reference in square bracket that was not properly set up as a citation. It is now fixed in the working version but, unless the AD directs otherwise, I'm not going to repost for this rather trivial problem that I'm confident the RFC Editor would have caught. > The algorithm and rules of RFCs 5891 and 5892 > > missing xref's to the RFCs? Nope. Cited with xrefs in the same section, two paragraphs earlier. See above. > registries SHOULD normally consult > > Either use "SHOULD" or "normally", not both? It's a little odd. This document is a little odd in the sense that, in a more perfect world, it should be completely unnecessary. If there were greater understanding of and consensus about the issues associated with IDNs in the various communities that want to use them and will encounter them, we would not be bothering with it (much of that is explained above). In particular, the IETF usually avoids publishing documents that say "you MUST do X, but, if you don't, then you SHOULD do Y or Z. But that is precisely the position this document is in with MUST language in the base IDNA RFCs that a number of registries have chosen to ignore for business or other reasons. Given that, language that is "a little odd" is probably predictable. > to fully satisfy the mandate set out above > > Instead of mandate, which is a bit generic and confusing, why > not refer to the mentioned "IAB guidance", which I think it is > referring to ? Because it isn't referring to the IAB guidance or, more specifically, is referring to parts of it and some other things. Suggested better language would be welcome, again subject to the request/ suggestion above. > may provide useful guidance. > Remove the word "may" "may" was intentional. Those documents are completely irrelevant if one of the script or language-specific RFCs are considered. Whether the MSR is relevant or not below the root or in a zone for which ICANN does not have authority is controversial. If everyone agreed that it was relevant, this document could be replaced by something much shorter that would say "regardless of what IDNA allows, no characters or character sequences are permitted unless they exclusively use one of the scripts that ICANN has considered as part of the VIP/ LGR process and by the MSR and other ICANN recommendations and rules that derive from that process". But, for a number of reasons including those that are at least hinted at above, there is no such agreement, From nobody Wed Sep 4 07:38:12 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA408120019; Wed, 4 Sep 2019 07:38: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, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 EGyD_qpw0wFX; Wed, 4 Sep 2019 07:38:08 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 68D4E12000F; Wed, 4 Sep 2019 07:38:08 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46NmdV44MKzFhW; Wed, 4 Sep 2019 16:38:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1567607886; bh=gHBA4o/YIoW5bJSI7x19cw1Vu7YaPqihCM3B06jNMl0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ZNL4c6xS1g09rdayUbml+BxRsCSBYAhdQEn9QPEN0aMpXeRmFSevwUmiBB40W91qZ rP9Mg6UbHuurQGRO39N0rRa1IrW+JUPA+RFhZWgpgfiyAJo13DTtcnrhWgOcTEpv10 JIEnXoIMXxgx0Pbzype1un3B90mDUAkW1MhYIILw= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id wH8xIQmwoccM; Wed, 4 Sep 2019 16:38:04 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 4 Sep 2019 16:38:03 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 047EF353A37; Wed, 4 Sep 2019 10:38:01 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 047EF353A37 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id F0FC540267F9; Wed, 4 Sep 2019 10:38:01 -0400 (EDT) Date: Wed, 4 Sep 2019 10:38:01 -0400 (EDT) From: Paul Wouters To: John C Klensin cc: secdir@ietf.org, draft-klensin-idna-rfc5891bis.all@ietf.org, iesg@ietf.org, i18ndir@ietf.org In-Reply-To: <3B79ACC1CBCD8540E819481A@PSB> Message-ID: References: <156747952912.12965.18139183538869398923@ietfa.amsl.com> <3B79ACC1CBCD8540E819481A@PSB> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [secdir] Secdir last call review of draft-klensin-idna-rfc5891bis-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2019 14:38:11 -0000 On Tue, 3 Sep 2019, John C Klensin wrote: > Subject: Re: Secdir last call review of draft-klensin-idna-rfc5891bis-05 [ Only addressing the document review items in this email, not the SecDir review process ] >> Issue: >> >> It seems the document asks for the IANA Consideration section >> to be removed. Instead, it should keep the Section but use the >> text along the lines of " This document has no IANA >> actions.". This helps people who are looking through various >> RFC's to find IANA considerations. > > Until and unless the rules are changed to require IANA > Considerations sections in all IETF Stream documents, this is a > judgment call. Your preference is noted but at least this > author believes that the omission of an essentially trivial > statement is more helpful to many users then including it and > keeps documents shorter. I understand it is a matter of preference. I find it takes me less time to go through the document's Table of Contents to find the IANA Section that says "nothing to see here, move along" than it is for me to try and find the non-existing IANA Section. >> Minor issues: >> >> I find the term "For-profit domain" very confusing as .pizza >> is a very much for profit domain. Normally, the terms "Generic >> domain" and "Brand domain" although I guess the latter is >> usually avoided in written text. While the term is described >> to mean a Generic Domain, I think it would be better to use >> Generic domain instead of For-profit domain. > > "For-profit" was chosen after multiple discussions about the > best term and was chosen, in part, because it is not in common > use. Okay. Again personally, I think as a person who has spend time in IETF and ICANN that this term is less clear, but if the WG and author has spent considerable time on this discussion already, then there is no need to revisit this based on my single added opinion. >> Registries choosing to make exceptions -- allow code points >> that recommendations such as the MSR do not allow -- should >> make such decisions only with great care and only if they >> have considerable understanding of, and great confidence in, >> their appropriateness. >> >> This paragraph seems really to say "Registries SHOULD NOT make >> exceptions" and seems a good place for some RFC 2119 wording. > > While the language was a compromise -- Asmus is inclined to be > somewhat more restrictive and directive than I am -- "SHOULD > NOT" is definitely not appropriate. If this has been discussed and the result of a compromise, again my one voice shouldn't matter anymore in this case so feel free to leave as is. Although personally I do think you could have used "SHOULD NOT" followed by a "MAY" to give this a little more weight (especially as the document talks about outsiders/implementors getting things wrong). But this is not important enough to re-open an old discussion. >> I find the term "registry" in this document confusing, as it > See above. Same here, that's fine. >> [ID.draft-klensin-idna-unicode-review] is in progress. Its >> status should be checked in conjunction with application of >> the present specification. >> >> I think this is meant as informational to the RFC Editor ? >> Perhaps these documents should go out as a cluster? > > Yes, it is informational to the RFC Editor. And, yes, it is not > an accident that the two documents went out for Last Call at the > same time and are being evaluated concurrently. My hope is to > see both to them in the RFC Editor's hands at the same time, > whether they are explicitly handled as a cluster or not. Good. >> Note I find some documents are references within [square >> brackets] but not all of them, even some RFC's are in brackets >> and others are not. Please make this consistent. > > I think you will find that all documents are cited (with the > square brackets) at least once. After many discussions over the > years with the RFC Editor That's fine then too. I personally prefer to have it clickable, so if at the third time of an RFC being mentioned I go like "okay, I should really read this" and I can click on it on that 3rd instance. But I also understand the document shouldn't become a Christmas tree of links. > On checking on your comment, I did catch one instance of a > reference in square bracket that was not properly set up as a > citation. It is now fixed in the working version but, unless > the AD directs otherwise, I'm not going to repost for this > rather trivial problem that I'm confident the RFC Editor would > have caught. That's fine, thanks. >> registries SHOULD normally consult >> >> Either use "SHOULD" or "normally", not both? It's a little odd. > > This document is a little odd in the sense that, in a more > perfect world, it should be completely unnecessary. For me as a programmer, I prefer to read SHOULDs followed by MAY to relay these kind of "should normally do X". It is just more formal and thus easier for implementers to follow programatically. But again, if this has seen lots of discussion already, please feel free to leave as is. >> to fully satisfy the mandate set out above >> >> Instead of mandate, which is a bit generic and confusing, why >> not refer to the mentioned "IAB guidance", which I think it is >> referring to ? > > Because it isn't referring to the IAB guidance or, more > specifically, is referring to parts of it and some other things. > Suggested better language would be welcome, again subject to the > request/ suggestion above. Now this does seem like a real issue. After reading it a few times, I included that "mandate" meant the IAB guidance, and now you are telling me it actually does not. So that just confirms the use of "the mandate set out above" is actually not at all clear and should be clarified. > >> may provide useful guidance. > > >> Remove the word "may" > > "may" was intentional. Okay. So in conclusion, all my comments/questions are addressed, except for the mandate issue. It is not big enough to block the document for, but I think it would be useful to clarify further. Paul From nobody Wed Sep 4 08:57:27 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8B012087A; Wed, 4 Sep 2019 08:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0XeUdhhOR0n; Wed, 4 Sep 2019 08:57:10 -0700 (PDT) Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) (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 1F5C612086C; Wed, 4 Sep 2019 08:57:10 -0700 (PDT) Received: by mail-io1-f43.google.com with SMTP id r4so30056175iop.4; Wed, 04 Sep 2019 08:57:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qIzstm2qvV2tIE3iH+ab+Joh8g+3W8Gy28UVCVgzAZ0=; b=gmz2Zfof7sSI7m/ba6F8YkFie79eY1H4+FKF2vqd7dIOB9c8JwgKG9PsMQAsnC9jMa 4pXpGKQteeeY/i2/xZXb3c9kSpa8v8llZQ/rSoYu1mmGyHR4T+E2VQ3q33b4uOAYJnt8 cnbUFvb+p6mYEo9LDTt86yfMGP9Nq7tgvSdNtUDtK561BQpeMCd792jddMFOYznGXNxm /e8fsFLf7OXRIjBHMI3bN5+bXdXID8ZTtmUqwBLkHpSQaKEUg1TQM4mwDscPuC+gJoyo ZtRujLmbAbDiNnvXvK8OTqMSByMdayz48EdW45/bjp55er1xkeDEHTcf7XCX7n5RGj8k Fo4A== X-Gm-Message-State: APjAAAWMMVK11GF3SOfmr1t1Vot3W74jauodZb5QfztYmeGYyW0ESkvQ 4NAQBiymllhDnSU3RFj5jT3GPKzkIfhLkj+xtQQ= X-Google-Smtp-Source: APXvYqw4sp7v+2OBBjC7Exttnt38YokQfICYrD0NGSL9T9ePXLCrXwWcTWhl1dgJd6yqtsoLClOqg8ZMgGeROe/uDU8= X-Received: by 2002:a5d:9b96:: with SMTP id r22mr3564855iom.17.1567612629024; Wed, 04 Sep 2019 08:57:09 -0700 (PDT) MIME-Version: 1.0 References: <156747952912.12965.18139183538869398923@ietfa.amsl.com> <3B79ACC1CBCD8540E819481A@PSB> In-Reply-To: From: Barry Leiba Date: Wed, 4 Sep 2019 11:56:57 -0400 Message-ID: To: Paul Wouters Cc: John C Klensin , IETF SecDir , draft-klensin-idna-rfc5891bis.all@ietf.org, IESG , i18ndir@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-klensin-idna-rfc5891bis-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2019 15:57:12 -0000 Hi, Paul, and let me add my thanks for your careful review of a rather esoteric document. Just on two points, and generalizing them: > >> Note I find some documents are references within [square > >> brackets] but not all of them, even some RFC's are in brackets > >> and others are not. Please make this consistent. > > > > I think you will find that all documents are cited (with the > > square brackets) at least once. After many discussions over the > > years with the RFC Editor > > That's fine then too. I personally prefer to have it clickable, so > if at the third time of an RFC being mentioned I go like "okay, I > should really read this" and I can click on it on that 3rd instance. > But I also understand the document shouldn't become a Christmas tree > of links. This has come up often. As a text style thing, I know that John prefers not to have the citation as part of the text. It's the difference between "As [RFC5891] says, ...," and "As the IDNA Protocol [RFC5891] says, ...." I mostly agree with John on this, from a stylistic point of view, but accept (and even embrace) the reality that many people like the former. But style aside, Paul, your issue is more about convenience to the reader, and that's an important thing. Clearly, there's no direct difference, simply from a "reading the text" angle, between "RFC 5891" and "[RFC5891]". This is, therefore, an issue of tooling. If we should change the HTML rendering so that "RFC 5891" or "RFC5891" were as readily clickable as "[RFC5891]", this would simply not be a problem, right? Assuming that, I think I will have a conversation with the tools team: we should just do it. > >> registries SHOULD normally consult > >> > >> Either use "SHOULD" or "normally", not both? It's a little odd. > > > > This document is a little odd in the sense that, in a more > > perfect world, it should be completely unnecessary. > > For me as a programmer, I prefer to read SHOULDs followed by MAY > to relay these kind of "should normally do X". It is just more > formal and thus easier for implementers to follow programatically. > But again, if this has seen lots of discussion already, please > feel free to leave as is. Yes, lots of discussion, yes, we'll leave it as it is for this case. But... In the general case, I actually rail *against* "SHOULD X, but MAY Y", because I think they're contradictory: doing Y is not an entirely optional choice (and MAY is too flaky anyway, and doesn't work here). My strong preference is for using the following: - MUST do X unless , in which case MUST do Y. - MUST do X unless , in which case SHOULD do Y. - MUST do X unless , in which case implementations generally do Y. - SHOULD do X. I note that in the last case, you already have an out, if you have a good reason not to do X and understand the interoperability or security implications. But I think that most SHOULDs ought to include an explanation of why it's "SHOULD" (and not MAY or MUST), what the implications are, and what is done otherwise. That explanation doesn't need to have BCP 14 key words in it, and it probably detracts from it if it does, at least much of the time. Perhaps an exception to that last is if there are only, say, two options, and one is strongly preferred from an interoperability/security point of view. Then, "SHOULD do X, but if you don't do X you MUST do Y." Or maybe "MUST do X or Y, and SHOULD do X." (BTW, I also think that "MAY do X" is useful only in certain circumstances. It's useful to alert one side that something might happen that could otherwise be unexpected ("The server MAY close the connection without warning."), and for clarity in certain situations ("The client MAY include multiple instances of X."). It's not good for things like, "The client MAY set the FARBLE bit to indicate that it is farbling." Well, yes, one presumes that's what the FARBLE bit is for.) Barry From nobody Thu Sep 5 03:20:27 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5C1120090 for ; Thu, 5 Sep 2019 03:20:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <156767882656.22674.16642599597561222616.idtracker@ietfa.amsl.com> Date: Thu, 05 Sep 2019 03:20:26 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2019 10:20:27 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-09-05 Reviewer LC end Draft David Waltermire 2019-08-07 draft-ietf-oauth-jwt-introspection-response-07 Brian Weis 2019-08-05 draft-ietf-oauth-resource-indicators-05 For telechat 2019-09-19 Reviewer LC end Draft Leif Johansson 2019-09-02 draft-ietf-tls-sni-encryption-05 Stephen Kent 2019-09-17 draft-ietf-cbor-sequence-01 Christopher Wood 2019-08-30 draft-klensin-idna-unicode-review-03 Last calls: Reviewer LC end Draft Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Daniel Gillmor 2019-08-27 draft-ietf-lsr-isis-rfc5306bis-05 Daniel Gillmor 2018-03-19 draft-gutmann-scep-14 Steve Hanna 2019-09-05 draft-ietf-cbor-array-tags-07 Dan Harkins 2019-09-03 draft-ietf-pim-reserved-bits-03 Scott Kelly 2019-09-18 draft-ietf-dnsop-obsolete-dlv-00 Watson Ladd 2019-09-17 draft-ietf-stir-oob-05 Chris Lonvick 2019-09-14 draft-ietf-sipcore-callinfo-spam-04 Aanchal Malhotra 2019-09-13 draft-ietf-teas-native-ip-scenarios-08 David Mandelberg 2019-09-12 draft-ietf-sipcore-digest-scheme-08 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Sandra Murphy 2019-07-08 draft-ietf-i2nsf-applicability-17 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Tim Polk 2019-08-01 draft-ietf-acme-star-08 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Next in the reviewer rotation: Catherine Meadows Alexey Melnikov Daniel Migault Matthew Miller Adam Montville Kathleen Moriarty Russ Mundy Sandra Murphy Yoav Nir Magnus Nystrom From nobody Thu Sep 5 03:53:51 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC60B1200C1; Thu, 5 Sep 2019 03:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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=infineon.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 uFEeLlU0lR7b; Thu, 5 Sep 2019 03:53:48 -0700 (PDT) Received: from smtp11.infineon.com (smtp11.infineon.com [IPv6:2a00:18f0:1e00:4::5]) (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 38029120090; Thu, 5 Sep 2019 03:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=infineon.com; i=@infineon.com; q=dns/txt; s=IFXMAIL; t=1567680819; x=1599216819; h=from:to:subject:date:message-id:mime-version; bh=xTKbObe90ak1BHn8Wua6RyElsR2djWb8bxtu5TLqH1Y=; b=boruG2zQiWRJRGvB1CaqS3LiktYf6Sju4QlYe4YOE4l6gF2cd5VUttdb Xc9I31uxQ8B/NNiG6F4S7hABWJJX/I+4aEi2j4f010ogC77c6B7J0/Agy iK+qh1XQrOc4n2AmTcxhtaA1QDnr8yOfoc8bxxi/NpieBV4MrL2jfIIo3 4=; IronPort-SDR: oDo47oB9jKr/WlHVQWYopELv48XeS7rsmMYNfEfaYWECcKYH4ZNfU5hohw7cVw5TS/5hrBz59y 6tefWt86lTQdvJf+TofpOuNvoI2bJMatDtG3j5Ak6xWq5M+QTizgnJHg1NX5/i7/7ut99ii30w mfSZLdjTjDeCesoavYxp+Htr1DX/LUzdSIAXT2VbEh2Um32+gQtqxAOkcqlptkBVbPo48t5TKg EUYuEmlIQ9FxciwenJ91MlsmCRFHafJfblSpZhr3nXaYCl33JsFjZeiB15IpyHRjWvJ4rZQ09Q Jp8= X-SBRS: None X-IronPort-AV: E=McAfee;i="6000,8403,9370"; a="132572457" X-IronPort-AV: E=Sophos;i="5.64,470,1559512800"; d="scan'208,217";a="132572457" Received: from unknown (HELO mucxv002.muc.infineon.com) ([172.23.11.17]) by smtp11.infineon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Sep 2019 12:53:32 +0200 Received: from MUCSE706.infineon.com (MUCSE706.infineon.com [172.23.7.80]) by mucxv002.muc.infineon.com (Postfix) with ESMTPS; Thu, 5 Sep 2019 12:53:31 +0200 (CEST) Received: from MUCSE705.infineon.com (172.23.7.79) by MUCSE706.infineon.com (172.23.7.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Thu, 5 Sep 2019 12:53:31 +0200 Received: from MUCSE707.infineon.com (172.23.7.81) by MUCSE705.infineon.com (172.23.7.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Thu, 5 Sep 2019 12:53:31 +0200 Received: from MUCSE707.infineon.com ([fe80::e599:a749:53f5:64a1]) by MUCSE707.infineon.com ([fe80::e599:a749:53f5:64a1%17]) with mapi id 15.01.1713.008; Thu, 5 Sep 2019 12:53:31 +0200 From: To: , , Thread-Topic: Secdir last call review of draft-ietf-cbor-array-tags-07 Thread-Index: AdVj14ixKz1dDp0nTWGTTPknSCjzLg== Date: Thu, 5 Sep 2019 10:53:30 +0000 Message-ID: <7be3584279814afeaed2cb9b824426c4@infineon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.23.8.247] Content-Type: multipart/alternative; boundary="_000_7be3584279814afeaed2cb9b824426c4infineoncom_" MIME-Version: 1.0 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-cbor-array-tags-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2019 10:53:50 -0000 --_000_7be3584279814afeaed2cb9b824426c4infineoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reviewer: Steve Hanna 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 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 any= other last call comments. The draft draft-ietf-cbor-array-tags-07 defines CBOR tags for typed arrays = of numeric data, multi-dimensional arrays, and homogeneous arrays. The security considerations refer mainly to the security considerations for= CBOR (RFC 7049) with appropriate additional warnings. The overall quality, brevity, and clarity of the document is good. The document is ready for approval. --_000_7be3584279814afeaed2cb9b824426c4infineoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reviewer: Steve Hanna

Review result: Ready

 

I have reviewed this document as part of the secu= rity directorate's ongoing effort to review all IETF documents being proces= sed by the IESG.  These comments were written primarily for the benefi= t of the security area directors. Document editors and WG chairs should treat these comments just like any other last= call comments.

 

The draft draft-ietf-cbor-array-tags-07 defines C= BOR tags for typed arrays of numeric data, multi-dimensional arrays, and ho= mogeneous arrays.

 

The security considerations refer mainly to the s= ecurity considerations for CBOR (RFC 7049) with appropriate additional warn= ings.

 

The overall quality, brevity, and clarity of the = document is good.

 

The document is ready for approval.

 

--_000_7be3584279814afeaed2cb9b824426c4infineoncom_-- From nobody Thu Sep 5 07:12:24 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B7B1200D7 for ; Thu, 5 Sep 2019 07:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mandelberg.org 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 XGTVo0bAYvjt for ; Thu, 5 Sep 2019 07:12:12 -0700 (PDT) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C1CD120026 for ; Thu, 5 Sep 2019 07:12:12 -0700 (PDT) X_CMAE_Category: , , X-CNFS-Analysis: v=2.3 cv=BoPjPrf5 c=1 sm=1 tr=0 a=OXtaa+9CFT7WVSERtyqzJw==:117 a=OXtaa+9CFT7WVSERtyqzJw==:17 a=KGjhK52YXX0A:10 a=IkcTkHD0fZMA:10 a=NTnny0joGdQA:10 a=J70Eh1EUuV4A:10 a=bmmO2AaSJ7QA:10 a=iiazv-oawmH03g7Men8A:9 a=QEXdDO2ut3YA:10 a=Z5ABNNGmrOfJ6cZ5bIyy:22 a=bWyr8ysk75zN3GCy5bjg:22 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: ZHNlb21uQHJjbi5jb20= Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=david@mandelberg.org; sender-id=softfail Authentication-Results: smtp02.rcn.cmh.synacor.com header.DKIM-Signature=@mandelberg.org; dkim=pass Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=david@mandelberg.org; spf=softfail; sender-id=softfail Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.user=dseomn@rcn.com; auth=pass (LOGIN) Received: from [209.6.43.168] ([209.6.43.168:49554] helo=uriel.mandelberg.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=DHE-RSA-AES256-GCM-SHA384) id 56/50-38394-7B7117D5; Thu, 05 Sep 2019 10:12:07 -0400 Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 0894F1C60AC; Thu, 5 Sep 2019 10:12:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; s=201909; t=1567692726; bh=Ew+Wfca8pzN4lqnVktoShI1uTNm7uBNL2v32ASNfOHA=; h=To:From:Subject:Date:From; b=mhiiBznWJa4J5uWyWne3+PZIy+rfENQXDGhMZUhEH1LY4MM50v4byrBGOrA69A3nf RMYTQflAu1ingrT26UCdWoeQtgPdouZtC11DJ01tRqt8duw8dCo1KfQtkAsXbTrnGQ KN8UxCUxlIWK42em4woV6HHStOe9sXuWsoRVqLLEO6k3gGoRoPSakrPytzQEiq93Dh Zxb9KQvzgdebWnx2od04McoWAVUf9qkxm8vmuXXCa/Kuiy0rJbzbIJ8wAwblfNWm4q iZXOsOUyWPA5DQP7lRA4Zb5ixCIga1qRvqMrnQECBYdFN48D/deNuCKGo7KntB9HYn Uf99E6/eQB5+Q== To: secdir@ietf.org, iesg@ietf.org, draft-ietf-sipcore-digest-scheme.all@ietf.org From: David Mandelberg Message-ID: <46a1f70a-4099-4013-4244-bbf09c7bda8b@mandelberg.org> Date: Thu, 5 Sep 2019 10:12:04 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [secdir] secdir review of draft-ietf-sipcore-digest-scheme-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2019 14:12:15 -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. This is a pretty straightforward draft to support more modern hash algorithms in SIP digest authentication. It doesn't remove support for MD5, but it paves the way for that to happen in the future. From nobody Thu Sep 5 21:42:58 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A301208A1; Thu, 5 Sep 2019 21:42:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Watson Ladd via Datatracker To: Cc: draft-ietf-stir-oob.all@ietf.org, ietf@ietf.org, stir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Watson Ladd Message-ID: <156774497737.24303.11133605098244175595@ietfa.amsl.com> Date: Thu, 05 Sep 2019 21:42:57 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-stir-oob-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2019 04:42:58 -0000 Reviewer: Watson Ladd Review result: Has Nits Dear Interested People, 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 Has Nits. One nit typographical: the sentence at the bottom of page 9 and top of page 10 beginning "PASSporTs will be encrypted with an" made more sense after I changed "signed with" to "encrypted with". Two nits cryptographical: Blind signatures are one approach: VOPRFS are another, more efficient approach. The next nit that the property of hiding the recipient of a public key encrypted message isn't a part of some of the standard security notions. This means the scheme for encrypting needs to be carefully chosen to make messages look indistinguishable from random when encrypted (the exact notion is a bit weaker, but that will do). Overall I found this draft a cogent discussion of the issues associated with possible out of band architectures for STIR discovery. Sincerely, Watson Ladd From nobody Fri Sep 6 07:48:23 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0B9120C86; Fri, 6 Sep 2019 07:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=secureservernet.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 Pb32nAWezWX1; Fri, 6 Sep 2019 07:48:11 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0723.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe41::723]) (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 A463E120C90; Fri, 6 Sep 2019 07:48:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MrffX4CH3v8BhETTcVYdNB0oEBmnjomnHfslryMZCIc1FO7BFPG6Ntfs1O+qCPAD2TSV8gAJVDefiysJzNkg96FIhInFsHHbRxdYk1kSdlULTtMXuZMSHYT/wTkS+CLOYMEUrDAdpBvLihR1ZtFitGYL1zdOF3c8AkingclqROZIMUuOflBiVQrdlkP9w+YIHur4ZfmSMokVquAc9AqjHZKEJDE4yg4TBHbOS29IJzl8eYwRY1uhN6XvhbAIZ8YCPohTuUxfc0a+8nZKYCutuNeNTQqKy8oU72NRlhpGCFRug0jI9wzHZyBnA6DDimrjcCHiHQetBIKJedrcQzsH6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qxk8uu5NVf2PzLn3oUVD6TzTV5djjyJtNwa4YYIzjIE=; b=Q8lb3+h6BCRSZR3XeCAHXd1j4YCWqvisNveuPg/87k7Rf3qBpnRIuWOer3Atb9gTp0LrgEUF/nCMma1Rfo7D6mNm7iZ3qGwDlAoHX/ogSbCQq7+ZVM8zbB3Paw9d8If3scnpVYXiTUL+ujpDvMltZZRPnjGnIVHisHNjK+gC1gDwkrEh24CdeDy0wOGlYWAEh7UBpSb2oMkdTPGkgORMUSOFcs+01p6muQuDEXzCl5Fg8Cuqg3aMf8nSRb7zaFkQNiH7Pcob6t0O0EbomLua3mrDzk1EQ8PIoFjPHgu0LYQl9L3pK4YiWcmV3wLEA95u7+VZrsUdlNwsihRd2d17dA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=godaddy.com; dmarc=pass action=none header.from=godaddy.com; dkim=pass header.d=godaddy.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=secureservernet.onmicrosoft.com; s=selector2-secureservernet-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qxk8uu5NVf2PzLn3oUVD6TzTV5djjyJtNwa4YYIzjIE=; b=nOnPT1wAz5s7Xp1e1JcyGsLszPU5TGmAgn8V12NgJN8J8uX4Nuzcj7FmWR+xkifcCnB93qGWNzcYg8/vjmUZR8oATLQm9t+yBkgscECCvgQm8dxuJrLg8hQdJnLkk87xZjfnf33cvTmUz0SIO0G5bbP2DSQlGoej8ClWLnX8trY= Received: from BL0PR02MB5491.namprd02.prod.outlook.com (20.177.207.214) by BL0PR02MB4625.namprd02.prod.outlook.com (10.167.172.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.19; Fri, 6 Sep 2019 14:48:04 +0000 Received: from BL0PR02MB5491.namprd02.prod.outlook.com ([fe80::de0:ffa3:56a:6f4e]) by BL0PR02MB5491.namprd02.prod.outlook.com ([fe80::de0:ffa3:56a:6f4e%6]) with mapi id 15.20.2220.022; Fri, 6 Sep 2019 14:48:04 +0000 From: Roger D Carney To: Yoav Nir , "secdir@ietf.org" CC: "ietf@ietf.org" , "draft-ietf-regext-epp-fees.all@ietf.org" , "regext@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-regext-epp-fees-16 Thread-Index: AQHVLo73dUFUGwuDgkmttbFHLxXhi6cb0i2A Date: Fri, 6 Sep 2019 14:48:04 +0000 Message-ID: References: <156182196167.12901.11966487185176024571@ietfa.amsl.com> In-Reply-To: <156182196167.12901.11966487185176024571@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcarney@godaddy.com; x-originating-ip: [173.18.40.219] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ce5e4e22-a127-410e-9611-08d732d93978 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BL0PR02MB4625; x-ms-traffictypediagnostic: BL0PR02MB4625: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0152EBA40F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(346002)(39860400002)(366004)(396003)(136003)(13464003)(189003)(199004)(52536014)(74316002)(9686003)(7736002)(5660300002)(11346002)(186003)(110136005)(54906003)(6506007)(66446008)(64756008)(66556008)(66476007)(66946007)(76116006)(6436002)(476003)(6246003)(3846002)(6116002)(790700001)(86362001)(256004)(478600001)(14454004)(2906002)(53936002)(7696005)(229853002)(316002)(33656002)(446003)(76176011)(14444005)(71190400001)(71200400001)(53546011)(486006)(4326008)(25786009)(2501003)(55016002)(99286004)(102836004)(66066001)(54896002)(8936002)(81166006)(81156014)(6306002)(26005)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR02MB4625; H:BL0PR02MB5491.namprd02.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: godaddy.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Su2i3FdF8A2uA9B37qHHfzlahPy+NFEmDquMfgOUSAVNuaj+y3X5qhHzQJ5Mp3r0iPjVEi5NYHyvS4VfvFbseEmm1D+u63lukqucJHIrin2XhiTM66HAbmAQX4DggfeipzMr/ZMcuc0ibxcPkbXNaAhZCnMIrUfPYtWP9V5Msnf+W31gROJH43mByymxlvn4Lc2+uxlGBb6d/q/XvhRocNkI2F3g4C3oWrvhKJWSm/nY7KuYBDKxOAV8PmmG8dpjVr5+t4w37yrqr+DZqdJMF9rLiZOihRcph2WrOXIzB0yxZlmVBOu2iPqZ2UevsGwi2NLUwh5DyDOC80McBfEj7Rke2C6hazag0tiCkYT6eSTY1FjlmRshMTSjKYrIHlXvn2K20J+V9Fcp4+cmyi6qCol+N3I4ms8ST/oxwngc4Xs= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR02MB54915DE532DCD836D4DFAD15B1BA0BL0PR02MB5491namp_" MIME-Version: 1.0 X-OriginatorOrg: godaddy.com X-MS-Exchange-CrossTenant-Network-Message-Id: ce5e4e22-a127-410e-9611-08d732d93978 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2019 14:48:04.8941 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d5f1622b-14a3-45a6-b069-003f8dc4851f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: R/bmlAO7iav4LIuSf82IRwbuhWdut1BjM4VBzeYCJ1F6OhLS7FDiszvQy9cKfefLZDeY8qa0Pf7PFaBtoxP+uA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR02MB4625 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-regext-epp-fees-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2019 14:48:15 -0000 --_000_BL0PR02MB54915DE532DCD836D4DFAD15B1BA0BL0PR02MB5491namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R29vZCBNb3JuaW5nLA0KDQoNCg0KVGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzIFlvYXYsIHBs ZWFzZSBzZWUgbXkgcmVzcG9uc2VzIGJlbG93LiBBIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCB3 aWxsIGJlIHB1Ymxpc2hlZCBzaG9ydGx5IGFuZCB3aWxsIGFkZHJlc3MgYWxsIG9mIHRoZSByZXZp ZXcgY29tbWVudHMgdGhhdCBuZWVkZWQgZWRpdHMuDQoNCg0KDQoNCg0KVGhhbmtzDQoNClJvZ2Vy DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBZb2F2IE5pciB2aWEg RGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+DQoNClNlbnQ6IFNhdHVyZGF5LCBKdW5lIDI5 LCAyMDE5IDEwOjI2IEFNDQoNClRvOiBzZWNkaXJAaWV0Zi5vcmcNCg0KQ2M6IGlldGZAaWV0Zi5v cmc7IGRyYWZ0LWlldGYtcmVnZXh0LWVwcC1mZWVzLmFsbEBpZXRmLm9yZzsgcmVnZXh0QGlldGYu b3JnDQoNClN1YmplY3Q6IFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcmVn ZXh0LWVwcC1mZWVzLTE2DQoNCg0KDQpOb3RpY2U6IFRoaXMgZW1haWwgaXMgZnJvbSBhbiBleHRl cm5hbCBzZW5kZXIuDQoNCg0KDQoNCg0KDQoNClJldmlld2VyOiBZb2F2IE5pcg0KDQpSZXZpZXcg cmVzdWx0OiBIYXMgTml0cw0KDQoNCg0KSGkNCg0KDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRv Y3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZv cnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElF U0cuICBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZp dCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuDQoNCkRvY3VtZW50IGVkaXRvcnMgYW5k IFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhl ciBsYXN0IGNhbGwgY29tbWVudHMuDQoNCg0KDQpUaGUgZW50aXJlIHRleHQgb2YgdGhlIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gaXMgYXMgZm9sbG93czoNCg0KDQoNCiAgIFRoZSBt YXBwaW5nIGV4dGVuc2lvbnMgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgZG8gbm90IHByb3Zp ZGUgYW55DQoNCiAgIHNlY3VyaXR5IHNlcnZpY2VzIGJleW9uZCB0aG9zZSBkZXNjcmliZWQgYnkg RVBQIFtSRkM1NzMwXSwgdGhlIEVQUA0KDQogICBkb21haW4gbmFtZSBtYXBwaW5nIFtSRkM1NzMx XSwgYW5kIHByb3RvY29sIGxheWVycyB1c2VkIGJ5IEVQUC4gIFRoZQ0KDQogICBzZWN1cml0eSBj b25zaWRlcmF0aW9ucyBkZXNjcmliZWQgaW4gdGhlc2Ugb3RoZXIgc3BlY2lmaWNhdGlvbnMgYXBw bHkNCg0KICAgdG8gdGhpcyBzcGVjaWZpY2F0aW9uIGFzIHdlbGwuDQoNCg0KDQpUaGlzIGlzIHdo YXQgd2UgbGlrZSB0byBjYWxsICJzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBieSByZWZlcmVuY2Ui LiBJIGRvbid0IGtub3cgd2hhdCAic2VjdXJpdHkgc2VydmljZXMiIGFyZSBpbiB0aGlzIGNvbnRl eHQsIGJ1dCB0aGV5IGFyZSBub3QgdGhlIG9ubHkgdGhpbmcgdGhhdCBuZWVkcyB0byBiZSBkZXNj cmliZWQgaW4gYSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLg0KDQoNCg0KSW4gdGhp cyBjYXNlLCB0aGUgZHJhZnQgYWRkcyBpbmZvcm1hdGlvbiBhYm91dCBmZWVzLCBjdXN0b21lciBj cmVkaXQgYW5kIHBheSBzY2hlZHVsZS4gVGhpcyBmYWxscyB1bmRlciB0aGUgY2F0ZWdvcnkgb2Yg ZmluYW5jaWFsIGluZm9ybWF0aW9uLCB3aGljaCBzaG91bGQgYmUgcHJvdGVjdGVkIGluIHRyYW5z aXQgYnkgc2VjdXJpdHkgbWVjaGFuaXNtcyB0aGF0IHByb3RlY3QgY29uZmlkZW50aWFsaXR5IGFu ZCBpbnRlZ3JpdHkuIEl0IGlzIGFsc28gdHJ1ZSB0aGF0IGFueSB0cmFuc3BvcnQgbWVjaGFuaXNt IHRoYXQgY29tcGxpZXMgd2l0aCBSRkMNCg0KNTczMCBwcm92aWRlcyB0aG9zZSBmdW5jdGlvbnMu IFNvIHdoYXQgSSdtIG1pc3NpbmcgaGVyZSBpcyBhIHNlbnRlbmNlIHRoYXQgY2FsbHMgdGhpcyBv dXQgc3BlY2lmaWNhbGx5LiBTb21ldGhpbmcgYWxvbmcgdGhlIGxpbmVzIG9mICJUaGlzIGV4dGVu c2lvbiBhZGRzIGZpbmFuY2lhbCBpbmZvcm1hdGlvbiB0byB0aGUgRVBQIHByb3RvY29sLCBzbyBj b25maWRlbnRpYWxpdHkgYW5kIGludGVncml0eSBwcm90ZWN0aW9uIG11c3QgYmUgcHJvdmlkZWQg YnkgdGhlIHRyYW5zcG9ydCBtZWNoYW5pc20uICBBbGwgdHJhbnNwb3J0cyBjb21wbGlhbnQgd2l0 aCBSRkM1NzMwIHByb3ZpZGUgdGhhdCINCg0KDQoNCltSRENdIFdlIGhhdmUgYWRkZWQgdGhlIGZv bGxvd2luZyB0ZXh0IHRvIHNlY3Rpb24gNzogIlRoaXMgZXh0ZW5zaW9uIHBhc3NlcyBmaW5hbmNp YWwgaW5mb3JtYXRpb24gdXNpbmcgdGhlIEVQUCBwcm90b2NvbCwgc28gY29uZmlkZW50aWFsaXR5 IGFuZCBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBtdXN0IGJlIHByb3ZpZGVkIGJ5IHRoZSB0cmFuc3Bv cnQgbWVjaGFuaXNtLiAgQWxsIHRyYW5zcG9ydHMgY29tcGxpYW50IHdpdGggUkZDNTczMCBwcm92 aWRlIHRoZSBuZWVkZWQgbGV2ZWwgb2YgY29uZmlkZW50aWFsaXR5IGFuZCBpbnRlZ3JpdHkgcHJv dGVjdGlvbnMuIg0K --_000_BL0PR02MB54915DE532DCD836D4DFAD15B1BA0BL0PR02MB5491namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFt ZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Hb29k IE1vcm5pbmcsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoYW5rIHlvdSBmb3IgeW91 ciBjb21tZW50cyBZb2F2LCBwbGVhc2Ugc2VlIG15IHJlc3BvbnNlcyBiZWxvdy4gQSBuZXcgdmVy c2lvbiBvZiB0aGUgZHJhZnQgd2lsbCBiZSBwdWJsaXNoZWQgc2hvcnRseSBhbmQgd2lsbCBhZGRy ZXNzIGFsbCBvZiB0aGUgcmV2aWV3IGNvbW1lbnRzIHRoYXQgbmVlZGVkIGVkaXRzLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPlRoYW5rczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Um9nZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkZyb206IFlv YXYgTmlyIHZpYSBEYXRhdHJhY2tlciAmbHQ7bm9yZXBseUBpZXRmLm9yZyZndDsgPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TZW50OiBTYXR1cmRheSwgSnVuZSAyOSwg MjAxOSAxMDoyNiBBTTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VG86 IHNlY2RpckBpZXRmLm9yZzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Q2M6IGlldGZAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtcmVnZXh0LWVwcC1mZWVzLmFsbEBpZXRmLm9y ZzsgcmVnZXh0QGlldGYub3JnPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5TdWJqZWN0OiBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLXJlZ2V4dC1l cHAtZmVlcy0xNjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Ob3RpY2U6IFRoaXMgZW1h aWwgaXMgZnJvbSBhbiBleHRlcm5hbCBzZW5kZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5SZXZpZXdlcjogWW9hdiBO aXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlJldmlldyByZXN1bHQ6 IEhhcyBOaXRzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhpPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2Yg dGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJ RVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuJm5ic3A7IFRoZXNlIGNv bW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1 cml0eSBhcmVhIGRpcmVjdG9ycy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPkRvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29t bWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPlRoZSBlbnRpcmUgdGV4dCBvZiB0aGUgU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnMgc2VjdGlvbiBpcyBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsgVGhlIG1hcHBpbmcgZXh0ZW5zaW9ucyBkZXNjcmliZWQgaW4gdGhp cyBkb2N1bWVudCBkbyBub3QgcHJvdmlkZSBhbnk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBzZWN1cml0eSBzZXJ2aWNlcyBiZXlvbmQgdGhvc2Ug ZGVzY3JpYmVkIGJ5IEVQUCBbUkZDNTczMF0sIHRoZSBFUFA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBkb21haW4gbmFtZSBtYXBwaW5nIFtSRkM1 NzMxXSwgYW5kIHByb3RvY29sIGxheWVycyB1c2VkIGJ5IEVQUC4mbmJzcDsgVGhlPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMgZGVzY3JpYmVkIGluIHRoZXNlIG90aGVyIHNwZWNpZmljYXRpb25zIGFwcGx5 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgdG8g dGhpcyBzcGVjaWZpY2F0aW9uIGFzIHdlbGwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PlRoaXMgaXMgd2hhdCB3ZSBsaWtlIHRvIGNhbGwgJnF1b3Q7c2VjdXJpdHkgY29uc2lkZXJhdGlv bnMgYnkgcmVmZXJlbmNlJnF1b3Q7LiBJIGRvbid0IGtub3cgd2hhdCAmcXVvdDtzZWN1cml0eSBz ZXJ2aWNlcyZxdW90OyBhcmUgaW4gdGhpcyBjb250ZXh0LCBidXQgdGhleSBhcmUgbm90IHRoZSBv bmx5IHRoaW5nIHRoYXQgbmVlZHMgdG8gYmUgZGVzY3JpYmVkIGluIGEgU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnMgc2VjdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SW4gdGhpcyBj YXNlLCB0aGUgZHJhZnQgYWRkcyBpbmZvcm1hdGlvbiBhYm91dCBmZWVzLCBjdXN0b21lciBjcmVk aXQgYW5kIHBheSBzY2hlZHVsZS4gVGhpcyBmYWxscyB1bmRlciB0aGUgY2F0ZWdvcnkgb2YgZmlu YW5jaWFsIGluZm9ybWF0aW9uLCB3aGljaCBzaG91bGQgYmUgcHJvdGVjdGVkIGluIHRyYW5zaXQg Ynkgc2VjdXJpdHkgbWVjaGFuaXNtcyB0aGF0IHByb3RlY3QgY29uZmlkZW50aWFsaXR5IGFuZA0K IGludGVncml0eS4gSXQgaXMgYWxzbyB0cnVlIHRoYXQgYW55IHRyYW5zcG9ydCBtZWNoYW5pc20g dGhhdCBjb21wbGllcyB3aXRoIFJGQzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+NTczMCBwcm92aWRlcyB0aG9zZSBmdW5jdGlvbnMuIFNvIHdoYXQgSSdtIG1pc3Npbmcg aGVyZSBpcyBhIHNlbnRlbmNlIHRoYXQgY2FsbHMgdGhpcyBvdXQgc3BlY2lmaWNhbGx5LiBTb21l dGhpbmcgYWxvbmcgdGhlIGxpbmVzIG9mICZxdW90O1RoaXMgZXh0ZW5zaW9uIGFkZHMgZmluYW5j aWFsIGluZm9ybWF0aW9uIHRvIHRoZSBFUFAgcHJvdG9jb2wsIHNvIGNvbmZpZGVudGlhbGl0eSBh bmQgaW50ZWdyaXR5IHByb3RlY3Rpb24NCiBtdXN0IGJlIHByb3ZpZGVkIGJ5IHRoZSB0cmFuc3Bv cnQgbWVjaGFuaXNtLiZuYnNwOyBBbGwgdHJhbnNwb3J0cyBjb21wbGlhbnQgd2l0aCBSRkM1NzMw IHByb3ZpZGUgdGhhdCZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj5b UkRDXSBXZSBoYXZlIGFkZGVkIHRoZSBmb2xsb3dpbmcgdGV4dCB0byBzZWN0aW9uIDc6ICZxdW90 O1RoaXMgZXh0ZW5zaW9uIHBhc3NlcyBmaW5hbmNpYWwgaW5mb3JtYXRpb24gdXNpbmcgdGhlIEVQ UCBwcm90b2NvbCwgc28gY29uZmlkZW50aWFsaXR5IGFuZCBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBt dXN0IGJlIHByb3ZpZGVkIGJ5IHRoZSB0cmFuc3BvcnQgbWVjaGFuaXNtLiZuYnNwOw0KIEFsbCB0 cmFuc3BvcnRzIGNvbXBsaWFudCB3aXRoIFJGQzU3MzAgcHJvdmlkZSB0aGUgbmVlZGVkIGxldmVs IG9mIGNvbmZpZGVudGlhbGl0eSBhbmQgaW50ZWdyaXR5IHByb3RlY3Rpb25zLiZxdW90OzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BL0PR02MB54915DE532DCD836D4DFAD15B1BA0BL0PR02MB5491namp_-- From nobody Fri Sep 6 08:08:19 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03BB120CB4; Fri, 6 Sep 2019 08:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Dj5z0WSLcj1; Fri, 6 Sep 2019 08:08:03 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 1FC0F120C9E; Fri, 6 Sep 2019 08:08:03 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id t17so6894960wmi.2; Fri, 06 Sep 2019 08:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=3aFcWo8LQ0QSfDvdj8msWzBDhkMDJ99kX3vQMt/gAus=; b=T64YY5kvwBjnfe2NRJ8O9n+RxW5lzuCqRxyAfAgnYvzQ07ZeTs5Z62GkTnPQbwpC2t TCMnIm8pGX3pUwSWRB7cSaAp+IPmHIJvsLLA3H3wE4uPGVI5lyfkZhqGsriMcBEV4zzh q4lXw9cCIszTWBt4epPO2NVG4jSq0V4T2ZmR4fX1kTxWhaZVHaIEeUdbOiDiLszuIN2N GjA/grOXaTjdGa1ZJuPIa7ZLeZr83RSidt9UNekr87+fvU/cZYVMD+89oFT9IGQ3zw2r RTqptcesOHEe0cbe5Yk2dYpzvmo1bTrP0lh3vK8Ja9OUbSkqQukNRp1WkpM7EFTpy/Ln ZWgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=3aFcWo8LQ0QSfDvdj8msWzBDhkMDJ99kX3vQMt/gAus=; b=ozTN561GARYmZg/A02LWkVPOblYoEUfR/6eGhIrO2Z/c3bQb6SztZ6LVA+ymQgKObh SRY1Tt75MEAjayBRnWoCO6MTlPPWqQH63PTbkSpYa2nwQ2xF1CInuz+9R8gevdI4K9QS 1YfGzd+0tfCAMmywkwvwL3l1QVCZM3dpvCj4YEP2PQEr+h6ScfbOaqjZcl4iOaRK7MUK A5sh11aOi4QK+qU3+JsbGvbxVY/cgnZ0TUVtrH8nNJFts1srZ22jJujxr7izBaXWc8HT 5wMRGG/SC832+0S+3vc8brFM/sHUsmx+PL91T9vijXVkkoj4yb/FBK3e7Jj0dntdkJB/ IcLQ== X-Gm-Message-State: APjAAAViwlfCpiT0+e77ovyW1DaOjf9P8lc819OoYVOeiv+NuUcoyeE7 OpDygR19TG4OfRrcesSVmjE= X-Google-Smtp-Source: APXvYqylmCyHEx+VLbVEqWKD31yp0aU0u9snhk/1seV9aCtCwLmskP27/iq2wKWvKxOlt3I/D4ZB7A== X-Received: by 2002:a1c:f518:: with SMTP id t24mr7367184wmh.98.1567782481465; Fri, 06 Sep 2019 08:08:01 -0700 (PDT) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id c3sm7451065wrh.55.2019.09.06.08.07.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Sep 2019 08:07:58 -0700 (PDT) From: Yoav Nir Message-Id: <5D46C5CF-8453-4F59-B7C7-692A2B5F0BD7@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_851569C1-8791-4FAF-9B46-A7BA5380498A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 6 Sep 2019 18:07:55 +0300 In-Reply-To: Cc: "secdir@ietf.org" , "ietf@ietf.org" , "draft-ietf-regext-epp-fees.all@ietf.org" , "regext@ietf.org" To: Roger D Carney References: <156182196167.12901.11966487185176024571@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-regext-epp-fees-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2019 15:08:06 -0000 --Apple-Mail=_851569C1-8791-4FAF-9B46-A7BA5380498A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Roger Looks good. What I think should also be said, is that the financial = information passed to any customer is only information about that = customer=E2=80=99s own account. We wouldn=E2=80=99t want customer = information to leak to other customers. Yoav > On 6 Sep 2019, at 17:48, Roger D Carney wrote: >=20 > Good Morning, > =20 > Thank you for your comments Yoav, please see my responses below. A new = version of the draft will be published shortly and will address all of = the review comments that needed edits. > =20 > =20 > Thanks > Roger > =20 > -----Original Message----- > From: Yoav Nir via Datatracker >=20 > Sent: Saturday, June 29, 2019 10:26 AM > To: secdir@ietf.org > Cc: ietf@ietf.org ; = draft-ietf-regext-epp-fees.all@ietf.org = ; regext@ietf.org = > Subject: Secdir last call review of draft-ietf-regext-epp-fees-16 > =20 > Notice: This email is from an external sender. > =20 > =20 > =20 > Reviewer: Yoav Nir > Review result: Has Nits > =20 > Hi > =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 entire text of the Security Considerations section is as follows: > =20 > The mapping extensions described in this document do not provide = any > security services beyond those described by EPP [RFC5730], the EPP > domain name mapping [RFC5731], and protocol layers used by EPP. = The > security considerations described in these other specifications = apply > to this specification as well. > =20 > This is what we like to call "security considerations by reference". I = don't know what "security services" are in this context, but they are = not the only thing that needs to be described in a Security = Considerations section. > =20 > In this case, the draft adds information about fees, customer credit = and pay schedule. This falls under the category of financial = information, which should be protected in transit by security mechanisms = that protect confidentiality and integrity. It is also true that any = transport mechanism that complies with RFC > 5730 provides those functions. So what I'm missing here is a sentence = that calls this out specifically. Something along the lines of "This = extension adds financial information to the EPP protocol, so = confidentiality and integrity protection must be provided by the = transport mechanism. All transports compliant with RFC5730 provide = that" > =20 > [RDC] We have added the following text to section 7: "This extension = passes financial information using the EPP protocol, so confidentiality = and integrity protection must be provided by the transport mechanism. = All transports compliant with RFC5730 provide the needed level of = confidentiality and integrity protections." --Apple-Mail=_851569C1-8791-4FAF-9B46-A7BA5380498A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = Roger

Looks good. =  What I think should also be said, is that the financial = information passed to any customer is only information about that = customer=E2=80=99s own account.  We wouldn=E2=80=99t want customer = information to leak to other customers.

Yoav

On 6 Sep = 2019, at 17:48, Roger D Carney <rcarney@godaddy.com> wrote:

Good = Morning,
 
Thank you for your comments Yoav, please see my responses = below. A new version of the draft will be published shortly and will = address all of the review comments that needed edits.
 
 
Thanks
Roger
 
-----Original Message-----
From: Yoav Nir via Datatracker <noreply@ietf.org> 
Sent: = Saturday, June 29, 2019 10:26 AM
To: secdir@ietf.org
Cc: ietf@ietf.org; draft-ietf-regext-epp-fees.all@ietf.org; regext@ietf.org
Subject: = Secdir last call review of draft-ietf-regext-epp-fees-16
 
Notice: = This email is from an external sender.
 
 
 
Reviewer: Yoav Nir
Review = result: Has Nits
 
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 entire text of the Security Considerations section is as = follows:
 
   The mapping extensions described in this = document do not provide any
   security services beyond = those described by EPP [RFC5730], the EPP
   domain name mapping = [RFC5731], and protocol layers used by EPP.  The
   security considerations described in these other = specifications apply
   to this specification as well.
 
This is = what we like to call "security considerations by reference". I don't = know what "security services" are in this context, but they are not the = only thing that needs to be described in a Security Considerations = section.
 
In this case, the draft adds information about fees, customer = credit and pay schedule. This falls under the category of financial = information, which should be protected in transit by security mechanisms = that protect confidentiality and integrity. It is also true that any = transport mechanism that complies with RFC
5730 provides those functions. So what = I'm missing here is a sentence that calls this out specifically. = Something along the lines of "This extension adds financial information = to the EPP protocol, so confidentiality and integrity protection must be = provided by the transport mechanism.  All transports compliant with = RFC5730 provide that"
 
[RDC] We = have added the following text to section 7: "This extension passes = financial information using the EPP protocol, so confidentiality and = integrity protection must be provided by the transport mechanism.  = All transports compliant with RFC5730 provide the needed level of = confidentiality and integrity = protections."

= --Apple-Mail=_851569C1-8791-4FAF-9B46-A7BA5380498A-- From nobody Fri Sep 6 09:20:42 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D87B612011B; Fri, 6 Sep 2019 09:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1567786175; bh=aZtKtptABkckZtjiNMydDDW8w4D3ZvmeSKbY2+MNwEU=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=FChAwDmmOWi7Ep54Uthu+dlARd70JBdEfXDASCQodFlacs2if4w2cLn7vxiPCCXd/ shlyYPD4zXM/JNsTWFofrFAzxjCr+g7jc90R3hajBieI6Soh9If3edLeOw+LNjcERU E/Di11qYYt/xO4aKgdbBm9LHbyIaZEgSlU8V98yE= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Sep 6 09:09:30 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 476DB1200FB; Fri, 6 Sep 2019 09:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1567786167; bh=aZtKtptABkckZtjiNMydDDW8w4D3ZvmeSKbY2+MNwEU=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=qvB0S5AYnLr3YPakucxQYQqA7gBwyhVth5d9bjSc8hX37eMqA1sUb1FqjKw2w6qfA qFU4Mo5C7uANRxgznJZAZYQ5JJKYxYVeHWDtzu7SJLX8h0HZ4cm73HTDPFL8wANAfM kS5gGg4i0syg8bcaRJ0VMvfXY3n1bAYayXUjdltA= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F641200F9 for ; Fri, 6 Sep 2019 09:09:17 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply_to: MIME-Version: 1.0 Message-ID: <156778615775.21955.16322688102613833955.idtracker@ietfa.amsl.com> Date: Fri, 06 Sep 2019 09:09:17 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 06 Sep 2019 09:20:40 -0700 Subject: [secdir] [new-work] WG Review: Audio/Video Transport Core Maintenance (avtcore) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2019 16:09:40 -0000 The Audio/Video Transport Core Maintenance (avtcore) WG in the Applications and Real-Time Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2019-09-16. Audio/Video Transport Core Maintenance (avtcore) ----------------------------------------------------------------------- Current status: Active WG Chairs: Rachel Huang Jonathan Lennox Assigned Area Director: Barry Leiba Applications and Real-Time Area Directors: Adam Roach Alexey Melnikov Barry Leiba Mailing list: Address: avt@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/avt Archive: https://mailarchive.ietf.org/arch/browse/avt/ Group page: https://datatracker.ietf.org/group/avtcore/ Charter: https://datatracker.ietf.org/doc/charter-ietf-avtcore/ The Real-time Transport Protocol (RTP) along with its associated profiles and payload formats provides for real-time transmission of audio and video over unicast and multicast transports. RTP is widely implemented and deployed for a broad range of applications, from telephony to television over IP. RTP itself is now an Internet Standard. Its associated profiles, extensions, and payload formats are currently at various levels of standards maturity. As new applications emerge, there is a need for guidelines for the use of the RTP/RTCP protocols and extensions specific to those applications. The AVTCORE working group is chartered for the following tasks: 1. To maintain the core RTP/RTCP specifications and the AVP, SAVP, AVPF, and SAVPF profiles. The group will provide architectural guidance for extending the protocols and guidelines for their proper use. 2. To develop application-specific guidelines for the use of RTP/RTCP protocols with the AVP, SAVP, AVPF, and SAVPF profiles, and extensions to those protocols that are driven by application-specific needs. 3. To specify and maintain payload formats for use with RTP. The working group will develop RTP payload formats for new media codecs, review and revise existing payload formats to advance those that are especially useful to Internet Standard, and declare others Historic. The group will follow the guidelines established in "Guidelines for Writers of RTP Payload Format Specifications" [BCP 36] and "How to Write an RTP Payload Format" (RFC 8088), and is responsible for maintaining those guidelines. 4. To evaluate and process proposals for RTP eXtended Report Block (XRBLOCK) definitions containing new metrics. The group will work within the framework defined by RFC 3611, "RTP Control Protocol Extended Reports (RTCP XR)" along with other RTP monitoring architecture being developed in the working group. It will follow the guidelines established in RFC 5968, "Guidelines for Extending the RTP Control Protocol (RTCP)" and RFC 6390, "Guidelines for Considering New Performance Metric Development". The AVTCORE working group will coordinate closely with the Security Area while working on maintenance and enhancements to the SRTP Profile (SAVP). Milestones: Feb 2019 - Submit Guidelines for using the Multiplexing Features of RTP for Informational Mar 2019 - Submit RTP Payload Format for the TETRA Audio Codec Apr 2019 - Submit RTP Header Extension for Video Frame Information for Proposed Standard Jun 2019 - Submit Feedback Mechanism for RTP Congestion Control for Proposed Standard Nov 2019 - Submit RTP Payload Format for VP9 Video for Proposed Standard Mar 2020 - Submit RTP Payload Format for ISO/IEC 21122 (JPEG XS) for Proposed Standard Mar 2020 - Submit RTP Payload Format for TTML Timed Text for Proposed Standard _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Sep 6 10:55:30 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D04A1120866; Fri, 6 Sep 2019 10:55:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Stephen Kent via Datatracker To: Cc: draft-ietf-cbor-sequence.all@ietf.org, ietf@ietf.org, cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Stephen Kent Message-ID: <156779251575.21899.11186203310854403491@ietfa.amsl.com> Date: Fri, 06 Sep 2019 10:55:15 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-cbor-sequence-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2019 17:55:16 -0000 Reviewer: Stephen Kent Review result: Ready SECDIR review of draft-ietf-cbor-sequence-01 The summary of the review is Ready, with one suggested edit. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. The Abstract says that this short document describes the Concise Binary Object Representation(CBOR) Sequence format and associated media type "application/cbor seq". The document indicates that the motivation for this extension of the base CBOR specification (RFC 7049) is to specify a format for CBOR sequences, which allow incremental production and consumption of such sequences while imposing minimal demands on a CBOR parser. The Security Considerations section consists of just two, brief paragraphs. The first says that the considerations of the base CBRO specification (RFC 7049) apply, which seems reasonable. The Security Considerations section of that document is well written. It discusses several types of potential vulnerabilities associated with complex parsers, and notes that CBOR tries to reduce the range of some type of attacks by striving to reduce parser complexity. This document notes that COSE (RFC 8152) can be employed if security services, e.g., data integrity, are required. This too seems reasonable, since COSE explicitly specifies mechanisms for offering such services for CBOR-formatted data. The second paragraph of the Security Considerations section reminds the reader that decoders (parsers) ought to be designed with the understanding that inputs are untrusted – good advice. I’d be happier if the final sentence changed “must” to “MUST” to reinforce this admonition. From nobody Tue Sep 10 15:29:37 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC12C120019; Tue, 10 Sep 2019 15:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrGQb7Dd3C4H; Tue, 10 Sep 2019 15:29:26 -0700 (PDT) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 ED83D12003F; Tue, 10 Sep 2019 15:29:25 -0700 (PDT) Received: by mail-ot1-x334.google.com with SMTP id z26so11358805oto.1; Tue, 10 Sep 2019 15:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=kSYEgKxH0dkr/7o/N+xMugd7TdAycmcOvgl1ulpKDHA=; b=mwYIzwFhJMHHMWaFDB3t2n36/ZJzv6mfl7OiFxcfXDPFbRdgdRpl3T696rxwodk2p+ WJDGuliymd6gBe1QMRmOVJ6LiMCNTa/ATeGB4l7FDs6VgMPjPfRkUw4oBxaV/Nw2Wn4F yHwNZrNBWc0zjmNctNNoxWAoSr1EkSLRVM3beNig96XLsvB2aSV0uo0ncy4IMzajuHxW 9+OF1Fl/3a3ZUPdBJX3kxm787ZmAavQvZ89c11VFKyCSYQg25fKJdjLJDikD+PwSYf4m 2LJJJwUVfJGVo3r8X8XsCKAUcS3F3pUC57Gdh3K8uSWIt8qlm+pKRvDh0th1vhuTnLpC DCfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=kSYEgKxH0dkr/7o/N+xMugd7TdAycmcOvgl1ulpKDHA=; b=BZhYCM1Q19fIhEOU9DmKDOrU5RQ/MuR6mf5XMsZHH4V47UER9Unm2NA0uSoDX0LHdQ gDJCq6YiJBILRYX8WHrRzKGn0bORkUKX88GsX2WJU3GsS4sNWx960G95+mG4lgU+DIF7 cHcAeEzp//poF1Q5TlwPSmHMz0Ft7bZJc0l7OlFuKpHPSjFPLNm2luR3K+OANb4tVb0L IU/ziV6jWYc7kgxrA4mPew8R4Q9sdpmW3uyD9JWWCTBE88HDiaA3XUwYSGJb1nQKzYYm w3BE6fu+A+4S3gVyBQM/GuIi5a8BxXghDMrjUnGUwXqN/O/f1p8U4vnSQJiV+Aiw8d3j YdHQ== X-Gm-Message-State: APjAAAULGO5ME6cDQhtq8i496ORjsxDrBgRWnTAzxAC4WXnRnTISgweP Lb39xTK6TXFmrb2vpNCsC95431Is X-Google-Smtp-Source: APXvYqxCXtfOySObqrd5+fbRjPEBiDsHLdsgNZz/Sjq5mIdjUFtoGiG97gKvU0+XR6OPX000+IQs9A== X-Received: by 2002:a9d:7d91:: with SMTP id j17mr2201745otn.120.1568154565165; Tue, 10 Sep 2019 15:29:25 -0700 (PDT) Received: from Chriss-Air.attlocal.net ([2600:1700:12b0:adf0:9c5c:5907:e6b6:cc58]) by smtp.googlemail.com with ESMTPSA id r2sm6606497oia.0.2019.09.10.15.29.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Sep 2019 15:29:24 -0700 (PDT) To: draft-ietf-sipcore-callinfo-spam@ietf.org, "iesg@ietf.org" , "secdir@ietf.org" From: Chris Lonvick Message-ID: <0cc5e268-26c4-b3b6-c39a-3d99d595ca85@gmail.com> Date: Tue, 10 Sep 2019 17:29:24 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------E3AC2F2253B433EE480F8B20" Content-Language: en-US Archived-At: Subject: [secdir] SECDIR Review of draft-ietf-sipcore-callinfo-spam-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2019 22:29:28 -0000 This is a multi-part message in MIME format. --------------E3AC2F2253B433EE480F8B20 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready with nits. Overall, the document is well written and, as I disregard yet another call from a number that's suspiciously very like my own number, will probably be very useful. Nit 1 - The next to last paragraph of the Security Considerations section says that "a UAS SHOULD NOT trust the information in the "Call-Info" header field unless the SIP session between the entity inserting the header field and the UAS is protected by TLS [RFC8446]." Perhaps it would be more appropriate to include a qualification that a certificate offered by the entity must be authenticated. This would prevent rogue entities with self-signed certificates from attempting to insert a header field. Or perhaps there are more appropriate measures in SIP to prevent that. (I'm just not altogether that familiar with SIP to say.) Nit 2 - (Very minor typo nits): In the last paragraph in the Security Considerations section "mislead" should be "misled"; "only be added calls" should be "only be added to calls". Best regards, Chris --------------E3AC2F2253B433EE480F8B20 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi,

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

The summary of the review is Ready with nits.

Overall, the document is well written and, as I disregard yet another call from a number that's suspiciously very like my own number, will probably be very useful.

Nit 1 - The next to last paragraph of the Security Considerations section says that "a UAS SHOULD NOT trust the information in the "Call-Info" header field unless the SIP session between the entity inserting the header field and the UAS is protected by TLS [RFC8446]." Perhaps it would be more appropriate to include a qualification that a certificate offered by the entity must be authenticated. This would prevent rogue entities with self-signed certificates from attempting to insert a header field. Or perhaps there are more appropriate measures in SIP to prevent that. (I'm just not altogether that familiar with SIP to say.)

Nit 2 - (Very minor typo nits): In the last paragraph in the Security Considerations section "mislead" should be "misled"; "only be added calls" should be "only be added to calls".

Best regards,

Chris

--------------E3AC2F2253B433EE480F8B20-- From nobody Tue Sep 10 18:41:11 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AD71200E0; Tue, 10 Sep 2019 18:41:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christopher Wood via Datatracker To: Cc: ietf@ietf.org, draft-klensin-idna-unicode-review.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.101.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Christopher Wood Message-ID: <156816606075.22400.22167404102467671@ietfa.amsl.com> Date: Tue, 10 Sep 2019 18:41:00 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-klensin-idna-unicode-review-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 01:41:01 -0000 Reviewer: Christopher Wood Review result: Has Nits This document looks mostly good to go. I only have a few questions and some various editorial nits. Questions: - Section 4, last paragraph: Will code points "considered unsafe" be labelled as such, and if so, where? In the derived property IANA tables? (Assuming those tables are kept.) - Section 5, second paragraph: How will the success of this document's proposed changes be measured in order to determine if further steps towards minimizing confusion are needed? Nits: - Section 2, first paragraph, first sentence: It seems a comma is missing after [RFC3491] reference, i.e., "..., commonly known as "IDNA2003" [RFC3490] [RFC3491], ...". - Section 3, second paragraph: s/full Unicode versions/major Unicode versions? - Section 3.1: s/also concluded that maintain Unicode/also concluded that Unicode? - Section 4, third paragraph: Is the requirement that changes which are "documented" redundant with the following "explained" requirement? (That is, perhaps just say "... must be documented and explained." - Security Considerations, second paragraph: Do "end users" include systems that process or interpret Unicode values? If not, it might help to specifically call them out, as problems may arise from misinterpretation there. From nobody Tue Sep 10 21:34:37 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B48120024; Tue, 10 Sep 2019 20:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1568172216; bh=V2EjZK2jfy4m2+Ulzg89zJryXBBDezkDHtGy2k/i8Yc=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=TPgskhVrrhyDVXMgI/JvLnFqY2u5icgKzNUIMpOgkpy44dxIue7hySZoS5+WFor7q jocVtZVySF4Xdbiu+FL2Ovm33v4pe6l/xhUVqn6GVp77reBrd7SxwlYCaFLlVAojis /p0S/gKXdklSJfu+h/LTGDUThymg22ejWzDm6gzg= X-Mailbox-Line: From new-work-bounces@ietf.org Tue Sep 10 20:23:36 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2D61207FE; Tue, 10 Sep 2019 20:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1568172216; bh=V2EjZK2jfy4m2+Ulzg89zJryXBBDezkDHtGy2k/i8Yc=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=TPgskhVrrhyDVXMgI/JvLnFqY2u5icgKzNUIMpOgkpy44dxIue7hySZoS5+WFor7q jocVtZVySF4Xdbiu+FL2Ovm33v4pe6l/xhUVqn6GVp77reBrd7SxwlYCaFLlVAojis /p0S/gKXdklSJfu+h/LTGDUThymg22ejWzDm6gzg= 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 591691207FE for ; Tue, 10 Sep 2019 20:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, 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 danb53XvyXdW for ; Tue, 10 Sep 2019 20:23:32 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (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 5FEF6120024 for ; Tue, 10 Sep 2019 20:23:32 -0700 (PDT) Received: from [42.100.6.231] (helo=[192.168.1.4]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1i7tE8-00029d-R9 for new-work@ietf.org; Wed, 11 Sep 2019 03:23:29 +0000 To: new-work@ietf.org From: xueyuan Message-ID: Date: Wed, 11 Sep 2019 11:23:25 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Tue, 10 Sep 2019 21:34:35 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Accessibility Guidelines Working Group (AG WG) (until 2019-10-08) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 03:23:39 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgQWNjZXNz aWJpbGl0eSBHdWlkZWxpbmVzIFdvcmtpbmcgR3JvdXAgCihBRyBXRyk6CiDCoCBodHRwczovL3d3 dy53My5vcmcvMjAxOS8wOC9kcmFmdC1hZy1jaGFydGVyCgpBcyBwYXJ0IG9mIGVuc3VyaW5nIHRo YXQgdGhlIGNvbW11bml0eSBpcyBhd2FyZSBvZiBwcm9wb3NlZCB3b3JrCmF0IFczQywgdGhpcyBk cmFmdCBjaGFydGVyIGlzIHB1YmxpYyBkdXJpbmcgdGhlIEFkdmlzb3J5CkNvbW1pdHRlZSByZXZp ZXcgcGVyaW9kLgoKVzNDIGludml0ZXMgcHVibGljIGNvbW1lbnRzIHRocm91Z2ggMjAxOS0xMC0w OCBvbiB0aGUKcHJvcG9zZWQgY2hhcnRlci4gUGxlYXNlIHNlbmQgY29tbWVudHMgdG8KcHVibGlj LW5ldy13b3JrQHczLm9yZywgd2hpY2ggaGFzIGEgcHVibGljIGFyY2hpdmU6CiDCoCBodHRwOi8v bGlzdHMudzMub3JnL0FyY2hpdmVzL1B1YmxpYy9wdWJsaWMtbmV3LXdvcmsvCgpPdGhlciB0aGFu IGNvbW1lbnRzIHNlbnQgaW4gZm9ybWFsIHJlc3BvbnNlcyBieSBXM0MgQWR2aXNvcnkKQ29tbWl0 dGVlIFJlcHJlc2VudGF0aXZlcywgVzNDIGNhbm5vdCBndWFyYW50ZWUgYSByZXNwb25zZSB0bwpj b21tZW50cy4gSWYgeW91IHdvcmsgZm9yIGEgVzNDIE1lbWJlciBbMV0sIHBsZWFzZSBjb29yZGlu YXRlCnlvdXIgY29tbWVudHMgd2l0aCB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRh dGl2ZS4gRm9yCmV4YW1wbGUsIHlvdSBtYXkgd2lzaCB0byBtYWtlIHB1YmxpYyBjb21tZW50cyB2 aWEgdGhpcyBsaXN0IGFuZApoYXZlIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0 aXZlIHJlZmVyIHRvIGl0IGZyb20gaGlzCm9yIGhlciBmb3JtYWwgcmV2aWV3IGNvbW1lbnRzLgoK SWYgeW91IHNob3VsZCBoYXZlIGFueSBxdWVzdGlvbnMgb3IgbmVlZCBmdXJ0aGVyIGluZm9ybWF0 aW9uLCBwbGVhc2UKY29udGFjdCBNaWNoYWVsIENvb3BlciwgVzNDIFN0YWZmIENvbnRhY3QgPGNv b3BlckB3My5vcmc+LgoKVGhhbmsgeW91LAoKWHVleXVhbiBKaWEsIFczQyBNYXJrZXRpbmcgJiBD b21tdW5pY2F0aW9ucwoKWzFdIGh0dHA6Ly93d3cudzMub3JnL0NvbnNvcnRpdW0vTWVtYmVyL0xp c3QKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXct d29yayBtYWlsaW5nIGxpc3QKbmV3LXdvcmtAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXctd29yawo= From nobody Wed Sep 11 15:08:17 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1943D120289; Wed, 11 Sep 2019 15:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 P4A2aLYdhkxo; Wed, 11 Sep 2019 15:07:34 -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 F01301200A1; Wed, 11 Sep 2019 15:07:30 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1i8Alt-000LH0-JO; Wed, 11 Sep 2019 18:07:29 -0400 Date: Wed, 11 Sep 2019 18:07:24 -0400 From: John C Klensin To: Christopher Wood cc: secdir@ietf.org, iesg@ietf.org, draft-klensin-idna-unicode-review.all@ietf.org Message-ID: <645388ABB5D92E33447C55DF@PSB> In-Reply-To: <156816606075.22400.22167404102467671@ietfa.amsl.com> References: <156816606075.22400.22167404102467671@ietfa.amsl.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [secdir] Secdir last call review of draft-klensin-idna-unicode-review-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 22:07:36 -0000 Christopher, (since Last Call has ended, iesg added and the IETF list = removed) This has already been discussed in the context of another review but, the tracker showed the review as being due by August 30, the same date as Last Call closed, until yesterday. It is important that area reviews appear within the Last Call period so that others in the community can comment on them. Late reviews, especially ones that arrive after the IESG evaluation period starts, are also a bit disrespectful of authors who struggle to get complete documents posted immediately after IETF Last Call and before the IESG evaluation period begins so as to have documents that are as complete as possible before ADs start their reviews and of those ADs who might have done so. That said.... --On Tuesday, September 10, 2019 18:41 -0700 Christopher Wood via Datatracker wrote: > Reviewer: Christopher Wood > Review result: Has Nits >=20 > This document looks mostly good to go. I only have a few > questions and some various editorial nits. >=20 > Questions: > - Section 4, last paragraph: Will code points "considered > unsafe" be labelled as such, and if so, where? In the derived > property IANA tables? (Assuming those tables are kept.) - The document should be clear on this. In particular, the last sentence of Section 3.2, which, AFAICT, is the first comment in it about "considered unsafe", says 'The affected code points should be considered unsafe and identified as "under review" in the IANA tables until final derived properties are assigned.' That seems very clear to me unless you think the document should say "... identified as 'unsafe and under review' in the IANA tables..." or something similar. That, to me, is a tradeoff against tediousness and against the fairly clear language in the base IDNA specifications, as well as language in draft-klensin-idna-5891bis (in Last Call and IESG evaluation current with this document) that spell out what a zone is allowed to do with code points that IDNA considers PVALID. The intent is to give a registry a clear warning that the status of a code point might change as reviews continue. If there were community consensus that the issue should be described in more detail in this document, I assume we would happily change it. But, because this issue did not come up during IETF Last Call, there is no time for such a discussion and, IMO, a presumption that the text is ok. > Section 5, second paragraph: How will the success of this > document's proposed changes be measured in order to determine > if further steps towards minimizing confusion are needed? First of all, the nature of human languages and writing systems and their evolution is such that, as characters other than those from very simple scripts designed for easy recognition (e.g., Roman script as used in the early Roman Republic) are allowed in identifiers (including domain name labels), aspirations for zero confusion are up there with aspirations for perfect security that cannot be broken by any mechanism now or in the future. That makes "good enough" subjective, circumstantial, and, to some extent, dependent on the dedication of the attackers and resources available to them. But this paragraph is not about that. It is about the observation that publishing non-normative tables with IANA, rather than telling people what the rules and algorithms are and expected them to do their own computation or relying on tables that are not an IETF responsibility, has resulted in a good deal of confusion (and some complaints) about what the true and correct values are. If those complaints now stop, we are successful. If they continue, then we conclude the that IANA tables are a bad idea on balance and we drop them. It occurs to me that your comment about "unsafe and under review" and the discussion above suggest that, if we decided to get rid of the IANA tables in their current form, we'd need to find a place to publish that information. But let's cross that bridge when and if we get to it. > Nits: > - Section 2, first paragraph, first sentence: It seems a comma > is missing after [RFC3491] reference, i.e., "..., commonly > known as "IDNA2003" [RFC3490] [RFC3491], ...". Correct. Working draft fixed. Thanks although I'm confident the RFC Editor would have caught this.=20 > - Section 3, > second paragraph: s/full Unicode versions/major Unicode > versions? IIR, "full Unicode versions" is Unicode's preferred terminology. We should check this. - Section 3.1: s/also concluded that maintain > Unicode/also concluded that Unicode? Yes. Cut and paste error as that sentence was rewritten several times. Fixed in working draft. > - Section 4, third > paragraph: Is the requirement that changes which are > "documented" redundant with the following "explained" > requirement? (That is, perhaps just say "... must be > documented and explained." It is actually not redundant although I understand why you might read it that way. Explanation on request if you or some AD think it is important. > - Security Considerations, second > paragraph: Do "end users" include systems that process or > interpret Unicode values? If not, it might help to = specifically > call them out, as problems may arise from misinterpretation > there. They do not. "End user" refers to human beings and, perhaps eventually, robots who are using the Internet as surrogates for human beings. One of the design goals of IDNA2008 (successfully realized) was to create a situation in which there simply are no ambiguities in Unicode strings as they pass through the protocol. As an overused example, as far as computer systems processing or interpreting values are concerned, Latin small "a" (U+0061) is quite distinct from Cyrillic small "=D0=B0" (U+0430) = in all relevant encoding forms including what happens when those code points are passed through the Punycode algorithm. The problem occurs only when those characters are displayed to humans and they can't tell the difference. Hence end users. =20 Processes that try to figure out what a human might confuse are a different story, but they, necessarily, operate off assumptions about the graphemes associated with particular code points and not the code points themselves. Hence they are just not relevant to this document. Thanks for the careful reading. best, john From nobody Wed Sep 11 19:10:15 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6401200B7; Wed, 11 Sep 2019 19:10:06 -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=heapingbits.net header.b=Uw6CaxDv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XYMexm8w 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 17UpnYoMd0zc; Wed, 11 Sep 2019 19:10:03 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72CDC120013; Wed, 11 Sep 2019 19:10:03 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C548322535; Wed, 11 Sep 2019 22:10:02 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Wed, 11 Sep 2019 22:10:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm2; bh=vt DHPrXZ8QiqEbORIDCV6CnjD7wgcVLoSk09nQqz4Gs=; b=Uw6CaxDvqNqhC/WKHO fLvysxWyjBldbRyCDu/VVsU6ctaF7/fHLjwVG9NRg9NekJ6K76o4SgXYmNuImbAR +jGgbHgll5rPek+MDvllIO168FBKUyJi9Wdq7cuEgDobg9YEOi7cdEZX9uDoPeGl kcbvx98GEkZe8iKpIkHxSi0l3mkEPaQ9oxkXkyr9V2pSBw7Hw8TpIUOBitQRjD1G nI8jSkfSL3sd5IOeUAfQ3C4NXBbxC+RRl7IB8ajUycN7rmc/y7pD+GTDd2WpgyTd X2jNiB0+wyqkeee0LR5bMdphDCLzR9CSJWTlp4Xg+rU29WP4Ed5xDF6JlvJ29VyB V0LQ== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=vtDHPrXZ8QiqEbORIDCV6CnjD7wgcVLoSk09nQqz4 Gs=; b=XYMexm8wLTMpHV29id2HbP4lZTJx2f5MAS4QEX+wBtGlOLtWuBGc5T4l2 Ssw388P93UvE706ubKaPLDOZefuMLwrP3eI3fKNxJ8a0KEnNjMHtTDB4ypExqkRt maHRsGhH2jgfRIJq1MlH01ivm1KSf6o7wlM/te+DJiK45RSzqhkDuOhSP8+J4P2O z2JnfK6xUQIiKZX9/yxfQpYu4xh+K+a0X1wW8364wXG4GIxCxJgKMaALxLGOovHj kzPtvTtSewmdqqClfedMlc4auX9syONY9kQlAli5suNIrp+rD4ShzarLidjOyqFy 3PQ7Lmqeb1twPW3s04bj66cuciU/A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrtdeggdehiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomheptg grfieshhgvrghpihhnghgsihhtshdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7940E3C00A1; Wed, 11 Sep 2019 22:10:02 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-227-g18586b54-fmstable-20190911v1 Mime-Version: 1.0 Message-Id: <6cfd7c22-dbee-4de5-a6b3-2091147e2f3c@www.fastmail.com> In-Reply-To: <645388ABB5D92E33447C55DF@PSB> References: <156816606075.22400.22167404102467671@ietfa.amsl.com> <645388ABB5D92E33447C55DF@PSB> Date: Wed, 11 Sep 2019 19:09:42 -0700 From: "Christopher Wood" To: "John C Klensin" Cc: "secdir@ietf.org" , iesg@ietf.org, draft-klensin-idna-unicode-review.all@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] Secdir last call review of draft-klensin-idna-unicode-review-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 02:10:06 -0000 John, On Wed, Sep 11, 2019, at 3:07 PM, John C Klensin wrote: > Christopher, >=20 > This has already been discussed in the context of another review > but, the tracker showed the review as being due by August 30, > the same date as Last Call closed, until yesterday. It is > important that area reviews appear within the Last Call period > so that others in the community can comment on them. Late > reviews, especially ones that arrive after the IESG evaluation > period starts, are also a bit disrespectful of authors who > struggle to get complete documents posted immediately after IETF > Last Call and before the IESG evaluation period begins so as to > have documents that are as complete as possible before ADs start > their reviews and of those ADs who might have done so. Understood. Things happen. I figured a late review was better than none.= =20 > That said.... >=20 > --On Tuesday, September 10, 2019 18:41 -0700 Christopher Wood > via Datatracker wrote: >=20 > > Reviewer: Christopher Wood > > Review result: Has Nits > >=20 > > This document looks mostly good to go. I only have a few > > questions and some various editorial nits. > >=20 > > Questions: > > - Section 4, last paragraph: Will code points "considered > > unsafe" be labelled as such, and if so, where? In the derived > > property IANA tables? (Assuming those tables are kept.) - >=20 > The document should be clear on this. In particular, the last > sentence of Section 3.2, which, AFAICT, is the first comment in > it about "considered unsafe", says >=20 > 'The affected code points should be considered unsafe > and identified as "under review" in the IANA tables > until final derived properties are assigned.' My point was that "considered unsafe" is not necessarily the same as "un= der review." One can read the latter and conclude the thing is safe, for= example. > That seems very clear to me unless you think the document should > say "... identified as 'unsafe and under review' in the IANA > tables..." or something similar. That, to me, is a tradeoff > against tediousness and against the fairly clear language in the > base IDNA specifications, as well as language in > draft-klensin-idna-5891bis (in Last Call and IESG evaluation > current with this document) that spell out what a zone is > allowed to do with code points that IDNA considers PVALID. =20 A tradeoff indeed! I was merely calling out the possible confusion. > The intent is to give a registry a clear warning that the status of > a code point might change as reviews continue. If there were > community consensus that the issue should be described in more > detail in this document, I assume we would happily change it. > But, because this issue did not come up during IETF Last Call, > there is no time for such a discussion and, IMO, a presumption > that the text is ok. >=20 >=20 > > Section 5, second paragraph: How will the success of this > > document's proposed changes be measured in order to determine > > if further steps towards minimizing confusion are needed? >=20 > First of all, the nature of human languages and writing systems > and their evolution is such that, as characters other than those > from very simple scripts designed for easy recognition (e.g., > Roman script as used in the early Roman Republic) are allowed in > identifiers (including domain name labels), aspirations for zero > confusion are up there with aspirations for perfect security > that cannot be broken by any mechanism now or in the future. > That makes "good enough" subjective, circumstantial, and, to > some extent, dependent on the dedication of the attackers and > resources available to them. But this paragraph is not about > that. It is about the observation that publishing non-normative > tables with IANA, rather than telling people what the rules and > algorithms are and expected them to do their own computation or > relying on tables that are not an IETF responsibility, has > resulted in a good deal of confusion (and some complaints) about > what the true and correct values are. If those complaints now > stop, we are successful. If they continue, then we conclude the > that IANA tables are a bad idea on balance and we drop them. It > occurs to me that your comment about "unsafe and under review" > and the discussion above suggest that, if we decided to get rid > of the IANA tables in their current form, we'd need to find a > place to publish that information. But let's cross that bridge > when and if we get to it. Sure. My underlying point was that use of the word "measure" is not real= ly actionable.=20 > > Nits: > > - Section 2, first paragraph, first sentence: It seems a comma > > is missing after [RFC3491] reference, i.e., "..., commonly > > known as "IDNA2003" [RFC3490] [RFC3491], ...". >=20 > Correct. Working draft fixed. Thanks although I'm confident > the RFC Editor would have caught this.=20 >=20 > > - Section 3, > > second paragraph: s/full Unicode versions/major Unicode > > versions? >=20 > IIR, "full Unicode versions" is Unicode's preferred terminology. > We should check this. >=20 > - Section 3.1: s/also concluded that maintain > > Unicode/also concluded that Unicode? >=20 > Yes. Cut and paste error as that sentence was rewritten several > times. Fixed in working draft. >=20 > > - Section 4, third > > paragraph: Is the requirement that changes which are > > "documented" redundant with the following "explained" > > requirement? (That is, perhaps just say "... must be > > documented and explained." >=20 > It is actually not redundant although I understand why you might > read it that way. Explanation on request if you or some AD > think it is important. >=20 > > - Security Considerations, second > > paragraph: Do "end users" include systems that process or > > interpret Unicode values? If not, it might help to specifically > > call them out, as problems may arise from misinterpretation > > there. >=20 > They do not. "End user" refers to human beings and, perhaps > eventually, robots who are using the Internet as surrogates for > human beings. One of the design goals of IDNA2008 (successfully > realized) was to create a situation in which there simply are no > ambiguities in Unicode strings as they pass through the > protocol. As an overused example, as far as computer systems > processing or interpreting values are concerned, Latin small "a" > (U+0061) is quite distinct from Cyrillic small "=D0=B0" (U+0430) in > all relevant encoding forms including what happens when those > code points are passed through the Punycode algorithm. The > problem occurs only when those characters are displayed to > humans and they can't tell the difference. Hence end users. =20 >=20 > Processes that try to figure out what a human might confuse are > a different story, but they, necessarily, operate off > assumptions about the graphemes associated with particular code > points and not the code points themselves. Hence they are just > not relevant to this document. I don't agree that they're irrelevant, though that's my humble opinion. Best, Chris From nobody Wed Sep 11 22:01:00 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41E812080E for ; Wed, 11 Sep 2019 22:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=netnod-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNMgzQndNSHS for ; Wed, 11 Sep 2019 22:00:55 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::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 32BF9120812 for ; Wed, 11 Sep 2019 22:00:55 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id q22so17687500ljj.2 for ; Wed, 11 Sep 2019 22:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netnod-se.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=hvfn8DJVs0u/f7bXUZZnn2BRcJ4hE6NM/d14HMs2h6c=; b=l3PC+R/eDdG4lRc2pTNyvLai5usge2rcdaz6T+3VtQHLrDsdziNQZJ61UxaaXSs1xC LJYQe87KEuL1jzHMtJB7l65sGPNzAxjhWrE5eXdQHRN4I0nFN1C8MUfN+HTMii47DdsF omAXa9XvOgtCig2Q7ptVUn/1XOa1FDgOPmN7HVRereWdOC1tS4nROag7izD2JqYzUruj rYPq5qkDxer7Ig18QjzXk1qP3myRc1deE+4NNOxiQp//nddxdvYQ/bhXmv5n+6ZpLQcT J54QLAewJgLESOxDfLTgxauNmtKq3aFE776fO1LyPH0Y26DiiiSi3RVLviVlGmtqSmUZ 7f0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=hvfn8DJVs0u/f7bXUZZnn2BRcJ4hE6NM/d14HMs2h6c=; b=jefaO8j/wxYSBjIeKUdu9lRk3cJbxYA9zVHPluleYViBS+QwQWffIrljio/m7jmVux E4KOP74wzhdCFsm5dur+De1w7VUHzLiAW7WOLCqk60oy3+fvfhX+EZyKq6o5DLZfcEVT BCv5r0sjtNP5dFXf9cqiXqOqDv5qep4lDx1om/a2+A05+xO9AZx7untBui94lxXlueJd sEFjts49gRc2+zl9bQzwij4u5dtv/cA+GzTo7aaX8eJhoVWey5EIDR71DxToCfZqMq1d Iolv0W209YA8xLM7vfhbYXHe6Zs3nstBw/sVgTItVAMNORMK74dxyMP/QiCCuKxisqSt m18g== X-Gm-Message-State: APjAAAWOekpPh32/egYhWJMZ6ugeWrEXpBg4s06FZNxWdoartxvhr+If jF/pwzV1MVHHDBf6iWwflINe9g== X-Google-Smtp-Source: APXvYqw126kjTh5VBJ8yqN1zd++3GQ5a7+UV6pmMzb/V7vGFsabojg9mgL0ji9BU4zpPc83Ui4byTg== X-Received: by 2002:a2e:99d7:: with SMTP id l23mr17896287ljj.86.1568264453092; Wed, 11 Sep 2019 22:00:53 -0700 (PDT) Received: from [192.168.10.199] (c-c4b7d954.028-114-73746f27.bbcust.telenor.se. [84.217.183.196]) by smtp.gmail.com with ESMTPSA id b30sm5943885lfq.59.2019.09.11.22.00.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Sep 2019 22:00:52 -0700 (PDT) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "John C Klensin" Cc: "Christopher Wood" , secdir@ietf.org, iesg@ietf.org, draft-klensin-idna-unicode-review.all@ietf.org Date: Thu, 12 Sep 2019 07:00:50 +0200 X-Mailer: MailMate (1.12.5r5635) Message-ID: <46C2335D-4C9E-4D96-B799-D2EC329F670E@netnod.se> In-Reply-To: <645388ABB5D92E33447C55DF@PSB> References: <156816606075.22400.22167404102467671@ietfa.amsl.com> <645388ABB5D92E33447C55DF@PSB> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_73C6C550-5529-4FC7-8BA4-6DB8AE4F7020_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-klensin-idna-unicode-review-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 05:00:58 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_73C6C550-5529-4FC7-8BA4-6DB8AE4F7020_= Content-Type: text/plain On 12 Sep 2019, at 0:07, John C Klensin wrote: >> - Section 3, >> second paragraph: s/full Unicode versions/major Unicode >> versions? > > IIR, "full Unicode versions" is Unicode's preferred terminology. > We should check this. I also thought it was "full" but when checking I see they call it "major": Patrik --=_MailMate_73C6C550-5529-4FC7-8BA4-6DB8AE4F7020_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iGwEARECACwWIQT9vk6hwHOftrJkxVxtJBVNQL09owUCXXnRAg4ccGFmQG5ldG5v ZC5zZQAKCRBtJBVNQL09o4HZAKCjHgtx08Lym6UaNOAzNiRFmVeJnwCfedo/8v84 ko23rwpztYaSgXIH8dg= =IVEg -----END PGP SIGNATURE----- --=_MailMate_73C6C550-5529-4FC7-8BA4-6DB8AE4F7020_=-- From nobody Thu Sep 12 05:23:12 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 120631200DB; Thu, 12 Sep 2019 05:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 HacSTQk3Yg0v; Thu, 12 Sep 2019 05:23:02 -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 E09E8120052; Thu, 12 Sep 2019 05:23:01 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1i8O7m-0001Xp-W7; Thu, 12 Sep 2019 08:22:58 -0400 Date: Thu, 12 Sep 2019 08:22:53 -0400 From: John C Klensin To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= cc: Christopher Wood , secdir@ietf.org, iesg@ietf.org, draft-klensin-idna-unicode-review.all@ietf.org Message-ID: <207ED4272C9D49D9D036E412@PSB> In-Reply-To: <46C2335D-4C9E-4D96-B799-D2EC329F670E@netnod.se> References: <156816606075.22400.22167404102467671@ietfa.amsl.com> <645388ABB5D92E33447C55DF@PSB> <46C2335D-4C9E-4D96-B799-D2EC329F670E@netnod.se> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [secdir] Secdir last call review of draft-klensin-idna-unicode-review-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 12:23:04 -0000 Fixed in working draft. Thanks. And thanks to Christopher for spotting this. john --On Thursday, September 12, 2019 07:00 +0200 Patrik = F=C3=A4ltstr=C3=B6m wrote: > On 12 Sep 2019, at 0:07, John C Klensin wrote: >=20 >>> - Section 3, >>> second paragraph: s/full Unicode versions/major Unicode >>> versions? >>=20 >> IIR, "full Unicode versions" is Unicode's preferred >> terminology. We should check this. >=20 > I also thought it was "full" but when checking I see they call > it "major": >=20 > >=20 > Patrik From nobody Thu Sep 12 09:35:42 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 32759120131 for ; Thu, 12 Sep 2019 09:35:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.101.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <156830613919.16552.1423758334998326192.idtracker@ietfa.amsl.com> Date: Thu, 12 Sep 2019 09:35:39 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 16:35:39 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-09-19 Reviewer LC end Draft Daniel Gillmor 2019-08-27 draft-ietf-lsr-isis-rfc5306bis-05 Leif Johansson 2019-09-02 draft-ietf-tls-sni-encryption-05 Yoav Nir R2019-07-08 draft-ietf-regext-epp-fees-18 Last calls: Reviewer LC end Draft Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Daniel Gillmor 2018-03-19 draft-gutmann-scep-14 Dan Harkins 2019-09-03 draft-ietf-pim-reserved-bits-03 Scott Kelly RNone draft-ietf-rift-rift-08 Scott Kelly 2019-09-18 draft-ietf-dnsop-obsolete-dlv-00 Aanchal Malhotra 2019-09-13 draft-ietf-teas-native-ip-scenarios-08 Catherine Meadows 2019-09-25 draft-ietf-payload-tsvcis-01 Daniel Migault 2019-09-25 draft-ietf-acme-tls-alpn-06 Adam Montville 2019-09-25 draft-ietf-dnsop-serve-stale-07 Kathleen Moriarty 2019-09-23 draft-ietf-isis-yang-isis-cfg-37 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Sandra Murphy 2019-07-08 draft-ietf-i2nsf-applicability-17 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Tim Polk 2019-08-01 draft-ietf-acme-star-08 David Waltermire 2019-08-07 draft-ietf-oauth-jwt-introspection-response-07 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Next in the reviewer rotation: Russ Mundy Sandra Murphy Yoav Nir Magnus Nystrom Hilarie Orman Radia Perlman Derrell Piper Tim Polk Vincent Roca Kyle Rose From nobody Fri Sep 13 08:01:12 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D819120808; Fri, 13 Sep 2019 05:24:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1568377491; bh=Rkpc+pzQgQgPCrE6Qq0FS1vAVEHQxW3/3LQ3buHc4uw=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=NJOCUJi/jmvKkQdefCXIZVTFyhQiUbiFAxXd+kK5B+j+D67btpzWHM5W+on8t3Jv+ 2D7gqYAMHLhzB01CJoWMi9B8mmWbR1oIqVzm6oX5PR2w6ueLph7A3ql0+pIvnuQWjz uSp9qXlx1g/FZQJFYUAi5sDqZC8cf0pjDTiDxKCY= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Sep 13 05:24:51 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BAE1207FD; Fri, 13 Sep 2019 05:24:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1568377491; bh=Rkpc+pzQgQgPCrE6Qq0FS1vAVEHQxW3/3LQ3buHc4uw=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=NJOCUJi/jmvKkQdefCXIZVTFyhQiUbiFAxXd+kK5B+j+D67btpzWHM5W+on8t3Jv+ 2D7gqYAMHLhzB01CJoWMi9B8mmWbR1oIqVzm6oX5PR2w6ueLph7A3ql0+pIvnuQWjz uSp9qXlx1g/FZQJFYUAi5sDqZC8cf0pjDTiDxKCY= 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 719B61207FD for ; Fri, 13 Sep 2019 05:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, 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 lvOWEV3w990q for ; Fri, 13 Sep 2019 05:24:47 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (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 ACCAC120227 for ; Fri, 13 Sep 2019 05:24:47 -0700 (PDT) Received: from [42.100.6.12] (helo=[192.168.1.2]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1i8kd3-0007xk-Nf for new-work@ietf.org; Fri, 13 Sep 2019 12:24:46 +0000 To: new-work@ietf.org From: xueyuan Message-ID: <7ffe0efe-9ebc-2cdf-65a4-cb760cb31fab@w3.org> Date: Fri, 13 Sep 2019 20:24:42 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 13 Sep 2019 08:01:00 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Web of Things Interest Group (until 2019-10-11) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2019 12:24:54 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgV2ViIG9m IFRoaW5ncyBJbnRlcmVzdCBHcm91cDoKIMKgIGh0dHBzOi8vd3d3LnczLm9yZy8yMDE5LzA3L3dv dC1pZy0yMDE5Lmh0bWwKCkFzIHBhcnQgb2YgZW5zdXJpbmcgdGhhdCB0aGUgY29tbXVuaXR5IGlz IGF3YXJlIG9mIHByb3Bvc2VkIHdvcmsKYXQgVzNDLCB0aGlzIGRyYWZ0IGNoYXJ0ZXIgaXMgcHVi bGljIGR1cmluZyB0aGUgQWR2aXNvcnkKQ29tbWl0dGVlIHJldmlldyBwZXJpb2QuCgpXM0MgaW52 aXRlcyBwdWJsaWMgY29tbWVudHMgdGhyb3VnaCAyMDE5LTEwLTExIG9uIHRoZQpwcm9wb3NlZCBj aGFydGVyLiBQbGVhc2Ugc2VuZCBjb21tZW50cyB0bwpwdWJsaWMtbmV3LXdvcmtAdzMub3JnLCB3 aGljaCBoYXMgYSBwdWJsaWMgYXJjaGl2ZToKIMKgIGh0dHA6Ly9saXN0cy53My5vcmcvQXJjaGl2 ZXMvUHVibGljL3B1YmxpYy1uZXctd29yay8KCk90aGVyIHRoYW4gY29tbWVudHMgc2VudCBpbiBm b3JtYWwgcmVzcG9uc2VzIGJ5IFczQyBBZHZpc29yeQpDb21taXR0ZWUgUmVwcmVzZW50YXRpdmVz LCBXM0MgY2Fubm90IGd1YXJhbnRlZSBhIHJlc3BvbnNlIHRvCmNvbW1lbnRzLiBJZiB5b3Ugd29y ayBmb3IgYSBXM0MgTWVtYmVyIFsxXSwgcGxlYXNlIGNvb3JkaW5hdGUKeW91ciBjb21tZW50cyB3 aXRoIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlLiBGb3IKZXhhbXBsZSwg eW91IG1heSB3aXNoIHRvIG1ha2UgcHVibGljIGNvbW1lbnRzIHZpYSB0aGlzIGxpc3QgYW5kCmhh dmUgeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRpdmUgcmVmZXIgdG8gaXQgZnJv bSBoaXMKb3IgaGVyIGZvcm1hbCByZXZpZXcgY29tbWVudHMuCgpUaGUgY3VycmVudCBJbnRlcmVz dCBHcm91cCBjaGFydGVyIFsyXSBoYXMgYWxzbyBiZWVuIGV4dGVuZGVkIHVudGlsIDMxCkRlY2Vt YmVyIDIwMTkgdG8gYWNjb21tb2RhdGUgdGhlIHJldmlldyBieSB0aGUgQWR2aXNvcnkgQ29tbWl0 dGVlLgoKSWYgeW91IHNob3VsZCBoYXZlIGFueSBxdWVzdGlvbnMgb3IgbmVlZCBmdXJ0aGVyIGlu Zm9ybWF0aW9uLCBwbGVhc2UKY29udGFjdCBLYXogQXNoaW11cmEgPGFzaGltdXJhQHczLm9yZz4g YW5kIERhdmUgUmFnZ2V0dCA8ZHNyQHczLm9yZz4sCldlYiBvZiBUaGluZ3MgSW50ZXJlc3QgR3Jv dXAgU3RhZmYgQ29udGFjdHMuCgpUaGFuayB5b3UsCgpYdWV5dWFuIEppYSwgVzNDIE1hcmtldGlu ZyAmIENvbW11bmljYXRpb25zCgpbMV0gaHR0cDovL3d3dy53My5vcmcvQ29uc29ydGl1bS9NZW1i ZXIvTGlzdApbMl0gaHR0cHM6Ly93d3cudzMub3JnLzIwMTYvMDcvd290LWlnLWNoYXJ0ZXIuaHRt bAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV3LXdv cmsgbWFpbGluZyBsaXN0Cm5ldy13b3JrQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV3LXdvcmsK From nobody Fri Sep 13 10:35:46 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1F712011C; Fri, 13 Sep 2019 10:35:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Aanchal Malhotra via Datatracker To: Cc: draft-ietf-teas-native-ip-scenarios.all@ietf.org, ietf@ietf.org, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.101.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Aanchal Malhotra Message-ID: <156839614479.31946.12242901108923524619@ietfa.amsl.com> Date: Fri, 13 Sep 2019 10:35:44 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-teas-native-ip-scenarios-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2019 17:35:45 -0000 Reviewer: Aanchal Malhotra Review result: Ready I have looked at this document as part of the secdir LC review and it looks fine. From nobody Tue Sep 17 13:36:55 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F640120920; Tue, 17 Sep 2019 13:36:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoav Nir via Datatracker To: Cc: ietf@ietf.org, draft-ietf-regext-epp-fees.all@ietf.org, regext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.101.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Yoav Nir Message-ID: <156875259956.17440.16915883379549498946@ietfa.amsl.com> Date: Tue, 17 Sep 2019 13:36:39 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-regext-epp-fees-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 20:36:40 -0000 Reviewer: Yoav Nir Review result: Has Nits The changes in revision -17 are fine. I would still like to have it stated that financial information is not at risk of leaking because the account information of a customer is only sent in communications with that customer. The Security Considerations section already says that encryption is used when transmitting financial information. That is necessary but not sufficient. You also need to state that such information is only sent to entities that should have access to that information. From nobody Wed Sep 18 16:55:56 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE7E1200B3 for ; Wed, 18 Sep 2019 16:55:42 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 93BsldJUtbFj for ; Wed, 18 Sep 2019 16:55:38 -0700 (PDT) Received: from mail-vs1-xe44.google.com (mail-vs1-xe44.google.com [IPv6:2607:f8b0:4864:20::e44]) (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 3F3C2120116 for ; Wed, 18 Sep 2019 16:55:38 -0700 (PDT) Received: by mail-vs1-xe44.google.com with SMTP id p13so1069127vsr.4 for ; Wed, 18 Sep 2019 16:55:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jlZ1D3PjGjtg4tqd5kVd6jccJ1C1VMB7tAIM9nj0tSQ=; b=ehGJ8w1AW3fNUCzLzcc9AzD561B23hsmkYFdVfKDT64fxRYQZyDBQvkdigkH9X2dlg 39CnqvnSmWmvuAa5hp76Y1v+gF++bXxbbaxuogojMYqcvusXBkPH7vI59pigVNfGc31B s7YC6FIlohNBQW/eZI33mwSw3PF6ZIxocEHWk= 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=jlZ1D3PjGjtg4tqd5kVd6jccJ1C1VMB7tAIM9nj0tSQ=; b=DbCF3kXAiH0HVUKbbEsCaSi3fyZU8XVUusCnOfeUPHeLXS7fNVGK5XG/jAt+qyFqpw +V+H4WzGoXrqruo3WTLzHl/+zMNLRNCPSqDJ+tF9f5J/aVKJTm6AM7MD3vFbHzbUdRiy 3SeQqt9USHYrRrcXFShtQAhFknQxfKsM9KkmFjbByLafxUtZeHA0O9ubc+kqC3QEYTjh HIYcvfhTqrx+QQmfq0KMsAk9LcteIvQ47jpY+FEV7Xxdpk7bv8XGZUjBFxQKPBeHdWZp lK8xDo5Fb53ucTZXjB/dt4+5Ql3MYOi2UmPUwBxb9wDZAOsw8+4OPzgv55w5MEYrBnxo bP9g== X-Gm-Message-State: APjAAAWMKJ7jWxZR7frOwmVLtnjo7lrPajXk797cYKYepJ/xxnAR8NSF Ra24euH5DY+bN8kNWvF/CrznKkn7N5wTymr+npjo0g== X-Google-Smtp-Source: APXvYqwTUw8YS3Ng2YaXqWrZ7pNu+XzcKxLktrw11wIhza6HTE7PXiA4oSl80LZg60IBfAM15OFcD+0urSoTXHRUeOg= X-Received: by 2002:a67:ec09:: with SMTP id d9mr3705884vso.215.1568850937064; Wed, 18 Sep 2019 16:55:37 -0700 (PDT) MIME-Version: 1.0 References: <156330717256.15259.2193942101748847069@ietfa.amsl.com> In-Reply-To: <156330717256.15259.2193942101748847069@ietfa.amsl.com> From: Nick Sullivan Date: Wed, 18 Sep 2019 16:55:20 -0700 Message-ID: To: Yaron Sheffer Cc: secdir@ietf.org, draft-ietf-tls-exported-authenticator.all@ietf.org, ietf@ietf.org, "" Content-Type: multipart/alternative; boundary="000000000000cf7b980592dc921b" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-tls-exported-authenticator-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 23:55:43 -0000 --000000000000cf7b980592dc921b Content-Type: text/plain; charset="UTF-8" Hi Yaron, Thank you for your thorough review. My answers will be inline, and I'll incorporate some of Ben's replies if necessary. Here's a PR with proposed changes in response to your comments: https://github.com/tlswg/tls-exported-authenticator/pull/52 On Tue, Jul 16, 2019 at 12:59 PM Yaron Sheffer via Datatracker < noreply@ietf.org> wrote: > Reviewer: Yaron Sheffer > Review result: Has Issues > > The document is generally clear in both its motivation and the proposed > solution. > > I think it's playing a bit too liberal with TLS 1.3, in sort-of but not > quite > deprecating renegotiation, and in changing the IANA registry in a way that > actually changes the protocol. Details below. > > Other comments: > > * Abstract: please reword to make it clear that it's the proof (not the > cert) > that is portable. Proposed text here: This document describes a mechanism in Transport Layer Security (TLS) for peers to provide a proof of ownership of a certificate. This proof can be exported by one peer, transmitted out-of-band to the other peer, and verified by the receiving peer. * Introduction: TLS 1.3 post-handshake auth "has the > disadvantage of requiring additional state to be stored as part of the TLS > state machine." Why is that an issue is practice, assuming this feature is > already supported by TLS libraries? Also, are we in effect deprecating > this TLS > 1.3 feature because of the security issue of the mismatched record > boundaries? > My understanding is that post-handshake authentication as defined in the TLS 1.3 RFC is not implemented in many (any?) TLS 1.3 libraries and some implementors would prefer to use exported authenticators. * "For simplicity, the mechanisms... require", maybe a normative REQUIRE? I'm fine with this. > * Authenticator Request: please clarify that we use the TLS 1.3 format > even when > running on TLS 1.2. Updated, though it might be a bit unnecessary. * Also, I suggest to change "is not encrypted with a > handshake key" which is too specific to "is sent unencrypted within the > normal > TLS-protected data". This specific text is meant to differentiate the wire format of this message from that of the CertificateRequest message, which is encrypted with the handshake key. The specificity is warranted. * Before diving into the detailed messages in Sec. 3, it > would be nice to include a quick overview of the message sequence. There are two message types and three potential sequences. I've added a short overview. > * Sec. 3: > "SHOULD use TLS", change to MUST. There's no way it can work otherwise > anyway. > As Ben noted, this could be any secure channel with equivalent security to TLS, such as QUIC. We shouldn't forbid other secure out-of-band mechanisms. > * "This message reuses the structure to the CertificateRequest message" - > repeats the preceding paragraph. Fixed > * Sec. 4: again, SHOULD use TLS -> MUST. Again, I don't see the need for a MUST here. > * Is > there a requirement for all protocol messages to be sent over a single TLS > connection? If so, please mention it. Certainly this is true for the > Authenticator message that must be sent over a single connection and > cannot be > multiplexed by the high-level protocol. I think this protocol actually > assumes > "nice" transport properties (no message reorder, reliability) that also > require > a single, clean TLS connection. There is no such requirement. Message ordering is managed by the application layer protocol that utilizes exported authenticators. > * Why no authenticator request for servers? > Don't we care about replay? OTOH if the client wants to detect replays, it > would need to keep state on received authenticators, which would be very > messy. > I'm not sure I understand. It's possible to use authenticator requests for servers. * 4.1: when referencing Exporters, mention this is Sec. 7.5 of [TLS1.3]. Added "Sec. 7.5" * The > discussion of Extended Master Secret only applies to TLS 1.2 - please > clarify > that, plus I suggest to reword this paragraph which I find hard to parse. re-worded * > 4.2: "the extensions are chosen from the TLS handshake." - What does it > mean > exactly, and how does an application even know which extensions were used > at > the TLS layer? Reading further, we mention "ClientHello extensions." Maybe > the > authenticator should also include a ClientHello message to indicate > supported > extensions. Assuming we can peek into ClientHello contradicts the hopeful > "even > if it is possible to implement it at the application layer" in Sec. 6. This could be clearer. Effectively, the Certificate message in the Authenticator needs to be constructed in a similar manner to how a Certificate message would be created in a TLS handshake. Namely, it can only contain extensions that were present in either the client hello or a preceding CertificateRequest. You're right that this makes an assumption that the party creating the Authenticator has access to the TLS handshake state. This implies that even if the Authenticator is created in the application space, an additional API needs to be exposed to share that information. * 4.2.1: > the first sentence of the section is incomplete. Fixed > * Can I use TLS 1.3-specific > extensions (oid_filters) if I'm running on a TLS 1.2 connection? Is there a > situation where a certificate is acceptable for TLS 1.3 connections but > not for > TLS 1.2 connections? Yes TLS 1.3-specific extensions are allowed, the CertificateRequest message is TLS 1.3-compatible. > * "using a value derived from the connection secrets" - I > think we should recommend a specific construction here to ensure people do > it > securely. This was a suggestion from the Additional Certificates use case ( https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-05). I'm not sure we should get into the details here. > * 4.2.3: Are we computing HMAC(MAC-key, Hash(a || b || c || d))? If > so, please say so. Yes, I'll put that in. * 4.2.4: "a constant-time comparison" - why is it actually > required, what is the threat? An attacker can do very little because each > authenticator being sent is different. As Ben noted, this was a safety note added during review. > * 5: please say explicitly which > messages are used in this case to construct the authenticator. Re-written. > * 6.1: the > "MUST" is strange in a section that's only supposed to be informative. > Also, > the library may provide this extension (and possibly others) without > requiring > it as input. How else do you propose wording the requirement that this API fail if the connection doesn't support EAs? > * 6.4: "The API MUST return a failure if the > certificate_request_context of the authenticator was used in a previously > validated authenticator." Are we requiring the library to keep previous > contexts for replay protection? If so, please make it explicit. I think this can be a SHOULD based on the burden replay protection places on the implementation. > * 7.1: this is > changing TLS 1.3 by allowing this extension in Cert Request! I think it's a > really bad idea. Better to hack special support to existing libraries, > allowing > this specific extension for this special case, than to change the base > protocol. Otherwise, this document should UPDATE 8446. This is a good point and one that we struggled a bit with during design. We needed to allow SNI in the CertificateRequest message because it can be client-generated in this context. I'd be ok with creating a different extension for this, but it's rather elegant to re-use it in this context. *I'd like to hear some opinions from the working group* on this point > * 8: I think the > Security Considerations is the right place to talk about interaction > between > this protocol and TLS 1.3 (or 1.2) renegotiation. Even if we simply > RECOMMEND > not to do it. Or else explain the use cases where renegotiation is still > useful > if there are any. > I'm not sure this document should be prescriptive about use cases. This doc is providing a new capability that may be leveraged at the application to replace the functionality of existing mechanisms, but I'm not convinced the evaluation of the trade-offs of different mechanisms should be contained in this document. --000000000000cf7b980592dc921b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Yaron,

Thank you for your thoro= ugh review. My answers will be inline, and I'll incorporate=C2=A0some o= f Ben's replies if necessary. Here's a PR with proposed changes in = response to your comments:

<= div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jul 16, 2019 at 12:59 PM Yaron= Sheffer via Datatracker <noreply@ietf.org> wrote:
Reviewer: Yaron Sheffer
Review result: Has Issues

The document is generally clear in both its motivation and the proposed
solution.

I think it's playing a bit too liberal with TLS 1.3, in sort-of but not= quite
deprecating renegotiation, and in changing the IANA registry in a way that<= br> actually changes the protocol. Details below.

Other comments:

* Abstract: please reword to make it clear that it's the proof (not the= cert)
that is portable.

Proposed text here:
=
This document describes a mechanism in Transport Layer Security (TLS) = for peers to
provide a proof of ownership of a certificate.=C2=A0 This p= roof can be exported
by one peer, transmitted out-of-band to the other p= eer, and verified by the receiving peer.

* Introduction: TLS 1.3 post-handsh= ake auth "has the
disadvantage of requiring additional state to be stored as part of the TLS<= br> state machine." Why is that an issue is practice, assuming this featur= e is
already supported by TLS libraries? Also, are we in effect deprecating this= TLS
1.3 feature because of the security issue of the mismatched record boundari= es?

My understanding is that post-hands= hake authentication=C2=A0as defined in the TLS 1.3 RFC is not implemented = in many (any?) TLS 1.3 libraries and some implementors=C2=A0would prefer to= use exported authenticators.

* "For simplicity, the mechanisms... require", maybe a normative = REQUIRE?
I'm fine with this.
=C2=A0
* Authenticator Request: ple= ase clarify that we use the TLS 1.3 format even when
running on TLS 1.2.
=C2=A0Updated, though it might be a bi= t unnecessary.

* Also, I suggest to change "is not encrypted with a
handshake key" which is too specific to "is sent unencrypted with= in the normal
TLS-protected data".
This specific text is meant to d= ifferentiate the wire format of this message from that of the CertificateRe= quest message, which is encrypted with the handshake key. The specificity i= s warranted.

* Before diving into the detailed messages in Sec. 3, it
would be nice to include a quick overview of the message sequence.
There are two message types and three potential sequences. I'v= e added a short overview.
=C2=A0
* Sec. 3:
"SHOULD use TLS", change to MUST. There's no way it can work = otherwise anyway.
As Ben noted, this could be any secu= re channel with equivalent security to TLS, such as QUIC. We shouldn't = forbid other secure out-of-band mechanisms.
=C2=A0
* "This message reuses the structure to the CertificateRequest message= " -
repeats the preceding paragraph.
Fixed
=C2=A0
* Sec. 4: again, SHOUL= D use TLS -> MUST.
Again, I don't see the need for = a MUST here.
=C2=A0
* Is
there a requirement for all protocol messages to be sent over a single TLS<= br> connection? If so, please mention it. Certainly this is true for the
Authenticator message that must be sent over a single connection and cannot= be
multiplexed by the high-level protocol. I think this protocol actually assu= mes
"nice" transport properties (no message reorder, reliability) tha= t also require
a single, clean TLS connection.
There is no such requireme= nt. Message ordering is managed by the application layer protocol that util= izes exported authenticators.
=C2=A0
* Why no authenticator request for servers?
Don't we care about replay? OTOH if the client wants to detect replays,= it
would need to keep state on received authenticators, which would be very me= ssy.
I'm not sure I understand. It's possib= le to use authenticator requests for servers.

* 4.1: when referencing Exporters,= mention this is Sec. 7.5 of [TLS1.3].
Added=C2=A0 "S= ec. 7.5"

* The
discussion of Extended Master Secret only applies to TLS 1.2 - please clari= fy
that, plus I suggest to reword this paragraph which I find hard to parse.
re-worded

*
4.2: "the extensions are chosen from the TLS handshake." - What d= oes it mean
exactly, and how does an application even know which extensions were used a= t
the TLS layer? Reading further, we mention "ClientHello extensions.&qu= ot; Maybe the
authenticator should also include a ClientHello message to indicate support= ed
extensions. Assuming we can peek into ClientHello contradicts the hopeful &= quot;even
if it is possible to implement it at the application layer" in Sec. 6.=

This could be clearer. Effectively, the Ce= rtificate message in the Authenticator needs
to be constructed in= a similar manner to how a Certificate message would be created
i= n a TLS handshake. Namely, it can only contain extensions that were present= in either
the client hello or a preceding=C2=A0CertificateReques= t.

You're right that this makes an assumption = that the party creating the Authenticator
has access to the TLS h= andshake state. This implies that even if the Authenticator
is cr= eated in the application space, an additional API needs to be exposed to sh= are
that information.

* 4.2.1:
the first sentence of the section is incomplete.

Fixed
=C2=A0
* Can I use TLS 1.3-specific
extensions (oid_filters) if I'm running on a TLS 1.2 connection? Is the= re a
situation where a certificate is acceptable for TLS 1.3 connections but not= for
TLS 1.2 connections?
Yes TLS 1.3-specific extensions are a= llowed, the CertificateRequest message is TLS 1.3-compatible.
=C2= =A0
* "using a = value derived from the connection secrets" - I
think we should recommend a specific construction here to ensure people do = it
securely.
This was a suggestion from the Additional Certif= icates use case (https://tools.ietf.org/html/draft-bishop-httpb= is-http2-additional-certs-05). I'm not sure we should get into the = details here.
=C2=A0
* 4.2.3: Are we computing HMAC(MAC-key, Hash(a || b || c || d))?= If
so, please say so.
Yes, I'll put that in.
* 4.2.4: "a = constant-time comparison" - why is it actually
required, what is the threat? An attacker can do very little because each authenticator being sent is different.
As Ben noted, this = was a safety note added during review.
=C2=A0
* 5: please say explicitly which
messages are used in this case to construct the authenticator.
=

Re-written.=C2=A0
* 6.1: the
"MUST" is strange in a section that's only supposed to be inf= ormative. Also,
the library may provide this extension (and possibly others) without requir= ing
it as input.
How else do you propose wording the requireme= nt that this API fail if the connection doesn't support EAs?
= =C2=A0
* 6.4: "= The API MUST return a failure if the
certificate_request_context of the authenticator was used in a previously validated authenticator." Are we requiring the library to keep previou= s
contexts for replay protection? If so, please make it explicit.
I think this can be a SHOULD based on the burden replay protection pl= aces on the implementation.=C2=A0
=C2=A0
*=C2=A0 7.1: this is
changing TLS 1.3 by allowing this extension in Cert Request! I think it'= ;s a
really bad idea. Better to hack special support to existing libraries, allo= wing
this specific extension for this special case, than to change the base
protocol. Otherwise, this document should UPDATE 8446.
This is a good point and one that we struggled a bit with durin= g design. We needed to allow SNI in the CertificateRequest message because = it can be client-generated in this context. I'd be ok with creating a d= ifferent extension for this, but it's rather elegant to re-use it in th= is context. I'd like to hear some opinions from the working group on this point
=C2=A0
* 8: I think the
Security Considerations is the right place to talk about interaction betwee= n
this protocol and TLS 1.3 (or 1.2) renegotiation. Even if we simply RECOMME= ND
not to do it. Or else explain the use cases where renegotiation is still us= eful
if there are any.

I'm not sure this= document should be prescriptive about use cases. This doc is providing a n= ew capability that may be leveraged at the application to replace the funct= ionality of existing mechanisms, but I'm not convinced the evaluation o= f the trade-offs of different mechanisms should be contained in this docume= nt.
--000000000000cf7b980592dc921b-- From nobody Wed Sep 18 18:34:12 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081B11200B2; Wed, 18 Sep 2019 18:34:05 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 AOkbuQETzE6V; Wed, 18 Sep 2019 18:34:03 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 CBD1E1200C1; Wed, 18 Sep 2019 18:34:02 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x8J1XxIk014251; Wed, 18 Sep 2019 21:33:59 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x8J1XxIk014251 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1568856839; bh=ZffohvKqma/demrIP5sX1VvNBs4ZjPalcmV20y3bCeM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=C0eskMffR9XmoOCgk95S4ZWZ98BEhRCvPvkSU5iJslVhBmR5BM723QOqDkKzWqx/i 7ExXPWEXdjvymxpqh510fcQggtBXn2fAHMzcKroge/cV1Gk7PK23pJJNYgarVrLSaC bZwkbzvnPrUqojzeWLII+BeAmTuZsF2I7m9ctksk= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x8J1XsDL022625; Wed, 18 Sep 2019 21:33:55 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0468.000; Wed, 18 Sep 2019 21:33:54 -0400 From: Roman Danyliw To: Christopher Wood CC: "draft-klensin-idna-unicode-review.all@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" , John C Klensin Thread-Topic: Secdir last call review of draft-klensin-idna-unicode-review-03 Thread-Index: AQHVaEH/YDzEV8R3oEqn9r7Ub+ZpwqcnTR4AgABDswCACq7ooA== Date: Thu, 19 Sep 2019 01:33:54 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B345E934@marathon> References: <156816606075.22400.22167404102467671@ietfa.amsl.com> <645388ABB5D92E33447C55DF@PSB> <6cfd7c22-dbee-4de5-a6b3-2091147e2f3c@www.fastmail.com> In-Reply-To: <6cfd7c22-dbee-4de5-a6b3-2091147e2f3c@www.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-klensin-idna-unicode-review-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2019 01:34:05 -0000 SGkhDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaWVzZyBbbWFpbHRv Omllc2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlzdG9waGVyIFdvb2QNCj4g U2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTEsIDIwMTkgMTA6MTAgUE0NCj4gVG86IEpvaG4g QyBLbGVuc2luIDxqb2huLWlldGZAamNrLmNvbT4NCj4gQ2M6IGRyYWZ0LWtsZW5zaW4taWRuYS11 bmljb2RlLXJldmlldy5hbGxAaWV0Zi5vcmc7IGllc2dAaWV0Zi5vcmc7DQo+IHNlY2RpckBpZXRm Lm9yZw0KPiBTdWJqZWN0OiBSZTogU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQta2xl bnNpbi1pZG5hLXVuaWNvZGUtcmV2aWV3LTAzDQo+IA0KPiBKb2huLA0KPiANCj4gT24gV2VkLCBT ZXAgMTEsIDIwMTksIGF0IDM6MDcgUE0sIEpvaG4gQyBLbGVuc2luIHdyb3RlOg0KPiA+IENocmlz dG9waGVyLA0KPiA+DQo+ID4gVGhpcyBoYXMgYWxyZWFkeSBiZWVuIGRpc2N1c3NlZCBpbiB0aGUg Y29udGV4dCBvZiBhbm90aGVyIHJldmlldyBidXQsDQo+ID4gdGhlIHRyYWNrZXIgc2hvd2VkIHRo ZSByZXZpZXcgYXMgYmVpbmcgZHVlIGJ5IEF1Z3VzdCAzMCwgdGhlIHNhbWUgZGF0ZQ0KPiA+IGFz IExhc3QgQ2FsbCBjbG9zZWQsIHVudGlsIHllc3RlcmRheS4gIEl0IGlzIGltcG9ydGFudCB0aGF0 IGFyZWENCj4gPiByZXZpZXdzIGFwcGVhciB3aXRoaW4gdGhlIExhc3QgQ2FsbCBwZXJpb2Qgc28g dGhhdCBvdGhlcnMgaW4gdGhlDQo+ID4gY29tbXVuaXR5IGNhbiBjb21tZW50IG9uIHRoZW0uICBM YXRlIHJldmlld3MsIGVzcGVjaWFsbHkgb25lcyB0aGF0DQo+ID4gYXJyaXZlIGFmdGVyIHRoZSBJ RVNHIGV2YWx1YXRpb24gcGVyaW9kIHN0YXJ0cywgYXJlIGFsc28gYSBiaXQNCj4gPiBkaXNyZXNw ZWN0ZnVsIG9mIGF1dGhvcnMgd2hvIHN0cnVnZ2xlIHRvIGdldCBjb21wbGV0ZSBkb2N1bWVudHMg cG9zdGVkDQo+ID4gaW1tZWRpYXRlbHkgYWZ0ZXIgSUVURiBMYXN0IENhbGwgYW5kIGJlZm9yZSB0 aGUgSUVTRyBldmFsdWF0aW9uIHBlcmlvZA0KPiA+IGJlZ2lucyBzbyBhcyB0byBoYXZlIGRvY3Vt ZW50cyB0aGF0IGFyZSBhcyBjb21wbGV0ZSBhcyBwb3NzaWJsZSBiZWZvcmUNCj4gPiBBRHMgc3Rh cnQgdGhlaXIgcmV2aWV3cyBhbmQgb2YgdGhvc2UgQURzIHdobyBtaWdodCBoYXZlIGRvbmUgc28u DQo+IA0KPiBVbmRlcnN0b29kLiBUaGluZ3MgaGFwcGVuLiBJIGZpZ3VyZWQgYSBsYXRlIHJldmll dyB3YXMgYmV0dGVyIHRoYW4gbm9uZS4NCg0KQWdyZWVkLiAgUmV2aWV3cyB0aW1lZCB3aXRoaW4g dGhlIElFVEYgTEMgd291bGQgYmUgaWRlYWwuICBIb3dldmVyLCBldmVuIGEgbGF0ZSByZXZpZXcs IGZvciB0aGlzIHZvbHVudGVlciByb2xlIGluIHNlY2RpciwgaXMgc3RpbGwgdmVyeSBoZWxwZnVs LiAgVGhhbmsgeW91IENocmlzISANCg0KUmVnYXJkcywNClJvbWFuDQoNCg== From nobody Thu Sep 19 05:51:10 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC9B120132 for ; Thu, 19 Sep 2019 05:51:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.101.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <156889746877.4654.13775142499114515485.idtracker@ietfa.amsl.com> Date: Thu, 19 Sep 2019 05:51:08 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2019 12:51:09 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-09-19 Reviewer LC end Draft Daniel Gillmor 2019-08-27 draft-ietf-lsr-isis-rfc5306bis-07 Dan Harkins 2019-09-03 draft-ietf-pim-reserved-bits-03 Leif Johansson 2019-09-02 draft-ietf-tls-sni-encryption-06 Last calls: Reviewer LC end Draft Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Daniel Gillmor 2018-03-19 draft-gutmann-scep-14 Scott Kelly 2019-09-18 draft-ietf-dnsop-obsolete-dlv-00 Catherine Meadows 2019-09-25 draft-ietf-payload-tsvcis-01 Daniel Migault 2019-09-25 draft-ietf-acme-tls-alpn-06 Adam Montville 2019-09-25 draft-ietf-dnsop-serve-stale-08 Kathleen Moriarty 2019-09-23 draft-ietf-isis-yang-isis-cfg-37 Russ Mundy 2019-09-27 draft-ietf-core-hop-limit-05 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Sandra Murphy None draft-ietf-mpls-ldp-yang-06 Sandra Murphy 2019-07-08 draft-ietf-i2nsf-applicability-18 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Tim Polk 2019-08-01 draft-ietf-acme-star-09 David Waltermire 2019-08-07 draft-ietf-oauth-jwt-introspection-response-07 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Scott Kelly R2019-10-31 draft-ietf-rift-rift-08 Next in the reviewer rotation: Yoav Nir Magnus Nystrom Hilarie Orman Radia Perlman Derrell Piper Tim Polk Vincent Roca Kyle Rose Joseph Salowey Rich Salz From nobody Thu Sep 19 12:14:27 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD4A120121; Thu, 19 Sep 2019 12:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cS6fo5gcSayu; Thu, 19 Sep 2019 12:14:17 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 EFE78120114; Thu, 19 Sep 2019 12:14:16 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-93-158-174.san.res.rr.com [76.93.158.174]) by wwwlocal.goatley.com (PMDF V6.8-0 #1001) with ESMTP id <0PY3001BDERSFH@wwwlocal.goatley.com>; Thu, 19 Sep 2019 14:14:16 -0500 (CDT) Received: from Dans-MacBook-Pro.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0PY300IC8EOXNY@trixy.bergandi.net>; Thu, 19 Sep 2019 12:12:35 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Thu, 19 Sep 2019 12:12:35 -0700 Date: Thu, 19 Sep 2019 12:14:13 -0700 From: Dan Harkins To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-pim-reserved-bits.all@ietf.org Message-id: <76082dca-0ffd-452b-42fd-732920b66221@lounge.org> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Pkfq1q03WF2nC5XAKCq/yw)" Content-language: en-US User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO Dans-MacBook-Pro.local) X-PMAS-Software: PreciseMail V3.3 [190918] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: [secdir] secdir review of draft-ietf-pim-reserved-bits-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2019 19:14:19 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Pkfq1q03WF2nC5XAKCq/yw) Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 8BIT   First of all, I apologize for the tardiness of this review; my bad. Now onto the boilerplate: 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-(late)-Nits The nits are as follows:   - instead of refering to a bit as the one that "follows" a field or is     "right in front of" a field I suggest saying the bit is "adjacent"     to the field.   - it's not clear how this document updates RFC 6754. Type 11 still has     8 reserved bits, nothing changes. The Security Considerations are very light but that seems fine given that the document is just codifying existing practice (sections 4.1 to 4.4) and future-proofing (section 5) a limited resource.   regards,   Dan. --Boundary_(ID_Pkfq1q03WF2nC5XAKCq/yw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: 8BIT  
  First of all, I apologize for the tardiness of this review; my bad.
Now onto the boilerplate:
    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-(late)-Nits
The nits are as follows:

  - instead of refering to a bit as the one that "follows" a field or is
    "right in front of" a field I suggest saying the bit is "adjacent"
    to the field.

  - it's not clear how this document updates RFC 6754. Type 11 still has
    8 reserved bits, nothing changes.

The Security Considerations are very light but that seems fine given that
the document is just codifying existing practice (sections 4.1 to 4.4) and
future-proofing (section 5) a limited resource.

  regards,

  Dan.


 --Boundary_(ID_Pkfq1q03WF2nC5XAKCq/yw)-- From nobody Mon Sep 23 15:24:42 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2007A1200DF; Mon, 23 Sep 2019 15:24:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Montville via Datatracker To: Cc: dnsop@ietf.org, ietf@ietf.org, draft-ietf-dnsop-serve-stale.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.102.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Montville Message-ID: <156927748004.17176.13716791809578495002@ietfa.amsl.com> Date: Mon, 23 Sep 2019 15:24:40 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-dnsop-serve-stale-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 22:24:40 -0000 Reviewer: Adam Montville 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. At first I was confused about offering an option to allow use of stale DNS data, but after reading the draft and realizing that the decision is still left to the operator, this draft is OK. The draft brings up-to-date the definition of TTL and offers additional specification on interpreting specific TTL values. Perhaps some expansion as to the prevalence of bad actors using the caches and fraudulently issued, domain-validated certificates in the Security Considerations section is warranted. Nevertheless, it appears that implementations have been fielded and in use operationally for quite some time, presumably without a problem, and, as previously stated, operators don't have to enable this functionality unless they warrant availability of their services to be paramount. From nobody Tue Sep 24 07:00:36 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E5A120810; Tue, 24 Sep 2019 07:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IESEuS9XbfH; Tue, 24 Sep 2019 06:59:59 -0700 (PDT) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 68D0E12080C; Tue, 24 Sep 2019 06:59:59 -0700 (PDT) Received: by mail-ua1-x92c.google.com with SMTP id b14so584178uap.6; Tue, 24 Sep 2019 06:59:59 -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=UTohYUTEEBCMaa+hS13GfTRALU1fBtIrEREBQKsW+Gs=; b=Rycd0mtNQL+1Ul7NCYMHIoNK/3TaOoTe86DgVN76eADgYiNqU+3gP69GrDHhGFknKW rhofVWW1q3ulz0yd2CzkcaMH7AZO9gwKHGD2KJXTw6v4R+qk0tZ2UGzHiqwA28SX+GxY C+LlN5d0BVOEeSeJIPtz9amqZf5Kn0y4hEuuAinboznXuE5KKHKa0WZarl6W0E8IaTpD WbWcFrMDxKfgCOcsl2gvZEHte2YM4JSSkM/KHrarhUlkCDyNR6S33pdAJzPzP6/ZyPjn OD4BxfdTPPNjqmSlxWcl1HhIacYiAiJ7gVhSthw9k+/IQR/oHUr0mOeT03Uxbk1/8PoC RSnA== 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=UTohYUTEEBCMaa+hS13GfTRALU1fBtIrEREBQKsW+Gs=; b=tcCdypWiXo1FmsdoY3rCIGjvOjeTjv63V6AEseNDkHTkZFwQ8Uh/npdh7/B8Stbnls EoQEabLP/UR+73UKNcNGEkwTbPs46QYgSPguvmUVjnvkSGpikOwhRxa/rKmtPEFFpstd ra8o72/W5gJDFhmi1apadCm3+7mISGZjxko8z6e2CLTREkPxV0cOG72z2MvKwkpHTFXN ZKt9udvrhthfqiVhszmtQDLs6ywScL50FahtiM/0Z8tKnYqahMd86IkSM015iYUDb7bB NQOFAknQX2jc7nPd+3/+N+uUk0pZdUkZHfGTBaR4LOLo5+PJpiU/SeHb9CY7n+z+EK/f ISsQ== X-Gm-Message-State: APjAAAV7FmYBqObOmHV+6UjnctrsULacVTsgiGGV7pMN1NpAuphxZ63k 9H1vZsUibzVrYgZPQ61043kUE4gSN0+fQNEbW1mymzYJo48= X-Google-Smtp-Source: APXvYqzTE0+Thgip3snH1PKDGUYqBDpOI88qs+w2pl4G5ymHWGAGeUALl3OZpur2nkd1uDKxCi6bOTMfQLSGbWR0K4Y= X-Received: by 2002:ab0:30d4:: with SMTP id c20mr1474160uam.136.1569333597974; Tue, 24 Sep 2019 06:59:57 -0700 (PDT) MIME-Version: 1.0 References: <156933292629.15651.2153181471854597685@ietfa.amsl.com> In-Reply-To: <156933292629.15651.2153181471854597685@ietfa.amsl.com> From: "Ori Finkelman (IETF)" Date: Tue, 24 Sep 2019 16:59:41 +0300 Message-ID: To: "" , draft-ietf-cdni-request-routing-extensions.all@ietf.org Cc: Dan Romascanu , gen-art@ietf.org, ops-dir@ietf.org, Zitao Wang , Linda Dunbar , secdir@ietf.org, Barry Leiba , drafts-lastcall@iana.org, Ben Niven-Jenkins , =?UTF-8?Q?Michael_T=C3=BCxen?= , tsv-art@ietf.org Content-Type: multipart/alternative; boundary="000000000000a4350705934cf3b1" Archived-At: Subject: [secdir] Fwd: [CDNi] I-D Action: draft-ietf-cdni-request-routing-extensions-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 14:00:04 -0000 --000000000000a4350705934cf3b1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All, This submission fixes the comments from all reviewers, I would like to thank all reviewers for taking the time and sharing their comments. Please note the diff should be against revision 05 rather than 06 as most of the changes were submitted in 06. Here is the full list of comments that were fixed in this version: =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=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=3D=3D=3D=3D=3D=3D=3D **************************************************************** Reviewer: Barry Leiba (AD) 1. Please use the new BCP 14 boilerplate and references: see RFC 8174. >> fixed 2. Abstract vs Introduction: The sentence about the SVA seems out of place in the Abstract, and is oddly missing from the Introduction. I would add the first two sentences of the Abstract to the Introduction. Then remove the first sentence from the Abstract and also remove =E2=80=9CI= n that aspect,=E2=80=9D from the second sentence. >> fixed 3. RFC 6707 defines necessary terminology, so it probably should be normative. I will note a downref in the last-call notice in anticipation of that. >> fixed *************************************************** Reviewer: Dan Romascanu (Genart) 1. Several non-obvious acronyms are not expanded: FCI, FQDN >> fixed and removed the ones not used 2. Section 3 - typo in the first paragraph '...the uCDN MUST be differnet ...' >> fixed ************************************************* Reviewer: Zitao Wang (Opsdir) #1: There are a lot of abbreviations that are not provided with explanations or citations, such as uCDN, dCDN, CFI, etc. >> fixed and remove the ones not necessary #2: The example of of a Redirect Target capability object serialization, is it encoded as json? Please present its encoding format. >> fixed #3: In section 2.1, the "Mandatory-to-Specify" attributes of dns-target and http-target, it describes that "No, but at least one of dns-target or http-target MUST be present and non-empty." I wonder whether there should be a detection mechanism. For example, if the requirements are not met, an error message will be returned. And if there are existing mechanisms, please briefly introduce them. >> That one is a great catch, thanks. I have changed it so it is not an error anymore. Instead we have defined a default behavior for the case it is not present or empty, see the fixed draft. ****************************************************************** Reviewer: Linda Dunbar (Secdir) The terminology RR (Request Router) and CP (Content Provider) specified by the Terminology are not used for the entire document. I assume that RR would be the one request content, isn't? is RR same as Client? Is RR part of Downstream CDN Provider? is the CP same as Downstream CDN provider or Upstream CDN Provider? >> In the new version RR appears in a few locations. I have added more explanations and references to the relevant CDNI docs where it was defined. who issued the Redirect Target? It would be good for the document to clearly specify the relationship of al= l the entities, such as who makes request and who respond, and who use the Redirect Target capability, etc. >> we have added drawings of sequences that explain it all, I hope it will be clearer now. ******************************************************************* Reviewer: Michael T=C3=BCxen (Tsvart) To improve readability, you might want to * resolve acronyms on first occurence like CDN, CDNI,... >> fixed * Remove section 1.1, since the introduced abbreviations are not used in the text. >> fixed * add a graphical representation of the involved nodes and the messages being exchanged between them >> Added sequence diagrams sections for both extensions. Typos: * Section 3: the uCDN provide a fallback -> the uCDN provides a fallback * Section 6: Nir B. Sopher -> Nir B. Sopher (no double space after period) * Section 6: Kevin J. Ma -> Kevin J. Ma (no double space after period) >> fixed ******************************************************************* Reviewer: Ben Niven-Jenkins (CDNI) Is there a reason that IPv6 addresses (AAAA records) are excluded from being allowed as DnsTargets, or is this an oversight? >> fixed. references to ipv6 and AAAA record were added in the relevant places. ******************************************************************* Thanks, Ori ---------- Forwarded message --------- From: Date: Tue, Sep 24, 2019 at 4:49 PM Subject: [CDNi] I-D Action: draft-ietf-cdni-request-routing-extensions-07.txt To: Cc: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Delivery Networks Interconnection WG of the IETF. Title : CDNI Request Routing Extensions Authors : Ori Finkelman Sanjay Mishra Filename : draft-ietf-cdni-request-routing-extensions-07.txt Pages : 17 Date : 2019-09-24 Abstract: Open Caching is a use case of Content Delivery Networks Interconnetion (CDNI) in which the commercial Content Delivery Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer serves as the downstream CDN (dCDN). The extensions specified in this document to the CDNI Metadata and FCI interfaces are derived from requirements raised by Open Caching but are also applicable to CDNI use cases in general. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-request-routing-extensions= / There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cdni-request-routing-extensions-07 https://datatracker.ietf.org/doc/html/draft-ietf-cdni-request-routing-exten= sions-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-request-routing-extensi= ons-07 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --000000000000a4350705934cf3b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,
This submission fixes th= e comments from all reviewers, I would like to thank all reviewers for taki= ng the time and sharing their comments.
Please note the diff shou= ld be against revision 05 rather than 06 as most of the changes were submit= ted in 06.=C2=A0


Here is the full l= ist of comments that were fixed in this version:
=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=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=3D=3D=3D=3D=3D=3D=3D

**= **************************************************************
Re= viewer: Barry Leiba (AD)


1. Please use the new BCP 14 boilerplate and references: see RFC 8174.
= >> fixed

2. Abstract vs = Introduction:=C2=A0 The sentence about the SVA seems out of
place in the= Abstract, and is oddly missing from the Introduction.=C2=A0 I
would add= the first two sentences of the Abstract to the Introduction.
Then remov= e the first sentence from the Abstract and also remove =E2=80=9CIn
that = aspect,=E2=80=9D from the second sentence.

>> fixed

3. RFC 6707 defines necessary= terminology, so it probably should be
normative.=C2=A0 I will note a do= wnref in the last-call notice in
anticipation of that.
>> fixed


************************************= ***************
Reviewer: Dan Romascanu (Genart)

1= . Several non-obvious acronyms are not expanded: FCI, FQDN
>> fixed and removed the ones not used
2. Sect= ion 3 - typo in the first paragraph '...the uCDN MUST be differnet ...&= #39;
>> fixed

=
*************************************************
Revi= ewer: Zitao Wang (Opsdir)

#1: There are a lot = of abbreviations that are not provided with explanations or
citations, s= uch as uCDN, dCDN, CFI, etc.
>> fix= ed and remove the ones not necessary

#2: The example of of a = Redirect Target capability object serialization, is it
encoded as json? = Please present its encoding format.
>&= gt; fixed

#3: In section 2.1, the "Mandatory-to-Specify&= quot; attributes of dns-target and
http-target, it describes that "= No, but at least one of dns-target or
http-target MUST be present and no= n-empty." I wonder whether there should be a
detection mechanism. F= or example, if the requirements are not met, an error
message will be re= turned. And if there are existing mechanisms, please briefly
introduce t= hem.

>> That one is = a great catch, thanks. I have changed it so it is not an error anymore. Ins= tead we have defined a default behavior=C2=A0for the case=C2=A0
it is not present or empty, see the fixed dra= ft.

********= **********************************************************
Review= er: Linda Dunbar (Secdir)

The terminology RR (Request=C2=A0Router) and CP (Content Provider) specified by the
Terminology= are not used for the entire document. I assume that RR would be the
one= =C2=A0= request=C2=A0content, isn't? is RR same as Client?=C2=A0 Is RR p= art of Downstream CDN
Provider? is the CP same as Downstream CDN provide= r or Upstream CDN Provider?

>&= gt; In the new version RR appears in a few locations. I have added more exp= lanations and references to the relevant CDNI docs where it was defined.=C2= =A0

who issued the Redirect Target?

It would be good f= or the document to clearly specify the relationship of all
the entities,= such as who makes=C2=A0request=C2=A0and who respond, and who use the
R= edirect Target capability, etc.

>>=C2=A0we=C2=A0have added drawings of sequences that expla= in it all, I hope it will be clearer now.

=
****************************************************************= ***
Reviewer: Michael T=C3=BCxen (Tsvart)

To improve readability, you might want to
* resolve acronyms on first = occurence like CDN,=C2=A0CDNI,...
>> fixed
* Remove section 1.1, since t= he introduced abbreviations are not used in the text.
>> fixed
* add a graphical representation of t= he involved nodes and the messages being exchanged between them
<= font color=3D"#0000ff">>> Added sequence diagrams sections for both e= xtensions.=C2=A0

Typos:
* Section 3: the uCDN provide a fa= llback -> the uCDN provides a fallback
* Section 6: Nir B.=C2=A0 Soph= er -> Nir B. Sopher (no double space after period)
* Section 6: Kevin= J.=C2=A0 Ma -> Kevin J. Ma (no double space after period)
>> fixed

***= ****************************************************************
= Reviewer: Ben Niven-Jenkins (CDNI)

Is there a reas= on that IPv6 addresses (AAAA records) are excluded from being allowed as Dn= sTargets, or is this an oversight?

>> fixed. references to ipv6 and AAAA record were added = in the relevant places.

****************************= ***************************************

Thanks,
Ori


---------- Forwarded message ---------
From: &l= t;internet-dr= afts@ietf.org>
Date: Tue, Sep 24, 2019 at 4:49 PM
Subje= ct: [CDNi] I-D Action: draft-ietf-cdni-request-routing-extensions-07.txtTo: <i-d-an= nounce@ietf.org>
Cc: <cdni@ietf.org>



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Content Delivery Networks Interconnection = WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= CDNI Request Routing Extensions
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Ori = Finkelman
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Sanjay Mishra
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-cdni-request-routing-extensions-07.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 17
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-09-24

Abstract:
=C2=A0 =C2=A0Open Caching is a use case of Content Delivery Networks
=C2=A0 =C2=A0Interconnetion (CDNI) in which the commercial Content Delivery=
=C2=A0 =C2=A0Network (CDN) is the upstream CDN (uCDN) and the ISP caching l= ayer
=C2=A0 =C2=A0serves as the downstream CDN (dCDN).=C2=A0 The extensions spec= ified in
=C2=A0 =C2=A0this document to the CDNI Metadata and FCI interfaces are deri= ved
=C2=A0 =C2=A0from requirements raised by Open Caching but are also applicab= le to
=C2=A0 =C2=A0CDNI use cases in general.



The IETF datatracker status page for this draft is:
https://datatracker.ietf= .org/doc/draft-ietf-cdni-request-routing-extensions/

There are also htmlized versions available at:
https://tools.ietf.org/html= /draft-ietf-cdni-request-routing-extensions-07
https://datatrack= er.ietf.org/doc/html/draft-ietf-cdni-request-routing-extensions-07

A diff from the previous version is available at:
https://www.ietf.or= g/rfcdiff?url2=3Ddraft-ietf-cdni-request-routing-extensions-07


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni
--000000000000a4350705934cf3b1-- From nobody Tue Sep 24 08:16:34 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C88E12091C; Tue, 24 Sep 2019 08:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JptCPWNcqCYD; Tue, 24 Sep 2019 08:16:02 -0700 (PDT) Received: from mail-io1-f51.google.com (mail-io1-f51.google.com [209.85.166.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67EE5120905; Tue, 24 Sep 2019 08:16:02 -0700 (PDT) Received: by mail-io1-f51.google.com with SMTP id n197so5305963iod.9; Tue, 24 Sep 2019 08:16:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=EEY7mJjR2nvgM+On/P/dXUcp+AvuPES5KLGYwcfcsoQ=; b=cLG22WsfBwe1i1S26pMIM2h+6uCuq1I4hfP2qZL9+zxYSUMwI/39WChry/eCCnqT2J 53WsMNzG0EuoAalhPXRht0nD9PFsR5SzyK0qNZl619B53ez72ee8CDKU+PnT7Dl8sVX4 NS/CR6i+DHTSQ7WiTA9W7Eb8UFcnMN6GIEazr8l9Osg4B6HAUPQi13+u3TvSzwQBkoFe 2FsPWlS01ubaagpt+yVazMLXYE4vmOAC2GLrebAHZSGVe7vpJpExizQHlhGNk7IDhXmy ou7Lf2bmXxmsOkk1GAPyux9pwUeW/7EV58dS/4S51Eqd9YxmC8SI2GFIfHPNGoof7DJX E7qg== X-Gm-Message-State: APjAAAW6XSocQYJXFmuSXzkunLhwjeGczVRqpyuxgMnbDEQB+UWdw+uv Mo2y96sTT9cy/6Z7DVHwwGR66dqqIUXpeDZsYcp/NQ== X-Google-Smtp-Source: APXvYqyq8/++j+Lg09TyJKfnL/fMInIcZws4VvfBSYA4tg9GrtCYhN5CQtEoUHmTMyPmsG/14IseqU0ilgTfAN49D1I= X-Received: by 2002:a02:608:: with SMTP id 8mr4321441jav.88.1569338161072; Tue, 24 Sep 2019 08:16:01 -0700 (PDT) MIME-Version: 1.0 References: <156933292629.15651.2153181471854597685@ietfa.amsl.com> In-Reply-To: From: Barry Leiba Date: Tue, 24 Sep 2019 11:15:49 -0400 Message-ID: To: draft-ietf-cdni-request-routing-extensions.all@ietf.org Cc: "" , Dan Romascanu , General Area Review Team , ops-dir@ietf.org, Zitao Wang , Linda Dunbar , IETF SecDir , Ben Niven-Jenkins , =?UTF-8?Q?Michael_T=C3=BCxen?= , tsv-art@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] [CDNi] I-D Action: draft-ietf-cdni-request-routing-extensions-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 15:16:14 -0000 Thanks for the updates, Ori. As we discussed, I will now re-run a 2-week last call purely to call out the new downref to RFC 7336, as we moved 7336 to normative. The document should be on the IESG telechat on 17 Oct. Barry On Tue, Sep 24, 2019 at 10:00 AM Ori Finkelman (IETF) wrote: > > Hi All, > This submission fixes the comments from all reviewers, I would like to th= ank all reviewers for taking the time and sharing their comments. > Please note the diff should be against revision 05 rather than 06 as most= of the changes were submitted in 06. > > > Here is the full list of comments that were fixed in this version: > =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=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=3D=3D=3D=3D=3D=3D=3D > > **************************************************************** > Reviewer: Barry Leiba (AD) > > > 1. Please use the new BCP 14 boilerplate and references: see RFC 8174. > >> fixed > > 2. Abstract vs Introduction: The sentence about the SVA seems out of > place in the Abstract, and is oddly missing from the Introduction. I > would add the first two sentences of the Abstract to the Introduction. > Then remove the first sentence from the Abstract and also remove =E2=80= =9CIn > that aspect,=E2=80=9D from the second sentence. > > >> fixed > > 3. RFC 6707 defines necessary terminology, so it probably should be > normative. I will note a downref in the last-call notice in > anticipation of that. > >> fixed > > > *************************************************** > Reviewer: Dan Romascanu (Genart) > > 1. Several non-obvious acronyms are not expanded: FCI, FQDN > >> fixed and removed the ones not used > 2. Section 3 - typo in the first paragraph '...the uCDN MUST be differnet= ...' > >> fixed > > ************************************************* > Reviewer: Zitao Wang (Opsdir) > > #1: There are a lot of abbreviations that are not provided with explanati= ons or > citations, such as uCDN, dCDN, CFI, etc. > >> fixed and remove the ones not necessary > > #2: The example of of a Redirect Target capability object serialization, = is it > encoded as json? Please present its encoding format. > >> fixed > > #3: In section 2.1, the "Mandatory-to-Specify" attributes of dns-target a= nd > http-target, it describes that "No, but at least one of dns-target or > http-target MUST be present and non-empty." I wonder whether there should= be a > detection mechanism. For example, if the requirements are not met, an err= or > message will be returned. And if there are existing mechanisms, please br= iefly > introduce them. > > >> That one is a great catch, thanks. I have changed it so it is not an e= rror anymore. Instead we have defined a default behavior for the case > it is not present or empty, see the fixed draft. > > ****************************************************************** > Reviewer: Linda Dunbar (Secdir) > > The terminology RR (Request Router) and CP (Content Provider) specified b= y the > Terminology are not used for the entire document. I assume that RR would = be the > one request content, isn't? is RR same as Client? Is RR part of Downstre= am CDN > Provider? is the CP same as Downstream CDN provider or Upstream CDN Provi= der? > > >> In the new version RR appears in a few locations. I have added more ex= planations and references to the relevant CDNI docs where it was defined. > > who issued the Redirect Target? > > It would be good for the document to clearly specify the relationship of = all > the entities, such as who makes request and who respond, and who use the > Redirect Target capability, etc. > > >> we have added drawings of sequences that explain it all, I hope it wil= l be clearer now. > > ******************************************************************* > Reviewer: Michael T=C3=BCxen (Tsvart) > > To improve readability, you might want to > * resolve acronyms on first occurence like CDN, CDNI,... > >> fixed > * Remove section 1.1, since the introduced abbreviations are not used in = the text. > >> fixed > * add a graphical representation of the involved nodes and the messages b= eing exchanged between them > >> Added sequence diagrams sections for both extensions. > > Typos: > * Section 3: the uCDN provide a fallback -> the uCDN provides a fallback > * Section 6: Nir B. Sopher -> Nir B. Sopher (no double space after perio= d) > * Section 6: Kevin J. Ma -> Kevin J. Ma (no double space after period) > >> fixed > > ******************************************************************* > Reviewer: Ben Niven-Jenkins (CDNI) > > Is there a reason that IPv6 addresses (AAAA records) are excluded from be= ing allowed as DnsTargets, or is this an oversight? > > >> fixed. references to ipv6 and AAAA record were added in the relevant p= laces. > > ******************************************************************* > > Thanks, > Ori > > > ---------- Forwarded message --------- > From: > Date: Tue, Sep 24, 2019 at 4:49 PM > Subject: [CDNi] I-D Action: draft-ietf-cdni-request-routing-extensions-07= .txt > To: > Cc: > > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Content Delivery Networks Interconnectio= n WG of the IETF. > > Title : CDNI Request Routing Extensions > Authors : Ori Finkelman > Sanjay Mishra > Filename : draft-ietf-cdni-request-routing-extensions-07.t= xt > Pages : 17 > Date : 2019-09-24 > > Abstract: > Open Caching is a use case of Content Delivery Networks > Interconnetion (CDNI) in which the commercial Content Delivery > Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer > serves as the downstream CDN (dCDN). The extensions specified in > this document to the CDNI Metadata and FCI interfaces are derived > from requirements raised by Open Caching but are also applicable to > CDNI use cases in general. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cdni-request-routing-extensio= ns/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-cdni-request-routing-extensions-07 > https://datatracker.ietf.org/doc/html/draft-ietf-cdni-request-routing-ext= ensions-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-request-routing-exten= sions-07 > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Wed Sep 25 06:05:13 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A748312008A; Wed, 25 Sep 2019 06:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huV_UFRs5GZm; Wed, 25 Sep 2019 06:04:53 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82BF1207FC; Wed, 25 Sep 2019 06:04:52 -0700 (PDT) Received: from [192.168.217.110] (p548DCE50.dip0.t-ipconnect.de [84.141.206.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46ddZC13Qgz10hj; Wed, 25 Sep 2019 15:04:51 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <156779251575.21899.11186203310854403491@ietfa.amsl.com> Date: Wed, 25 Sep 2019 15:04:50 +0200 Cc: secdir@ietf.org, draft-ietf-cbor-sequence.all@ietf.org, ietf@ietf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 591109489.016893-440eb0abb300bd43529d2eacdb563555 Content-Transfer-Encoding: quoted-printable Message-Id: <9C5B6D0A-98DA-4A35-A8A9-ACA4FCDBB91F@tzi.org> References: <156779251575.21899.11186203310854403491@ietfa.amsl.com> To: Stephen Kent X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [secdir] [Cbor] Secdir telechat review of draft-ietf-cbor-sequence-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2019 13:04:55 -0000 Hi Stephen, thank you for this review. On Sep 6, 2019, at 19:55, Stephen Kent via Datatracker = wrote: >=20 > The second paragraph of the Security Considerations section reminds = the > reader that decoders (parsers) ought to be designed with the = understanding that > inputs are untrusted =E2=80=93 good advice. I=E2=80=99d be happier if = the final sentence > changed =E2=80=9Cmust=E2=80=9D to =E2=80=9CMUST=E2=80=9D to reinforce = this admonition. Here I have a question: It seemed to me that we generally try to avoid = putting BCP14 keywords into security considerations sections =E2=80=94 = after all, the interoperability requirements should be handled in the = actual protocol definition, not in the security considerations after the = fact. This MUST would be an implementation requirement. Is this something we = want to do in a security considerations section? RFC 3552 appears to be = silent about this. (I=E2=80=99m also asking this because we are in the process of revising = RFC 7049, which would then raise the same question in its security = considerations section.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Sep 25 06:25:14 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52C4120815; Wed, 25 Sep 2019 06:25:04 -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=fastmail.fm header.b=Usihy0n2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WOFCliSt 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 qAoJUYjO2b_c; Wed, 25 Sep 2019 06:25:03 -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 E4FFF120806; Wed, 25 Sep 2019 06:25:02 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2FC2A22454; Wed, 25 Sep 2019 09:25:02 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Wed, 25 Sep 2019 09:25:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type:content-transfer-encoding; s=fm1; bh=UJAP6 UQDuorci+7Lu3PR7JnCdceKGEgubyfiecHczyo=; b=Usihy0n22H5d0EYSIue/P v1+se0GjpJFOFoxbNv5IhK4O6ReyuG7nZ3u+MQFfOIUOZB/9heI8ODrsv+/CcntP lVTr//vmEh8sA2ajzayKYkt2CWhLYqJ8VCdnjevWavoSEZIqWJ3nhw1qZao+KvyW xiLnBA6As1NQ2ugwvmMkoN2iYjE5E+Vgg8RWnaAjTNs+dgo8yrR/i1eJAR2XLa8V l5IEK6u37f0oWB6R7LL+DfuPGv2L6Q5RQfHwQfF2QhXc7I/Gdjb0yfe8hOENm7zH Pu4nFMuhoAZ86YFl9IzngtNN+AGY2uzCVkXKPxpElBTq/xnX+LxdHTAXMrzf58hC A== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=UJAP6UQDuorci+7Lu3PR7JnCdceKGEgubyfiecHcz yo=; b=WOFCliSttrFICjOVP0+TqZy8EZqHJ1bZola+UDloZYIwYikqV5FQJ84lk jrxxTaac8rcLBz8tlV/0EG8ZLEAdg4yZbtcOCCej5VXa/xh303CTWLFx8HPSukqO /k2hGB83l2mmEjqoV4F95bDvp7ouJeQS3q6AXfkCZzpIPh5VuKG49gHJF/N5Hi7W pCCRDGE0gSH2T7qOTwbo6iDvzact1RRaf4j64V/hWXWpQzaLmS6fYCpmHRb3K1ly JgZYFA3AOBFUqIQHsnXBMWvTZ0+S76LqaILCIg3AAjIDkbRoxRSpN81lDXZoMcWy IzhiMva0lMbwKL+H68Hd8CqFVgDJw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrfedvgdeigecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshht mhgrihhlrdhfmhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4D824C200A4; Wed, 25 Sep 2019 09:25:01 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-305-g4111847-fmstable-20190924v1 Mime-Version: 1.0 Message-Id: <59ca30ff-b521-4ab6-b792-a441b7ff2d20@www.fastmail.com> In-Reply-To: <9C5B6D0A-98DA-4A35-A8A9-ACA4FCDBB91F@tzi.org> References: <156779251575.21899.11186203310854403491@ietfa.amsl.com> <9C5B6D0A-98DA-4A35-A8A9-ACA4FCDBB91F@tzi.org> Date: Wed, 25 Sep 2019 14:23:44 +0100 From: "Alexey Melnikov" To: "Carsten Bormann" , "Stephen Kent" Cc: secdir@ietf.org, draft-ietf-cbor-sequence.all@ietf.org, ietf@ietf.org, cbor@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] [Cbor] Secdir telechat review of draft-ietf-cbor-sequence-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2019 13:25:05 -0000 Hi Carsten, On Wed, Sep 25, 2019, at 2:04 PM, Carsten Bormann wrote: > Hi Stephen, >=20 > thank you for this review. >=20 > On Sep 6, 2019, at 19:55, Stephen Kent via Datatracker wrote: > >=20 > > The second paragraph of the Security Considerations section reminds = the > > reader that decoders (parsers) ought to be designed with the underst= anding that > > inputs are untrusted =E2=80=93 good advice. I=E2=80=99d be happier i= f the final sentence > > changed =E2=80=9Cmust=E2=80=9D to =E2=80=9CMUST=E2=80=9D to reinforc= e this admonition. >=20 > Here I have a question: It seemed to me that we generally try to avoid= =20 > putting BCP14 keywords into security considerations sections =E2=80=94= after=20 > all, the interoperability requirements should be handled in the actual= =20 > protocol definition, not in the security considerations after the fact= . I think use of RFC 2119 keywords in the Security Considerations is fine,= as implementors should read the whole document. If a particular require= ment is really important, it can be moved to a separate section and refe= renced in the Security Considerations. > This MUST would be an implementation requirement. Is this something w= e=20 > want to do in a security considerations section? RFC 3552 appears to=20= > be silent about this. >=20 > (I=E2=80=99m also asking this because we are in the process of revisin= g RFC=20 > 7049, which would then raise the same question in its security=20 > considerations section.) Best Regards, Alexey From nobody Wed Sep 25 07:22:19 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7973E1200C4 for ; Wed, 25 Sep 2019 07:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.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 SAxeczB8isWl for ; Wed, 25 Sep 2019 07:22:15 -0700 (PDT) Received: from sonic305-2.consmr.mail.bf2.yahoo.com (sonic305-2.consmr.mail.bf2.yahoo.com [74.6.133.41]) (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 0BC2B120048 for ; Wed, 25 Sep 2019 07:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1569421333; bh=/jUoe/Eki5VBklrauras+K5XVkuSMe9844A6iHV33Uo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=kO8RKU3UzRLATvZGWKnS8JANxf04iZVmJKg8IhzyTT4moFOAKsoXKBJMs5rGGwDoJH/q9zKqn5iUKF3UIS/2vwQlFyqstc6tmNEyH2aH2jxHfY6F1hHxEnFlr/C8j8mUsxU5zySEhaBgf9AvaeW+23oENxdpR278pRVwOokIyxhY+GtZb2ddgLIIL4QQ0OW09f3cVcSSliCEw9zNSbvqs3crvyvDKFOH61LQqk6VTp1Umep12oe40UXS9a7RB4aX2iKXljYBwaPRt8iCPxrKgaFzzG/qQtotgTOBeITsudoyq6Q4vcJ6ry5oOOXI4PsHOrZHDiEMT9YVpPe4GSjt4g== X-YMail-OSG: v.a_QcwVM1mgxyVETnHVRuZFjNLPmi79hvb0.vKLbG3hHHYIqrRPZo6dbMktv7z wWx0wiHqpx_NrnGKuGK8ro_DWBoz3ITgSCslqfhXA64Ecl2kR8VLyBtOwd4BoVdpjYpKpwMr7STR .AbhxSSzdUjAbdojbv1Ey104A6BQHGQkQtNVAlnugt2RUd_9hMRMVjJ3mjwP27K_GSTcurBO.qYt BBz3IWzjdGllBH33t7IX4biT3UmjKCSIThe.pZMyionI5n3yabx.CByDZN8Lwox56SDNGYKBeEE. 8SyCd.Q0PSMm0wzuY9k56AoVJSD3bTQQAZMI19ARkIwGl_.CbWOpI.nhlV16HI3X_g9_6pBq6GG6 gSuDAoFgHBDI1vwHLo__.vBckCd5FOCdkCSEheyPGpYASOyMxURJ3IgPQzGjavHmVPc7m8ui7fVk 3JpQU4fneZa9kVeA9pC4vGDrnxTjOGr64U9Oxl8_OuU752BlmCdGjZLp1DVBTjqhJNabm.W4vUVJ l0AxDy0fWkJu7A8kQe.WEHCFBz8kWgYqmronqDDEK6sZYYk7r45Vx59e9Qdlmgh8TmnbPE8GJ1bh hCL7mvGNoAFU2tARfm1Yz5Q1bKrAY.2_7FYItjFENGyOrcM4o_NeANb0dRM53.cluuS44fiJKN64 TAIHEyRz8rLvxjfAWV6BcrsYE1uz0JTB1thFPq1QvTyNa.078L8xj0vP5ZI3ILznc.HYGi6k7Ezx mr8XM.sJM60hNkab74Qdwhqh6L2S5Ra8mfw5Qd0k1N5ZboNSlLPjDji_dI3ZEqdFKJcEHuiowScu tXVq1GaoEyaJWCXf2eY.zSWT7xP0m2zaGA8wr_aEqoPzlVfR_nnjmIzwCrXqiMHuCwaip.aohLrr ER35vb2HibAMuVdMJs6QSxK_eDDPP_REFmhzPhTsRH3QB4Qs8KJAGCRaN.UunOi_AtEAHFys4YOL GRW302FgpQD0uPupqhBIgg5IqhS.R3jCv1wF480vE810YMBTCdbHbEckpGUGAZrLEzFY0_7NpcSl wxS7GC3.53p7J3sslW5XKvFQfzEbEpkatN6QxCfoWmtKRPNhkk3.qYVnTvIUmlGWXI8tJxyMxAJ1 ycVlZzwjV8UiQw4FIJq9pmjKv1acckffp3sxYlr48yf_UCiZDmiiWbaSEffN3XjkpsHqKYeduWOC _bwVs2I4X4moFCPMVXyWe1dWnjua72CrTGp5x8E0eddbEGqsDPdGzY86dsG_c7bnuOG49zWNFs9A na1ECduxe9MkKB8QOyTCo0oqEalrBNqjrlEgH7_KYjKyKN_NWW_Cr8oSv9Wl2cd1GoIO8U8b1f4w ZtPKCzM4yOoyjiuaMxA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Wed, 25 Sep 2019 14:22:13 +0000 Received: by smtp412.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 90e859c14ae09ceeb1a6e4176b5f19a4; Wed, 25 Sep 2019 14:12:12 +0000 (UTC) To: Carsten Bormann , Stephen Kent Cc: secdir@ietf.org, draft-ietf-cbor-sequence.all@ietf.org, ietf@ietf.org, cbor@ietf.org References: <156779251575.21899.11186203310854403491@ietfa.amsl.com> <9C5B6D0A-98DA-4A35-A8A9-ACA4FCDBB91F@tzi.org> From: Stephen Kent Message-ID: <42c37ccd-1660-1efd-5fa5-80f174a80d4d@verizon.net> Date: Wed, 25 Sep 2019 10:12:09 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <9C5B6D0A-98DA-4A35-A8A9-ACA4FCDBB91F@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [secdir] [Cbor] Secdir telechat review of draft-ietf-cbor-sequence-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2019 14:22:16 -0000 Carsten, > Hi Stephen, > > thank you for this review. > > On Sep 6, 2019, at 19:55, Stephen Kent via Datatracker wrote: >> The second paragraph of the Security Considerations section reminds the >> reader that decoders (parsers) ought to be designed with the understanding that >> inputs are untrusted ??? good advice. I???d be happier if the final sentence >> changed ???must??? to ???MUST??? to reinforce this admonition. > Here I have a question: It seemed to me that we generally try to avoid putting BCP14 keywords into security considerations sections ??? after all, the interoperability requirements should be handled in the actual protocol definition, not in the security considerations after the fact. I am not aware of the convention you mention re BCP 14 keywords in the Security Considerations section. I'm pretty confident that I have seen the use of such keywords in other SC section sin the past > This MUST would be an implementation requirement. Is this something we want to do in a security considerations section? RFC 3552 appears to be silent about this. I don't think 3552 makes a statement on this topic either way. Steve From nobody Wed Sep 25 08:56:38 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D274E120803; Wed, 25 Sep 2019 08:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 oZ9tg1Ip2Ucu; Wed, 25 Sep 2019 08:56:23 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A8351207FF; Wed, 25 Sep 2019 08:56:23 -0700 (PDT) Received: from [192.168.217.110] (p548DCE50.dip0.t-ipconnect.de [84.141.206.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46djN56ngTzyWj; Wed, 25 Sep 2019 17:56:21 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <42c37ccd-1660-1efd-5fa5-80f174a80d4d@verizon.net> Date: Wed, 25 Sep 2019 17:56:21 +0200 Cc: Stephen Kent , draft-ietf-cbor-sequence.all@ietf.org, cbor@ietf.org, ietf@ietf.org, secdir@ietf.org X-Mao-Original-Outgoing-Id: 591119776.336159-3ff95f9da7cf5a485cfabb0000f39978 Content-Transfer-Encoding: quoted-printable Message-Id: References: <156779251575.21899.11186203310854403491@ietfa.amsl.com> <9C5B6D0A-98DA-4A35-A8A9-ACA4FCDBB91F@tzi.org> <42c37ccd-1660-1efd-5fa5-80f174a80d4d@verizon.net> To: Stephen Kent X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [secdir] [Cbor] Secdir telechat review of draft-ietf-cbor-sequence-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2019 15:56:37 -0000 On Sep 25, 2019, at 16:12, Stephen Kent = wrote: >=20 > Carsten, >> Hi Stephen, >>=20 >> thank you for this review. >>=20 >> On Sep 6, 2019, at 19:55, Stephen Kent via Datatracker = wrote: >>> The second paragraph of the Security Considerations section reminds = the >>> reader that decoders (parsers) ought to be designed with the = understanding that >>> inputs are untrusted ??? good advice. I???d be happier if the final = sentence >>> changed ???must??? to ???MUST??? to reinforce this admonition. >> Here I have a question: It seemed to me that we generally try to = avoid putting BCP14 keywords into security considerations sections ??? = after all, the interoperability requirements should be handled in the = actual protocol definition, not in the security considerations after the = fact. > I am not aware of the convention you mention re BCP 14 keywords in the = Security Considerations section. I'm pretty confident that I have seen = the use of such keywords in other SC section sin the past >> This MUST would be an implementation requirement. Is this something = we want to do in a security considerations section? RFC 3552 appears to = be silent about this. >=20 > I don=E2=80=99t think 3552 makes a statement on this topic either way. Thank you, so I have submitted -02 with a MUST in the final sentence. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Sep 25 20:18:19 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E4230120110; Wed, 25 Sep 2019 20:18:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Daniel Migault via Datatracker To: Cc: draft-ietf-acme-tls-alpn.all@ietf.org, acme@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.102.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Daniel Migault Message-ID: <156946788383.28879.9452952567486964215@ietfa.amsl.com> Date: Wed, 25 Sep 2019 20:18:03 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-acme-tls-alpn-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2019 03:18:04 -0000 Reviewer: Daniel Migault Review result: Ready 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 My only comment was that the text above may need some clarification. """This separation of layers can improve security and usability of ACME validation.""" More specifically, it was unclear to me if the improvement concerns the presented challenge versus the other ones (DNS or HTTP) or something else. Yours, Daniel From nobody Thu Sep 26 03:27:06 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3CC120899 for ; Thu, 26 Sep 2019 03:27:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.102.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <156949362370.5990.9916812034560320171.idtracker@ietfa.amsl.com> Date: Thu, 26 Sep 2019 03:27:03 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2019 10:27:04 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-10-03 Reviewer LC end Draft Kathleen Moriarty 2019-09-23 draft-ietf-isis-yang-isis-cfg-37 Tim Polk 2019-08-01 draft-ietf-acme-star-09 Last calls: Reviewer LC end Draft Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Daniel Gillmor 2018-03-19 draft-gutmann-scep-14 Leif Johansson 2019-09-02 draft-ietf-tls-sni-encryption-07 Scott Kelly 2019-09-18 draft-ietf-dnsop-obsolete-dlv-00 Catherine Meadows 2019-09-25 draft-ietf-payload-tsvcis-01 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Sandra Murphy 2019-07-08 draft-ietf-i2nsf-applicability-18 Yoav Nir 2019-10-09 draft-ietf-ace-cwt-proof-of-possession-07 Magnus Nystrom 2019-10-07 draft-ietf-ipsecme-implicit-iv-07 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Hilarie Orman 2019-10-04 draft-ietf-6tisch-minimal-security-12 Radia Perlman 2019-09-27 draft-ietf-core-hop-limit-05 David Waltermire 2019-08-07 draft-ietf-oauth-jwt-introspection-response-08 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Scott Kelly R2019-10-31 draft-ietf-rift-rift-08 Derrell Piper 2019-10-23 draft-ietf-nfsv4-rpc-tls-03 Tim Polk 2019-10-04 draft-ietf-lwig-curve-representations-08 Next in the reviewer rotation: Vincent Roca Kyle Rose Joseph Salowey Rich Salz Stefan Santesson Yaron Sheffer Rifaat Shekh-Yusef Melinda Shore Valery Smyslov Robert Sparks From nobody Thu Sep 26 06:20:40 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42492120839 for ; Thu, 26 Sep 2019 06:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vm4YDclcawrH for ; Thu, 26 Sep 2019 06:20:31 -0700 (PDT) Received: from smtp106.iad3a.emailsrvr.com (smtp106.iad3a.emailsrvr.com [173.203.187.106]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 175881208B8 for ; Thu, 26 Sep 2019 06:20:31 -0700 (PDT) Received: from app32.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp22.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 53E3F679B; Thu, 26 Sep 2019 09:20:30 -0400 (EDT) X-Sender-Id: scott@hyperthought.com Received: from app32.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Thu, 26 Sep 2019 09:20:30 -0400 Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app32.wa-webapps.iad3a (Postfix) with ESMTP id 3D1C3E0053; Thu, 26 Sep 2019 09:20:30 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Thu, 26 Sep 2019 06:20:30 -0700 (PDT) X-Auth-ID: scott@hyperthought.com Date: Thu, 26 Sep 2019 06:20:30 -0700 (PDT) From: "Scott G. Kelly" To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-dnsop-obsolete-dlv.all@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: <1569504030.247815945@apps.rackspace.com> X-Mailer: webmail/16.6.0-RC Archived-At: Subject: [secdir] secdir review of draft-ietf-dnsop-obsolete-dlv-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2019 13:20:39 -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.=0A=0AF= rom the abstract, this document obsoletes DNSSEC lookaside validation (DLV)= and reclassifies RFCs 4431 and 5074 as Historic.=0A=0AThe document lists a= ll current references to DLV RFCs and describes necessary changes to those = RFCs. The security considerations basically say that zones relying on DLV w= ill have to find another way, but that there are no well-known DLV registri= es, so this number will likely be small.=0A=0AI'm not a DNSSEC expert, so m= aybe this is a dumb question, but is there any possibility that someone doe= sn't get the memo, and continues to rely on some not-so-well-known DLV regi= stry? And if so, what could happen as a result? Anything anyone should care= about?=0A=0AThanks,=0A=0AScott=0A=0A=0A From nobody Thu Sep 26 06:32:26 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E09112002F; Thu, 26 Sep 2019 06:32:17 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 BMDjoL_jPUZX; Thu, 26 Sep 2019 06:32:15 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 9C1B9120827; Thu, 26 Sep 2019 06:32:15 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46fG7K6gLHzF0T; Thu, 26 Sep 2019 15:32:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1569504733; bh=YidRQTgRupJCUTVHuyo1OV5lBCJBQrlC6vT0zMxQbv8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=SbOJOTzagnlJKeXik278F+CDIMUTi1WKA9aoTOtYxmM0r02KOaTxhSC40tGwkTXYm WPkfarrMYhYxBMDfKVMX7OI/0a35kF/wSTJolmj2ZmfPNcm38gxVH0WeeMPMnSgoew hsPrIWr/PyLyfDuRWZ0ZFaMhnVSXBikxYHDrbBt8= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id yYIWJgGMc2dV; Thu, 26 Sep 2019 15:32:12 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 26 Sep 2019 15:32:12 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8AC87322DE9; Thu, 26 Sep 2019 09:32:11 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 8AC87322DE9 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 808BD40D37E1; Thu, 26 Sep 2019 09:32:11 -0400 (EDT) Date: Thu, 26 Sep 2019 09:32:11 -0400 (EDT) From: Paul Wouters To: "Scott G. Kelly" cc: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-dnsop-obsolete-dlv.all@ietf.org In-Reply-To: <1569504030.247815945@apps.rackspace.com> Message-ID: References: <1569504030.247815945@apps.rackspace.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-dnsop-obsolete-dlv-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2019 13:32:24 -0000 On Thu, 26 Sep 2019, Scott G. Kelly wrote: > I'm not a DNSSEC expert, so maybe this is a dumb question, but is there any possibility that someone doesn't get the memo, and continues to rely on some not-so-well-known DLV registry? And if so, what could happen as a result? Anything anyone should care about? It is possible someone has spun up a private DLV none of us knows about. They will at some point upgrade their software and see it is no longer working. Some of their queries will potentially change from secure to insecure. It is highly unlikely this would cover any public domains, because those queries would also be insecure for anyone not using that DLV, and it would already be too fragile to rely on getting nameservers assigned on roaming devices that would chain back to a resolver that uses this private DLV. So it would be a very fragile infrastructure that goes from fragile to insecure. I think the short warning in Section 5 is enough to discuss this case. Paul From nobody Thu Sep 26 06:42:18 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66777120077 for ; Thu, 26 Sep 2019 06:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 627LMiJw6xcb for ; Thu, 26 Sep 2019 06:42:15 -0700 (PDT) Received: from smtp113.iad3a.emailsrvr.com (smtp113.iad3a.emailsrvr.com [173.203.187.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FB67120041 for ; Thu, 26 Sep 2019 06:42:15 -0700 (PDT) Received: from app67.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp31.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 8C4C723A0E; Thu, 26 Sep 2019 09:42:14 -0400 (EDT) X-Sender-Id: scott@hyperthought.com Received: from app67.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Thu, 26 Sep 2019 09:42:14 -0400 Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app67.wa-webapps.iad3a (Postfix) with ESMTP id 785786104E; Thu, 26 Sep 2019 09:42:14 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Thu, 26 Sep 2019 06:42:14 -0700 (PDT) X-Auth-ID: scott@hyperthought.com Date: Thu, 26 Sep 2019 06:42:14 -0700 (PDT) From: "Scott G. Kelly" To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-rift-rift.all@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: <1569505334.490911728@apps.rackspace.com> X-Mailer: webmail/16.6.0-RC Archived-At: Subject: [secdir] secdir re-review of draft-ietf-rift-rift-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2019 13:42:16 -0000 This is a re-review of draft-ietf-rift-rift, I think 08 addresses all of my= comments. From nobody Thu Sep 26 15:54:24 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0EC120ABC; Thu, 26 Sep 2019 15:44:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1569537887; bh=LpRkKPeX5Z7MUM5Pe56ygqh0ChTnB7c7C/+gdhLvyBQ=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=Dyv5WeugP/ftsCo93F2peZAMHJuEPXdVsy8+6TMeyIjGhFVt/tfcfFgI20utMsJKk 7edtsr4Hn70D1oMA2+LGR1+xvgUwsgovkDTVvxQoPZSuLbM8w+qQ3TSUyaISaxBnkA jAJNrlNYVEVWDvWbPu/1dSQajZ+dEg9fdiIkXRQ0= X-Mailbox-Line: From new-work-bounces@ietf.org Thu Sep 26 15:44:42 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B625D120AA6; Thu, 26 Sep 2019 15:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1569537881; bh=LpRkKPeX5Z7MUM5Pe56ygqh0ChTnB7c7C/+gdhLvyBQ=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=qu/V10+N4KPG7ZzZ7kaYGOsICViAMrLFaWOZcvcry9/FduX5xSkeV3dqgvFKfWRv5 oV62O9iA8m/UfUQHC3MX29KIhICc32M8Lrt3JzRsItniEycOeLRwGEy9u0WV/vMP+c iooL4Rl9vrHEtkV4ICvBKpOc+/lV0ExvK+tUZ3u4= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B60120018 for ; Thu, 26 Sep 2019 15:44:25 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.103.0 Auto-Submitted: auto-generated Precedence: bulk Reply_to: MIME-Version: 1.0 Message-ID: <156953786533.31837.10722928868596206978.idtracker@ietfa.amsl.com> Date: Thu, 26 Sep 2019 15:44:25 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 26 Sep 2019 15:54:22 -0700 Subject: [secdir] [new-work] WG Review: General Area Dispatch (gendispatch) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2019 22:44:53 -0000 A new IETF WG has been proposed in the General Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2019-10-11. General Area Dispatch (gendispatch) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Francesca Palombini Pete Resnick Assigned Area Director: Alissa Cooper General Area Directors: Alissa Cooper Mailing list: Address: gendispatch@ietf.org To subscribe: Archive: Group page: https://datatracker.ietf.org/group/gendispatch/ Charter: https://datatracker.ietf.org/doc/charter-ietf-gendispatch/ The GENDISPATCH working group is a DISPATCH-style working group (see RFC 7957) chartered to consider proposals for new work in the GEN area, including proposals for changes or improvements to the IETF process and process documents. The working group is chartered to identify, or help create, an appropriate venue for the work. The working group will not consider any technical standardization work. Guiding principles for the proposed new work include: 1. Providing a clear problem statement, historical context, motivation, and deliverables for the proposed new work. 2. Ensuring there has been adequate mailing list discussion reflecting sufficient interest, individuals have expressed a willingness to contribute (if appropriate given the subject matter of the proposal) and there is WG consensus before new work is dispatched. 3. Looking for and identifying commonalities and overlap amongst published or ongoing work in the GEN area, within the IESG, or within the IETF LLC. Options for handling new work include: - Directing the work to an existing WG. - Developing a proposal for a BOF. - Developing a charter for a new WG. - Making recommendations that documents be AD-sponsored (which ADs may or may not choose to follow). - Requesting that the the IESG or the IETF LLC consider taking up the work. - Deferring the decision for the new work. - Rejecting the new work. If the group decides that a particular topic needs to be addressed by a new WG, the normal IETF chartering process will be followed, including, for instance, IETF-wide review of the proposed charter. Proposals for large work efforts SHOULD lead to a BOF where the topic can be discussed in front of the entire IETF community. Documents progressed as AD-sponsored would typically include those that are extremely simple or make minor updates to existing process documents. Proposed new work may be deferred in cases where the WG does not have enough information for the chairs to determine consensus. New work may be rejected in cases where there is not sufficient WG interest or the proposal has been considered and rejected in the past, unless a substantially revised proposal is put forth, including compelling new reasons for accepting the work. A major objective of the GENDISPATCH WG is to provide timely, clear dispositions of new efforts. Thus, where there is consensus to take on new work, the WG will strive to quickly find a home for it. While most new work in the GEN area is expected to be considered in the GENDISPATCH working group, there may be times where that is not appropriate. At the discretion of the GEN AD, new efforts may follow other paths. For example, work may go directly to a BOF, may be initiated in other working groups when it clearly belongs in that group, or may be directly AD-sponsored. Another major objective of the GENDISPATCH WG is to streamline how the IETF community considers process improvements. Community discussions about process suggestions that begin on other mailing lists, including ietf@ietf.org, will be redirected to the GENDISPATCH mailing list where they will be facilitated by the WG chairs. Proponents of process improvements will be encouraged to craft concrete proposals for discussion on the GENDISPATCH mailing list, with the goal of producing a concrete outcome in bounded time. Direct requests to the IESG may also, after proper consideration, be redirected to the WG. For proposals to be considered by the WG they will be expected to meet guiding principle #1 above. The existence of this working group does not change the IESG's responsibilities as described in RFC 3710. Work related to the IAB, IRTF, and RFC Editor processes is out of scope. _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Sat Sep 28 23:24:16 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C675712006A; Sat, 28 Sep 2019 23:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcZhkxOY7EtN; Sat, 28 Sep 2019 23:24:13 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::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 D4B3A12000F; Sat, 28 Sep 2019 23:24:09 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id q64so6201511ljb.12; Sat, 28 Sep 2019 23:24: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=2gJJKnaWxcX/66227S7niSIHA7IwWYlj8tS/oFGXOpc=; b=e9sfAp7+8m8tBMRJCCXgDjaNLCFo/NdWMhyIqJ53NynUdXY05pueE3lJ53taHe1Yd0 YlhISn3395B1y6bMdqqh8cSLvQL2EPhdAC64WorX+5VPXwaUXS+j66RLs1hjhtOK8ATE YAMwl58lj3shlbXQHUhJJWSPwwdb+x3tcgctDOTkqpcxJp7OonWyDOsq0bxsMKuk+QeZ Ol5VGmrXUPOiaE3KOs/A86JgF0W4r9P4ZyQmwvlJrAaVmUeuzVZHxkl5qyaERvApQlc4 GJSwkCxvmP05MPEnTOVpGopiQ0/FFoCTcv852qKov2ByaHMelen0Zmm20cLwAHnoHR2n A3HA== 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=2gJJKnaWxcX/66227S7niSIHA7IwWYlj8tS/oFGXOpc=; b=cpGiy65mdBcGsgoyZUK6hCA0AHPthS81PZGMU0zWsXyGB919yMnSgOQOTNxvFShCSI jmMWgiLhbbiF4jhaaijpYX3gB21EnkK2ZnfQnymU2lOEj28b0h5rxAbXK2BWMkdAy1q1 eVfcIkWa5m2WYPD6DQyLiyuwUXvNVSM5RmtE+RgL9PKKBTArHoH9CecpUtFn2u9NlnP4 hlDpApP6nqfBww5Z7hj2re7FXspm5BWWJeqBil33gFo5NOB6bzk7JIKiwZKqgZzWA3XU 3G8NMCzQ19WxVh0iw3cY/F6qjwAbp4+Se+DVdDJgdDAQH/GB19b8JiJAHDXxAe134kUz YPTw== X-Gm-Message-State: APjAAAX5OLZLhZ4bU6bFB0MYtdEVrCkurg5swOSFoDcA0U/e9AiNURhx 4jEW1KbfHYUIwPPtk2MGnxdoWpQdByj3lgb8O1bvIQuf X-Google-Smtp-Source: APXvYqz9q8uKso8bJPhNtXVqCC4+EpAkKQLOPc5f8zgxq8LDFrSdXGn6mV6cibpTzdx057x38INvgif34bECiVM50KI= X-Received: by 2002:a2e:1504:: with SMTP id s4mr6913801ljd.80.1569738247890; Sat, 28 Sep 2019 23:24:07 -0700 (PDT) MIME-Version: 1.0 From: Radia Perlman Date: Sat, 28 Sep 2019 23:23:56 -0700 Message-ID: To: draft-ietf-core-hop-limit@ietf.org, secdir@ietf.org, The IESG Content-Type: multipart/alternative; boundary="000000000000a7eb280593ab2aac" Archived-At: Subject: [secdir] Secdir review of draft-ietf-core-hop-limit-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Sep 2019 06:24:15 -0000 --000000000000a7eb280593ab2aac Content-Type: text/plain; charset="UTF-8" I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: This document is fine. This document defines an option for preventing infinite loops of Constrained Application Protocol (CoAP) proxies. The document says that infinite forward loops is undesirable", which is a cute wording. I'm very much in favor of hop count limits whenever things are forwarded (I was always somewhat terrified of forwarding Ethernet packets without a hop count). If I have to make an editorial comment (to show I was awake when reading this), I might comment about this text: "If no initial value is explicitly provided, the default initial Hop-Limit value of 16 MUST be used. This value is chosen to be sufficiently large to guarantee that a CoAP request would not be dropped in networks when there were no loops, but not so large as to consume CoAP proxy resources when a loop does occur. My quibble with that text is that if there were a value that would always be sufficiently large that a request would never be prematurely dropped, and not so large as to consume resources because of loops not being detected soon enough, then it needn't be configurable...just always use that value. So, maybe the text should say "this value is chosen so that in the majority of cases it is sufficiently large...but is still configurable to accommodate unusual topologies. Radia --000000000000a7eb280593ab2aac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
   I have reviewed thi=
s 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.
Summary:  This document is fine.
This document defines an option for preventing infinite loops of  Con=
strained Application Protocol (CoAP) proxies. The document says that infini=
te forward loops is undesirable", which is a cute wording.
<=
/pre>
I'm very much in favor of hop =
count limits whenever things are forwarded (I was always somewhat terrified=
 of forwarding Ethernet packets without a hop count).
If I have to make an editorial comment (to show I was a=
wake when reading this), I might comment about this text:
  "If no initial value is explicitly provide=
d, the default initial Hop-Limit value of
   16 MUST be used.  This value is chosen to be sufficiently large to
   guarantee that a CoAP request would not be dropped in networks when
   there were no loops, but not so large as to consume CoAP proxy
   resources when a loop does occur.

My quibble with that text is that=
 if there were a value that would always be sufficiently large that a reque=
st would never be prematurely dropped, and not so large as to consume resou=
rces because of loops not being detected soon enough, then it needn't b=
e configurable...just always use that value.
So, maybe the text should say "this value is chosen so that=
 in the majority of cases it is sufficiently large...but is still configura=
ble to accommodate unusual topologies.

Radia

--000000000000a7eb280593ab2aac-- From nobody Sun Sep 29 22:43:56 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F31A120106; Sun, 29 Sep 2019 22:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 wMTe5OxWoK4f; Sun, 29 Sep 2019 22:43:46 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C67DC120019; Sun, 29 Sep 2019 22:43:45 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 46hWXw1Qzlz5vs9; Mon, 30 Sep 2019 07:43:44 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.107]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 46hWXv2YFvz1xpp; Mon, 30 Sep 2019 07:43:43 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM8F.corporate.adroot.infra.ftgroup ([fe80::74f6:8fc8:b1b8:dbba%21]) with mapi id 14.03.0468.000; Mon, 30 Sep 2019 07:43:43 +0200 From: To: Radia Perlman , "draft-ietf-core-hop-limit@ietf.org" , "secdir@ietf.org" , The IESG Thread-Topic: Secdir review of draft-ietf-core-hop-limit-05 Thread-Index: AQHVdo6FqmzEbgOJzUafFrD/OWqlv6dDthjg Date: Mon, 30 Sep 2019 05:43:42 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031327F05@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933031327F05OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-core-hop-limit-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2019 05:43:48 -0000 --_000_787AE7BB302AE849A7480A190F8B933031327F05OPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmFkaWEsDQoNCk5vdGVkLiBXZSB3aWxsIGNvbnNpZGVyIHlvdXIgc3VnZ2VzdGlvbi4NCg0K VGhhbmsgeW91IGZvciB0aGUgcmV2aWV3Lg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBSYWRpYSBQ ZXJsbWFuIFttYWlsdG86cmFkaWFwZXJsbWFuQGdtYWlsLmNvbV0NCkVudm95w6kgOiBkaW1hbmNo ZSAyOSBzZXB0ZW1icmUgMjAxOSAwODoyNA0Kw4AgOiBkcmFmdC1pZXRmLWNvcmUtaG9wLWxpbWl0 QGlldGYub3JnOyBzZWNkaXJAaWV0Zi5vcmc7IFRoZSBJRVNHDQpPYmpldCA6IFNlY2RpciByZXZp ZXcgb2YgZHJhZnQtaWV0Zi1jb3JlLWhvcC1saW1pdC0wNQ0KDQoNCiAgIEkgaGF2ZSByZXZpZXdl ZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3MNCg0K ICAgIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJv Y2Vzc2VkIGJ5IHRoZQ0KDQogICAgSUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBw cmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZQ0KDQogICAgc2VjdXJpdHkgYXJlYSBkaXJl Y3RvcnMuICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0DQoNCiAg ICB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4N Cg0KU3VtbWFyeTogIFRoaXMgZG9jdW1lbnQgaXMgZmluZS4NCg0KVGhpcyBkb2N1bWVudCBkZWZp bmVzIGFuIG9wdGlvbiBmb3IgcHJldmVudGluZyBpbmZpbml0ZSBsb29wcyBvZiAgQ29uc3RyYWlu ZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApIHByb3hpZXMuIFRoZSBkb2N1bWVudCBzYXlz IHRoYXQgaW5maW5pdGUgZm9yd2FyZCBsb29wcyBpcyB1bmRlc2lyYWJsZSIsIHdoaWNoIGlzIGEg Y3V0ZSB3b3JkaW5nLg0KDQpJJ20gdmVyeSBtdWNoIGluIGZhdm9yIG9mIGhvcCBjb3VudCBsaW1p dHMgd2hlbmV2ZXIgdGhpbmdzIGFyZSBmb3J3YXJkZWQgKEkgd2FzIGFsd2F5cyBzb21ld2hhdCB0 ZXJyaWZpZWQgb2YgZm9yd2FyZGluZyBFdGhlcm5ldCBwYWNrZXRzIHdpdGhvdXQgYSBob3AgY291 bnQpLg0KDQpJZiBJIGhhdmUgdG8gbWFrZSBhbiBlZGl0b3JpYWwgY29tbWVudCAodG8gc2hvdyBJ IHdhcyBhd2FrZSB3aGVuIHJlYWRpbmcgdGhpcyksIEkgbWlnaHQgY29tbWVudCBhYm91dCB0aGlz IHRleHQ6DQoNCiAgIklmIG5vIGluaXRpYWwgdmFsdWUgaXMgZXhwbGljaXRseSBwcm92aWRlZCwg dGhlIGRlZmF1bHQgaW5pdGlhbCBIb3AtTGltaXQgdmFsdWUgb2YNCg0KICAgMTYgTVVTVCBiZSB1 c2VkLiAgVGhpcyB2YWx1ZSBpcyBjaG9zZW4gdG8gYmUgc3VmZmljaWVudGx5IGxhcmdlIHRvDQoN CiAgIGd1YXJhbnRlZSB0aGF0IGEgQ29BUCByZXF1ZXN0IHdvdWxkIG5vdCBiZSBkcm9wcGVkIGlu IG5ldHdvcmtzIHdoZW4NCg0KICAgdGhlcmUgd2VyZSBubyBsb29wcywgYnV0IG5vdCBzbyBsYXJn ZSBhcyB0byBjb25zdW1lIENvQVAgcHJveHkNCg0KICAgcmVzb3VyY2VzIHdoZW4gYSBsb29wIGRv ZXMgb2NjdXIuDQoNCk15IHF1aWJibGUgd2l0aCB0aGF0IHRleHQgaXMgdGhhdCBpZiB0aGVyZSB3 ZXJlIGEgdmFsdWUgdGhhdCB3b3VsZCBhbHdheXMgYmUgc3VmZmljaWVudGx5IGxhcmdlIHRoYXQg YSByZXF1ZXN0IHdvdWxkIG5ldmVyIGJlIHByZW1hdHVyZWx5IGRyb3BwZWQsIGFuZCBub3Qgc28g bGFyZ2UgYXMgdG8gY29uc3VtZSByZXNvdXJjZXMgYmVjYXVzZSBvZiBsb29wcyBub3QgYmVpbmcg ZGV0ZWN0ZWQgc29vbiBlbm91Z2gsIHRoZW4gaXQgbmVlZG4ndCBiZSBjb25maWd1cmFibGUuLi5q dXN0IGFsd2F5cyB1c2UgdGhhdCB2YWx1ZS4NCg0KU28sIG1heWJlIHRoZSB0ZXh0IHNob3VsZCBz YXkgInRoaXMgdmFsdWUgaXMgY2hvc2VuIHNvIHRoYXQgaW4gdGhlIG1ham9yaXR5IG9mIGNhc2Vz IGl0IGlzIHN1ZmZpY2llbnRseSBsYXJnZS4uLmJ1dCBpcyBzdGlsbCBjb25maWd1cmFibGUgdG8g YWNjb21tb2RhdGUgdW51c3VhbCB0b3BvbG9naWVzLg0KDQoNCg0KUmFkaWENCg0KDQo= --_000_787AE7BB302AE849A7480A190F8B933031327F05OPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCBD YXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLlByZm9ybWF0SFRNTENh cg0KCXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIjsNCglmb250 LWZhbWlseToiQ29uc29sYXMiLCJzZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7fQ0K c3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3Jt YWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PkhpIFJhZGlhLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Tm90ZWQu IFdlIHdpbGwgY29uc2lkZXIgeW91ciBzdWdnZXN0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Q2hlZXJz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+TWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBSYWRpYSBQZXJsbWFuIFttYWls dG86cmFkaWFwZXJsbWFuQGdtYTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aWwu Y29tXQ0KPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IGRpbWFuY2hlIDI5IHNlcHRlbWJyZSAy MDE5IDA4OjI0PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBkcmFmdC1pZXRmLWNvcmUtaG9wLWxpbWl0 QGlldGYub3JnOyBzZWNkaXJAaWV0Zi5vcmc7IFRoZSBJRVNHPGJyPg0KPGI+T2JqZXQmbmJzcDs6 PC9iPiBTZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY29yZS1ob3AtbGltaXQtMDU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHByZT4mbmJzcDsmbmJzcDsgSSBoYXZlIHJldmll d2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyA8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtvbmdvaW5nIGVm Zm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUg PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SUVTRy4mbmJz cDsgVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQg b2YgdGhlIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3Nl Y3VyaXR5IGFyZWEgZGlyZWN0b3JzLiZuYnNwOyBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFp cnMgc2hvdWxkIHRyZWF0IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO3RoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1l bnRzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+ U3VtbWFyeTombmJzcDsgVGhpcyBkb2N1bWVudCBpcyBmaW5lLjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoaXMgZG9jdW1lbnQg ZGVmaW5lcyBhbiBvcHRpb24gZm9yIHByZXZlbnRpbmcgaW5maW5pdGUgbG9vcHMgb2YmbmJzcDsg Q29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApIHByb3hpZXMuIFRoZSBkb2N1 bWVudCBzYXlzIHRoYXQgaW5maW5pdGUgZm9yd2FyZCBsb29wcyBpcyB1bmRlc2lyYWJsZSZxdW90 Oywgd2hpY2ggaXMgYSBjdXRlIHdvcmRpbmcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+SSdtIHZlcnkgbXVjaCBpbiBmYXZvciBvZiBo b3AgY291bnQgbGltaXRzIHdoZW5ldmVyIHRoaW5ncyBhcmUgZm9yd2FyZGVkIChJIHdhcyBhbHdh eXMgc29tZXdoYXQgdGVycmlmaWVkIG9mIGZvcndhcmRpbmcgRXRoZXJuZXQgcGFja2V0cyB3aXRo b3V0IGEgaG9wIGNvdW50KS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0id2hpdGUtc3Bh Y2U6cHJlLXdyYXAiPklmIEkgaGF2ZSB0byBtYWtlIGFuIGVkaXRvcmlhbCBjb21tZW50ICh0byBz aG93IEkgd2FzIGF3YWtlIHdoZW4gcmVhZGluZyB0aGlzKSwgSSBtaWdodCBjb21tZW50IGFib3V0 IHRoaXMgdGV4dDo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0id2hpdGUtc3BhY2U6cHJl LXdyYXAiPiZuYnNwOyAmcXVvdDtJZiBubyBpbml0aWFsIHZhbHVlIGlzIGV4cGxpY2l0bHkgcHJv dmlkZWQsIHRoZSBkZWZhdWx0IGluaXRpYWwgSG9wLUxpbWl0IHZhbHVlIG9mPG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IDE2IE1VU1QgYmUgdXNlZC4mbmJzcDsgVGhpcyB2YWx1 ZSBpcyBjaG9zZW4gdG8gYmUgc3VmZmljaWVudGx5IGxhcmdlIHRvPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7IGd1YXJhbnRlZSB0aGF0IGEgQ29BUCByZXF1ZXN0IHdvdWxkIG5v dCBiZSBkcm9wcGVkIGluIG5ldHdvcmtzIHdoZW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsgdGhlcmUgd2VyZSBubyBsb29wcywgYnV0IG5vdCBzbyBsYXJnZSBhcyB0byBjb25z dW1lIENvQVAgcHJveHk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgcmVzb3Vy Y2VzIHdoZW4gYSBsb29wIGRvZXMgb2NjdXIuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 IndoaXRlLXNwYWNlOnByZS13cmFwIj5NeSBxdWliYmxlIHdpdGggdGhhdCB0ZXh0IGlzIHRoYXQg aWYgdGhlcmUgd2VyZSBhIHZhbHVlIHRoYXQgd291bGQgYWx3YXlzIGJlIHN1ZmZpY2llbnRseSBs YXJnZSB0aGF0IGEgcmVxdWVzdCB3b3VsZCBuZXZlciBiZSBwcmVtYXR1cmVseSBkcm9wcGVkLCBh bmQgbm90IHNvIGxhcmdlIGFzIHRvIGNvbnN1bWUgcmVzb3VyY2VzIGJlY2F1c2Ugb2YgbG9vcHMg bm90IGJlaW5nIGRldGVjdGVkIHNvb24gZW5vdWdoLCB0aGVuIGl0IG5lZWRuJ3QgYmUgY29uZmln dXJhYmxlLi4uanVzdCBhbHdheXMgdXNlIHRoYXQgdmFsdWUuPG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj5TbywgbWF5YmUgdGhlIHRleHQgc2hvdWxk IHNheSAmcXVvdDt0aGlzIHZhbHVlIGlzIGNob3NlbiBzbyB0aGF0IGluIHRoZSBtYWpvcml0eSBv ZiBjYXNlcyBpdCBpcyBzdWZmaWNpZW50bHkgbGFyZ2UuLi5idXQgaXMgc3RpbGwgY29uZmlndXJh YmxlIHRvIGFjY29tbW9kYXRlIHVudXN1YWwgdG9wb2xvZ2llcy48bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+UmFkaWE8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B933031327F05OPEXCAUBMA2corp_--