From nobody Thu Jul 1 03:52:35 2021 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 062963A245F for ; Thu, 1 Jul 2021 03:52:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.33.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <162513675293.10613.13957157223132712431@ietfa.amsl.com> Date: Thu, 01 Jul 2021 03:52:32 -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, 01 Jul 2021 10:52:33 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2021-07-01 Reviewer LC end Draft Nancy Cam-Winget 2021-06-08 draft-ietf-oauth-par Charlie Kaufman R2021-06-18 draft-ietf-trans-rfc6962-bis For telechat 2021-07-15 Reviewer LC end Draft Nancy Cam-Winget R2021-06-28 draft-ietf-opsec-ipv6-eh-filtering David Mandelberg 2021-06-24 draft-ietf-shmoo-cancel-meeting Catherine Meadows 2021-04-14 draft-ietf-ntp-interleaved-modes Mališa Vučinić R2021-02-24 draft-ietf-curdle-ssh-kex-sha2 Last calls: Reviewer LC end Draft John Bradley 2021-03-16 draft-ietf-idr-bgp-ls-registry Nancy Cam-Winget R2021-06-28 draft-ietf-opsec-ipv6-eh-filtering Nancy Cam-Winget 2021-06-08 draft-ietf-oauth-par Shaun Cooley 2021-02-25 draft-ietf-v6ops-ipv6-ehs-packet-drops Alan DeKok 2021-03-24 draft-ietf-cbor-tags-oid Daniel Gillmor 2021-03-26 draft-ietf-lamps-crmf-update-algs Steve Hanna 2021-03-22 draft-ietf-regext-secure-authinfo-transfer Leif Johansson None draft-ietf-netconf-crypto-types Charlie Kaufman R2021-06-18 draft-ietf-trans-rfc6962-bis Watson Ladd None draft-ietf-netconf-tls-client-server Aanchal Malhotra None draft-ietf-opsawg-l3sm-l3nm David Mandelberg 2021-06-24 draft-ietf-shmoo-cancel-meeting Catherine Meadows 2021-07-07 draft-ietf-httpbis-cache-header Catherine Meadows 2021-04-14 draft-ietf-ntp-interleaved-modes Alexey Melnikov 2021-07-02 draft-ietf-netmod-nmda-diff Kathleen Moriarty 2021-04-27 draft-ietf-bess-mvpn-msdp-sa-interoperation Russ Mundy 2021-04-20 draft-ietf-dprive-xfr-over-tls Sandra Murphy R2021-04-05 draft-ietf-dmarc-psd Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Yoav Nir 2021-04-28 draft-ietf-core-new-block Melinda Shore 2021-05-17 draft-ietf-payload-rtp-jpegxs Mališa Vučinić 2021-06-10 draft-ietf-httpbis-semantics Mališa Vučinić R2021-02-24 draft-ietf-curdle-ssh-kex-sha2 Carl Wallace R2021-02-22 draft-ietf-tcpm-2140bis Samuel Weiler 2021-02-22 draft-ietf-tls-dtls13 Brian Weis 2021-02-19 draft-ietf-lamps-cms-aes-gmac-alg Klaas Wierenga 2020-12-02 draft-ietf-core-echo-request-tag Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Paul Wouters 2021-06-10 draft-ietf-httpbis-messaging Liang Xia 2021-03-17 draft-ietf-core-sid Early review requests: Reviewer Due Draft Stephen Farrell 2021-06-21 draft-ietf-idr-bgpls-srv6-ext Daniel Migault 2021-07-31 draft-ietf-httpbis-message-signatures Adam Montville 2021-07-23 draft-ietf-drip-rid Tina Tsou 2021-02-15 draft-ietf-idr-eag-distribution Dacheng Zhang 2020-12-07 draft-ietf-idr-eag-distribution Next in the reviewer rotation: Kathleen Moriarty Russ Mundy Sandra Murphy Yoav Nir Magnus Nystrom Hilarie Orman Radia Perlman Derrell Piper Tim Polk Tirumaleswar Reddy.K From nobody Thu Jul 1 05:58:31 2021 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 C122C3A0D03; Thu, 1 Jul 2021 05:58:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov via Datatracker To: Cc: draft-ietf-netmod-nmda-diff.all@ietf.org, last-call@ietf.org, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162514430275.17979.13728329356212798526@ietfa.amsl.com> Reply-To: Alexey Melnikov Date: Thu, 01 Jul 2021 05:58:22 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-netmod-nmda-diff-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2021 12:58:23 -0000 Reviewer: Alexey Melnikov 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 defines an RPC operation to compare management datastores that comply with the NMDA architecture. The Security Considerations talks about a couple of issues specific to the new operation: 1) sensitivity of the new "compare" operation and how access control rights to access it should be restricted. 2) performance considerations of running "compare" and how it can lead to Denial-of-Service, if the number of requests allowed in any given time interval is not restricted. I can't think of other security issues raised by this document that are missing from it. Nits: In Section 6: > The same request in RESTCONF (using JSON format): > > POST /restconf/operations/ietf-nmda-compare:compare HTTP/1.1 > Host: example.com > Content-Type: application/yang-data+json > Accept: application/yang-d Please insert an empty line after the HTTP request header and before the following payload, or your example is not syntactically valid. Also, I don't "application/yang-d" in the list of registered media types on . Did I miss it? > { "ietf-nmda-compare:input" { > "source" : "ietf-datastores:operational", > "target" : "ietf-datastores:intended", > "report-origin" : null, > "xpath-filter" : "/ietf-interfaces:interfaces" > } > } > > The same response in RESTCONF (using JSON format): > > HTTP/1.1 200 OK > Date: Thu, 26 Jan 2019 20:56:30 GMT > Server: example-server > Content-Type: application/yang-d Similar to the above, you need an empty line inserted here. > { "ietf-nmda-compare:output" : { > "differences" : { > "ietf-yang-patch:yang-patch" : { > "patch-id" : "interface status", > "comment" : "diff between intended (source) and operational", > "edit" : [ > { > "edit-id" : "1", > "operation" : "replace", > "target" : "/ietf-interfaces:interface=eth0/enabled", > "value" : { > "ietf-interfaces:interface/enabled" : "false" > }, > "source-value" : { > "ietf-interfaces:interface/enabled" : "true", > "@ietf-interfaces:interface/enabled" : { > "ietf-origin:origin" : "ietf-origin:learned" > } > } > }, > { > "edit-id" : "2", > "operation" : "create", > "target" : "/ietf-interfaces:interface=eth0/description", > "value" : { > "ietf-interface:interface/description" : "ip interface" > } > } > ] > } > } > } > } Best Regards, Alexey From nobody Thu Jul 1 19:24:06 2021 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 EE1283A0A8E for ; Thu, 1 Jul 2021 19:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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 (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 VKWkxK3yprTw for ; Thu, 1 Jul 2021 19:24:00 -0700 (PDT) Received: from mail-oi1-x264.google.com (mail-oi1-x264.google.com [IPv6:2607:f8b0:4864:20::264]) (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 A03F93A0A85 for ; Thu, 1 Jul 2021 19:24:00 -0700 (PDT) Received: by mail-oi1-x264.google.com with SMTP id r20so5096487oic.2 for ; Thu, 01 Jul 2021 19:24:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:dkim-signature:to:from:subject:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=kxwsUinuGEQ00U5CV8HWhciyOhY98sZTuml8rTziPUw=; b=CUgcLJLIY+YHuFEk5xjWB3x2ScLWHcS+WIuOzm24WoxmNb+sGnqMABUV+G6p7+wnLs 0T0tfCeZiPlVZU5TN26yFfg8mrdhqBKwe1RoEebGOrSkqQ59YFz7bzGmIKG/IDwGJLzC /LG35m+d2Hkltdo2Yh3vsfInHV9zFmgzop0YlU7fpbM2fI/gDuVaHuKdrMtMfonTV3Bm VxMPj9e93D/SHEp9EZ1jS4d4MkHdHfW4nkpjx8FEkhatmqurMnSSo3uShrXIWs/e8iI9 dzfxqXq4HXD2Z8vTlVfhg+Q1BWXq9BS+wrERlstMfZYFL/3pQJl4R2iqwy+IzA/p1cmH vZDg== X-Gm-Message-State: AOAM530MKGMn75gTNBm+V8rt8NOn18bcp6H0v8iySyzaq89If2XGHq9C DACbGSfXLHoxI9sTm4EdaXhqUovv3jidckqeBCJ+TWkWpxJ5rw== X-Google-Smtp-Source: ABdhPJwTFwkESbUM50qxFvYhYkqnqPnYE/ARGjXRYKQI4JmEkM8YPjJH7zDLtzJzRdzvqs1ANYSZka68krl4 X-Received: by 2002:aca:ab16:: with SMTP id u22mr10199609oie.0.1625192639268; Thu, 01 Jul 2021 19:23:59 -0700 (PDT) Received: from uriel.mandelberg.org (pool-74-104-157-60.bstnma.fios.verizon.net. [74.104.157.60]) by smtp-relay.gmail.com with ESMTPS id s23sm565838oop.2.2021.07.01.19.23.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Jul 2021 19:23:59 -0700 (PDT) X-Relaying-Domain: mandelberg.org Received: from [10.0.2.158] (sakaar.virgo.mandelberg.org [10.0.2.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 6CF491C6040; Thu, 1 Jul 2021 22:23:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; s=202103; t=1625192637; bh=fzwwve4zMS9eIE62P/VL8zXwE2wOOShRiTYs7cWeDAs=; h=To:From:Subject:Date:From; b=o1QTBvId6sQ012cDApKy2cH+RAqrjhUfUQsx2IEx7d9/K5UJHy4kiEsmB6WTZw5nS WdJvzS7iyZNaUiiEF+DTt78rPQ4pYRgzalZn4tKO70x3tp20qLC50X6909BHaylNM1 Hh6EzIAK3h56+xBAw4S0JA1I73tAdnXH7GOJkHb0pKFcc0gp/002OTBUhHXJNl2sO6 vrTeORMmG5fQREDmCedAOT/vinzjyFz9Idd/90nGq50ziSFCGVp5Zlv8d0zMhcq4t2 qxN6x2o5c3fSpXPOrwWlOQ+IkF3k1BQ92xF2rw20ULpWd8TQRJzFKJC3GWhZLJxghn JH5WnxN9Xvpzg== To: iesg@ietf.org, secdir@ietf.org, draft-ietf-shmoo-cancel-meeting.all@ietf.org From: David Mandelberg Message-ID: <7a05a3ab-608b-f555-f8c9-7e06278616ea@mandelberg.org> Date: Thu, 1 Jul 2021 22:23:54 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.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-shmoo-cancel-meeting-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: Fri, 02 Jul 2021 02:24:05 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready. The only thing I see in the document that looks at all relevant to security is the effect that cancellation (or potentially other options) could have on "the nomination process and seating of new officers." But also, I doubt that anybody would create an emergency on the scale this document talks about just to affect nomination or seating. From nobody Fri Jul 2 10:57:21 2021 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 A8AE43A266E; Fri, 2 Jul 2021 10:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1625248388; bh=DNIQQ0x5GkNAJoNAX53tWpS5GVAVfYokSXV1Oio+m3U=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=DYYlntM2MV8uLudigPTXKBmbnbxdXHT1PCygO3LtrOc1BWLuaDsQlefOzfmf1JBhn aLf/USGTFMnyCCYm851sf9nW4W0Q6ep8RxL483rvLF6M5aqOEJDof+EmCVlCpnFyCy iOJ6QMmI8mT5e3umpL7k/iKx2gY8YlzxpOVJowDE= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Jul 2 10:53:04 2021 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6001C3A0D08; Fri, 2 Jul 2021 10:53:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1625248383; bh=DNIQQ0x5GkNAJoNAX53tWpS5GVAVfYokSXV1Oio+m3U=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=Hy8W71Yc2gLn8APNFANAq+bNr5RrEXVy1qRWit0Q783pyVCn4QJpce8dOMuVf0DSX heYjD5FM9Qz5vFmRKFTdS2nR6/lbj471DvfI/stsXk80NB5ois17zCU9BrIS6l2xly oi+orDN9X6xyqMfPzgyzztWFYdcj6QUrj5d5Fb+0= 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 6547F3A0C79 for ; Fri, 2 Jul 2021 10:53:00 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <162524838039.13959.4947194276611797062@ietfa.amsl.com> Date: Fri, 02 Jul 2021 10:53:00 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Reply-To: iesg@ietf.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 02 Jul 2021 10:57:20 -0700 Subject: [secdir] [new-work] WG Review: Media Type Maintenance (mediaman) 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, 02 Jul 2021 17:53:14 -0000 QSBuZXcgSUVURiBXRyBoYXMgYmVlbiBwcm9wb3NlZCBpbiB0aGUgQXBwbGljYXRpb25zIGFuZCBS ZWFsLVRpbWUgQXJlYS4gVGhlCklFU0cgaGFzIG5vdCBtYWRlIGFueSBkZXRlcm1pbmF0aW9uIHll dC4gVGhlIGZvbGxvd2luZyBkcmFmdCBjaGFydGVyIHdhcwpzdWJtaXR0ZWQsIGFuZCBpcyBwcm92 aWRlZCBmb3IgaW5mb3JtYXRpb25hbCBwdXJwb3NlcyBvbmx5LiBQbGVhc2Ugc2VuZCB5b3VyCmNv bW1lbnRzIHRvIHRoZSBJRVNHIG1haWxpbmcgbGlzdCAoaWVzZ0BpZXRmLm9yZykgYnkgMjAyMS0w Ny0xMi4KCk1lZGlhIFR5cGUgTWFpbnRlbmFuY2UgKG1lZGlhbWFuKQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpD dXJyZW50IHN0YXR1czogUHJvcG9zZWQgV0cKCkNoYWlyczoKICBUQkQKCkFzc2lnbmVkIEFyZWEg RGlyZWN0b3I6CiAgTXVycmF5IEt1Y2hlcmF3eSA8c3VwZXJ1c2VyQGdtYWlsLmNvbT4KCkFwcGxp Y2F0aW9ucyBhbmQgUmVhbC1UaW1lIEFyZWEgRGlyZWN0b3JzOgogIE11cnJheSBLdWNoZXJhd3kg PHN1cGVydXNlckBnbWFpbC5jb20+CiAgRnJhbmNlc2NhIFBhbG9tYmluaSA8ZnJhbmNlc2NhLnBh bG9tYmluaUBlcmljc3Nvbi5jb20+CgpNYWlsaW5nIGxpc3Q6CiAgQWRkcmVzczogbWVkaWEtdHlw ZXNAaWV0Zi5vcmcKICBUbyBzdWJzY3JpYmU6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbWVkaWEtdHlwZXMKICBBcmNoaXZlOiBodHRwczovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvYnJvd3NlL21lZGlhLXR5cGVzLwoKR3JvdXAgcGFnZTogaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9ncm91cC9tZWRpYW1hbi8KCkNoYXJ0ZXI6IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi1tZWRpYW1hbi8KCklBTkEgbWFpbnRhaW5zIGEg cmVnaXN0cnkgb2YgbWVkaWEgdHlwZXMgYW5kIHN1YnR5cGVzIHRoYXQgYXJlIHVzZWQgdG8KaWRl bnRpZnkgcGFydGljdWxhciBwYXlsb2FkcyBhbmQgdGhlaXIgc2VtYW50aWNzIGFzIHRoZXkgYXJl IHRyYW5zcG9ydGVkIHZpYQphcHBsaWNhdGlvbiBsZXZlbCBwcm90b2NvbHMgc3VjaCBhcyBtZXNz YWdpbmcgKOKAnGVtYWls4oCdKSBhbmQgdGhlIHdlYiAoSFRUUCkuIApUaGUgY29yZSBzdHJ1Y3R1 cmUgYW5kIHVzZSBvZiBtZWRpYSB0eXBlcyBpcyB0aGUgTUlNRSBmcmFtZXdvcmssIGRlZmluZWQg aW4KUkZDcyAyMDQ1IHRocm91Z2ggMjA0OSwgYW5kIGFtZW5kZWQgYnkgdmFyaW91cyBsYXRlciBk b2N1bWVudHMuICBSZWdpc3RyYXRpb24Kb2YgbmV3IG1lZGlhIHR5cGVzIGlzIGRlZmluZWQgYnkg QkNQIDEzLCB3aGljaCB3YXMgbGFzdCB1cGRhdGVkIGluIDIwMTMuCgpUaGUgcmVnaXN0cmF0aW9u IG9mIGEgdG9wLWxldmVsIG1lZGlhIHR5cGUgaXMgYSByYXJlIGV2ZW50LiAgQkNQIDEzIGRlc2Ny aWJlcwp0aGUgcHJvY2VzcyBmb3IgZG9pbmcgc28sIGFzIHdhcyB1c2VkIGluIFJGQyA4MDgxLCBi dXQgaXQgZG9lcyBub3QgcHJvdmlkZQphbnkgZ3VpZGFuY2Ugb3IgY3JpdGVyaWEgcmVnYXJkaW5n IHdoYXQgY29uc3RpdHV0ZXMgYW4gYXBwcm9wcmlhdGUKcmVnaXN0cmF0aW9uLgoKU2V2ZXJhbCBv dGhlciB0b3BpY3MgaGF2ZSBhcHBlYXJlZCBpbiB0aGUgaW50ZXJpbSB0aGF0IGFyZSBsYXJnZSBl bm91Z2ggaW4Kc2NvcGUgYW5kIGltcG9ydGFuY2UgdG8gd2FycmFudCB0aGUgZm9ybWF0aW9uIG9m IGEgd29ya2luZyBncm91cCB0byBkZXZlbG9wCmFuZCBwcm9jZXNzIHRoZW0uICBUaGlzIHdvcmtp bmcgZ3JvdXAgd2lsbCB0aGVyZWZvcmUgdGFrZSB1cCB0aGUgZm9sbG93aW5nCml0ZW1zLCBpbiB0 aGlzIG9yZGVyIChvciBhcyBvdGhlcndpc2UgbmVnb3RpYXRlZCB3aXRoIHRoZSBzdXBlcnZpc2lu ZyBBcmVhCkRpcmVjdG9yKToKCiogRGV0ZXJtaW5lIHdoZXRoZXIgYW55IHNwZWNpZmljIGNyaXRl cmlhIG9yIGd1aWRhbmNlIGFyZSB3YXJyYW50ZWQgdG8gaGFuZGxlCnJlZ2lzdHJhdGlvbiBvZiBm dXR1cmUgdG9wLWxldmVsIG1lZGlhIHR5cGVzLCBhbmQgcHVibGlzaCBhbnkgc3VjaCBndWlkYW5j ZS4KCiogRGV2ZWxvcCBhbmQgcHJvY2VzcyB0aGUgcGVuZGluZyDigJhoYXB0aWNz4oCZIHRvcC1s ZXZlbCBtZWRpYSB0eXBlIHJlcXVlc3QsCmJhc2VkIG9uIGRyYWZ0LW11dGh1c2FteS1kaXNwYXRj aC1oYXB0aWNzLCBhbmQgdGhlIG91dGNvbWUgb2YgdGhlIHByZXZpb3VzCndvcmsgaXRlbS4KCiog Q29uc2lkZXIgd2hldGhlciBhbmQgaG93IHRvIHBlcm1pdCBtdWx0aXBsZSBtZWRpYSB0eXBlIHN1 ZmZpeGVzLgoKKiBEZXZlbG9wIGEgcmV2aWV3ZXLigJlzIGNoZWNrbGlzdCByZWdhcmRpbmcgU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbnMKaW4gbWVkaWEgdHlwZSBhcHBsaWNhdGlvbnMu CgoqIENvbnNpZGVyIGFueSBpc3N1ZXMgYXJvdW5kIG1lZGlhIHR5cGVzIGZvciBwcm9ncmFtbWlu ZyBsYW5ndWFnZXMuCgoqIFJldmlldyB0aGUgZm9ybWF0IG9mIHRoZSBtZWRpYSB0eXBlcyByZWdp c3RyeSBpdHNlbGYuCgoqIEV2YWx1YXRlIHRoZSByZWdpc3RyeSBwb2xpY2llcyBhbmQgcHJvY2Vk dXJlcyBpbiB0aGUgY29udGV4dCBvZiBob3cgbWVkaWEKdHlwZXMgYXJlIGN1cnJlbnRseSB1c2Vk LCBhbmQgbW9kaWZ5IHRoZW0gaWYgbmVjZXNzYXJ5LgoKVGhpcyBsYXN0IGl0ZW0gd2lsbCBjb25z aWRlciB0aGUgZXhpc3RpbmcgdXNlIG9mIEdpdEh1YiBmb3IgbWFuYWdpbmcKcmVnaXN0cmF0aW9u cyBhbmQgdGhlIHByb2Nlc3NpbmcgcXVldWVzIGZvciB0aGUg4oCcbGluayByZWxhdGlvbnPigJ0g YW5kIOKAnHdlbGwKa25vd24gVVJJc+KAnSByZWdpc3RyaWVzIGFzIGV4YW1wbGVzLgoKSW5wdXQg RG9jdW1lbnQocyk6CiogZHJhZnQtbXV0aHVzYW15LWRpc3BhdGNoLWhhcHRpY3MKCiogZHJhZnQt dzNjZGlkd2ctbWVkaWEtdHlwZXMtd2l0aC1tdWx0aXBsZS1zdWZmaXhlcwoKUHJvcG9zZWQgbWls ZXN0b25lcyAodGFyZ2V0IGRhdGVzIFRCRCk6CiogUHVibGlzaCBhbnkgc3BlY2lmaWMgY3JpdGVy aWEgb3IgZ3VpZGFuY2UgZm9yIGhhbmRsaW5nIHJlZ2lzdHJhdGlvbiBvZgpmdXR1cmUgdG9wLWxl dmVsIG1lZGlhIHR5cGVzLCBlaXRoZXIgYXMgYW4gUkZDIG9yIGEgd2lraSBwYWdlLgoKKiBkcmFm dC1tdXRodXNhbXktZGlzcGF0Y2gtaGFwdGljcyAob3IgZXF1aXZhbGVudCkgdG8gdGhlIElFU0cg Zm9yIGFwcHJvdmFsCihQcm9wb3NlZCBTdGFuZGFyZCkKCiogQSBkcmFmdCBhYm91dCBoYW5kbGlu ZyBtdWx0aXBsZSBzdWZmaXhlcyB0byB0aGUgSUVTRyBmb3IgYXBwcm92YWwgKEJDUCkKCiogUHVi bGlzaCBhIHJldmlld2Vy4oCZcyBjaGVja2xpc3QgYWJvdXQgU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnMgaW4gbWVkaWEgdHlwZQphcHBsaWNhdGlvbnMsIGVpdGhlciBhcyBhbiBSRkMgb3IgYSB3aWtp IHBhZ2UuCgoqIERlbGl2ZXIgcmVjb21tZW5kYXRpb25zIGFib3V0IHRoZSBtZWRpYSB0eXBlcyBy ZWdpc3RyeSBmb3JtYXQuCgoqIERlbGl2ZXIgYW55IHJlY29tbWVuZGF0aW9ucyBhYm91dCBmdXR1 cmUgcmVnaXN0cmF0aW9uIGFuZCBxdWV1ZSBtYW5hZ2VtZW50LgoKTWlsZXN0b25lczoKClRCRAoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV3LXdvcmsg bWFpbGluZyBsaXN0Cm5ldy13b3JrQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV3LXdvcmsK From nobody Sat Jul 3 16:23:01 2021 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 0CF7E3A2938; Sat, 3 Jul 2021 16:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdbCHWU95NtP; Sat, 3 Jul 2021 16:22:52 -0700 (PDT) Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam08olkn2023.outbound.protection.outlook.com [40.92.45.23]) (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 252253A2937; Sat, 3 Jul 2021 16:22:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S1VJsSKcFAqriOw5l6TK1K9Q5DtAXpAVK/b3mMN2zZoqfFN5YfxATvA++Th5Z+sWxR5iwsi+aymtOmHTLlBvb7i4XPI6x4NS98Wkt/Eh4ZSKdtNc8OkPG23l8GkYI4HDNWgXNCELepTcMe/ecLkACmRyEGvO73leshp5TsuLKGKsDFTZ4d5p7ZOlM5jDFXFqfu8rvD8Z06oMD09VfV7SsBLivN93qF4ELA/F3QY7fV65oaf9OW6E9t0SVIqWkzC2uIGBjtW81pujmWxh+HQIM1AAdyFijPx57BffRklqHrc0ozTnRvY5OvJ5nhQDZS6bwISku8i5tNKgytsy2rfuww== 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=gqyLsgSyFJhMi30f8lWK4lJjudT+vr9WVavD7EU0Vtw=; b=TC7Yk1HdRwcJ+x4Ft2Oj/eXIblonm+CHJsqR1YvYR9G6/rmXRi6f5ysfPENHFtlJLhrOMrRY7xzxWH3Y7irsx+BXdfgB0FcIAE5lrhN6q35gZTBoJNl+LNrucXz7oRQjUyHPQJHVqmOo9bpNMiUZOAm+bHqax6+m34Pry0UJ3WPrnBbleQZnbeJGnEtGJYSPHL/+ogeRd3UmlUzKQZTUbubkB8LPR/N4NC9w9/0k/0/xpUnNUQpiLojwuvvgiZb200GY1DmM21iMAW3zkdXf1OyOl+Vj4sU/XSligKf+Sm6p2uhE39S7JMvHUvKaKvA4RdV6jwicuYRe0WTT4l2laA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gqyLsgSyFJhMi30f8lWK4lJjudT+vr9WVavD7EU0Vtw=; b=WgIkcgu1i5eMglNEXfC/p6rc+OwkURilcVhnZBAZXVovFRyfWlCy9fyrT569nMaNvd5W/206BpVbd3dC/7Y/TwuuwA3HqNQAbpcDMdx3ojaEFH45TgJuchLYc3ssOzlxlXSitYS6R/1RyayxdYkzOlIffrbA7lug/vjqMz3YBaXukOTB4VqAKVKTw7g0gWW3o69UPK22GzwdSjB3o+tIf1X+UTYByN8+ox413Ia8hdwRcnv7M0nkT49rFVq1/UwYbULuGGE2LwRGD8Dw3tCuSM3WghxjIZk7MNoGjVYWRZoaD1AvjJzJFm4JDmxEtE5WmgXV+i5DfLNF6ESeO5gS1Q== Received: from DM6NAM04FT014.eop-NAM04.prod.protection.outlook.com (2a01:111:e400:7ea3::44) by DM6NAM04HT149.eop-NAM04.prod.protection.outlook.com (2a01:111:e400:7ea3::63) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.18; Sat, 3 Jul 2021 23:22:50 +0000 Received: from MW2PR1901MB4683.namprd19.prod.outlook.com (2a01:111:e400:7ea3::49) by DM6NAM04FT014.mail.protection.outlook.com (2a01:111:e400:7ea3::288) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.22 via Frontend Transport; Sat, 3 Jul 2021 23:22:50 +0000 Received: from MW2PR1901MB4683.namprd19.prod.outlook.com ([fe80::f538:ebac:9440:4974]) by MW2PR1901MB4683.namprd19.prod.outlook.com ([fe80::f538:ebac:9440:4974%3]) with mapi id 15.20.4264.026; Sat, 3 Jul 2021 23:22:50 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-trans-rfc6962-bis.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-trans-rfc6962-bis-39 Thread-Index: AQHXcGIc/cRwqgNbyk6UZeFj2ow23Q== Date: Sat, 3 Jul 2021 23:22:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:75D5F8B729417261A596C4BF6CEE7D6BE4E102925E6BC2973504AE625440C8F8; UpperCasedChecksum:CC16E626F86A7DE2CD5F1914C54322B951DD7F502D70761A73D17FE7947B974D; SizeAsReceived:6959; Count:41 x-tmn: [pwAKGBqWQAjrASsMGfaATkiUdYCn/2NB/sI/EIS6YAOTFzd0po08/W7AnJdH1U9A] x-ms-publictraffictype: Email x-incomingheadercount: 41 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 22d3d800-623a-4292-eda0-08d93e797981 x-ms-traffictypediagnostic: DM6NAM04HT149: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: i8c/c9nsgFqOguRJwQMwX4dc1/nMW+bKPHTMOd8kRFwR6HDnn3y1r6P4yeUTbSuUCgQ/zFRsfWR/Dmr20t+rryls4dwaMiKWtKx7TxzoW3o5G5INbL3qN2SU4pzEwNdmnOGyxhGIOp2iArDNGgmWd0QJ2Mp1Q0tyslBkNn9MBnpof0eWLf8sK+WZ0YpvAb3S2f1jve0pPnHw5c/l4ZD9JNkVwOceA/QuU5Atl9K1mx2ze9uKP0NdWg68tG84gF//znkpGhnxRNXptTRnmWysieyQ9emx5ZAsusRBzYJ6mY/CUBaMMfn2qHMQYiOw5wPERtO34vjmLEFcrsoxTSLbIZVT499hcu9uW+CITwm+/1vEKoBCcTlbhZtQj5E8nmdmaZmGmyhOP7WnUAMDBOzh9ql9VPdMP7sg07kaz+zLOa6bZsiEIhScGatcBTWO7AHM x-ms-exchange-antispam-messagedata: osKu9non5EQXGfmxRue7WpSTDZycpguk+3w0UjLRVW1gvihVkXuvPk6j9leJcZsdTpGYznnM05DlCSsXxIhPUEWWWtDm7fF8ArmMzbNRamRYf+pZ5gil6B85b3sAyrN1ZfS1sdc+Gq2mvP17UVvjLOAzzyQPhWmoPTUnrtDQdwzWUwgCnV0eVjzvcTROBiM9hpeIIp4Q0niILLRskE+ykA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-AuthSource: DM6NAM04FT014.eop-NAM04.prod.protection.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 22d3d800-623a-4292-eda0-08d93e797981 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2021 23:22:49.9099 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6NAM04HT149 Archived-At: Subject: [secdir] Secdir review of draft-ietf-trans-rfc6962-bis-39 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: Sat, 03 Jul 2021 23:22:55 -0000 =0A= 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= =0A= I reviewed -31 two years ago, found no problems with it then, and examining= the diffs find no problems with those either.=0A= =0A= This is an interesting proposal for testing the validity of certificates in= the Internet PKI (in addition to CRLs, OCSP, some DNS extension, and perha= ps some others I'm forgetting), and it has functionality that overlaps with= those. **PEOPLE INTERESTED IN TECHNICAL APPROACHES TO IMPROVING THE SECURI= TY OF THE INTERNET PKI SHOULD TAKE A LOOK AT THIS APPROACH WHETHER OR NOT T= HIS PARTICULAR PROPOSAL SUCCEEDS**.=0A= =0A= It is a little odd that this is classed as experimental given that it appea= rs to be deployed in Chrome and has enough history and evolution to be issu= ing a -bis.=0A= =0A= The goal of this protocol is to prevent someone who captures the private ke= y of a Certification Authority from issuing certificates for occasional use= without the knowledge of the CA. It does this by registering all observed = certificates in a log, encouraging clients to reject certificates not found= in the log, and encouraging CAs to check the log for certificates signed w= ith its key that were not signed through its authorized procedures.=0A= =0A= The proposal specifies the actions of a partially trusted logging service t= hat will take certificates as they are issued, sign an acknowledgement that= can optionally be placed in the certificate itself or in the TLS headers d= uring session initialization. The certificates are then placed in a Merkle = hash tree and signed. This both reduces the signing work the log server has= to do and allows it to prove that it has not removed any certificates from= its database once they are posted there.=0A= =0A= The protocol could be adapted for other logs that someone might want to aud= it for completeness and for following a policy of strictly-appending.=0A= =0A= An interesting question that I did not see addressed in the I-D concerns wh= ether the list of all issued certificates is made world-readable. The syste= m assumes that the owners of particular domain names can watch for the issu= ance of bogus certificates for names they own, but many issuers do not want= to make public the complete list of certificates they have issued for the = same reason they would not want to release a complete list of DNS names the= y are using below their arc. DNS allows verification of guessed names but n= ot enumeration of all names (at least optionally). Doing the same with this= system would lose some of its security benefits, but not doing it would ma= ke it unacceptable to some issuers. This issue was discussed by the working= group, but the security community might also want to comment.=0A= =0A= --Charlie= From nobody Sun Jul 4 13:32:57 2021 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 1DFD63A1D3B for ; Sun, 4 Jul 2021 13:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 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, 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 l7B7DcTy9WU8 for ; Sun, 4 Jul 2021 13:32:50 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63BE23A1D42 for ; Sun, 4 Jul 2021 13:32:50 -0700 (PDT) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 164KWgoJ025008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 4 Jul 2021 16:32:47 -0400 Date: Sun, 4 Jul 2021 13:32:42 -0700 From: Benjamin Kaduk To: Chris Lonvick Cc: secdir@ietf.org Message-ID: <20210704203242.GF17170@mit.edu> References: <162500581702.14479.10740784349692238870@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <162500581702.14479.10740784349692238870@ietfa.amsl.com> Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-bess-evpn-inter-subnet-forwarding-14 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, 04 Jul 2021 20:32:55 -0000 Thanks, Chris -- it's reassuring to have another set of eyes on the changes. -Ben On Tue, Jun 29, 2021 at 03:30:17PM -0700, Chris Lonvick via Datatracker wrote: > Reviewer: Chris Lonvick > 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. > > This is a re-review. The Security Considerations section has been updated and > addresses the issues I noted from the version -09 I previously reviewed. The > additions to the section do a very good job of addressing the adherence to or > differences from the security considerations sections of the referenced RFCs. > > Regards, > Chris > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Sun Jul 4 16:42:53 2021 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 159BE3A2A27; Sun, 4 Jul 2021 16:42:48 -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, 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 cGmj4n_BKO-1; Sun, 4 Jul 2021 16:42:43 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28C903A2A23; Sun, 4 Jul 2021 16:42:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id B895538B08; Sun, 4 Jul 2021 19:45:00 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id L7-Lzv7S9xxM; Sun, 4 Jul 2021 19:44:55 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9DD4138B00; Sun, 4 Jul 2021 19:44:55 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5727E319; Sun, 4 Jul 2021 19:42:33 -0400 (EDT) From: Michael Richardson To: Daniel Franke cc: secdir@ietf.org, draft-ietf-anima-constrained-voucher.all@ietf.org, anima@ietf.org In-Reply-To: <162509788114.10193.4485290358108899416@ietfa.amsl.com> References: <162509788114.10193.4485290358108899416@ietfa.amsl.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [secdir] [Anima] Secdir early review of draft-ietf-anima-constrained-voucher-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2021 23:42:48 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Daniel Franke via Datatracker wrote: > I'm marking this as "Not Ready" principally because the whole Security > Considerations section is "TBD". Yes. We were hoping to get early reviews from people who had previously re= viewed RFC8995. Filling in the Security Considerations without repeating RFC8995's lengthy section will be a challenge. > Having no prior familiarity with the ANIMA WG or its output, I found = the > introductory section of this draft rather bewildering. The document I= wanted to > read for background, RFC 8366, is cited a few sentences in, but the c= ontext > didn't make it clear that this was where I wanted to look. Please pro= vide a > paragraph or so worth of background about the ecosystem that this dra= ft lives > in before launching into protocol-specific jargon like "voucher" and > "pledge". fair enough! opened issue: https://github.com/anima-wg/constrained-voucher/issues/124 > You mention trying to conserve both network bandwidth and code size. = I see how > you're saving a bit of bandwidth by shortening URLs, using CBOR inste= ad of > JSON, and in some cases avoiding retransmission of public keys. But I= 'm not > following where the code size wins come from. The procedure described= in > section 5.3.1 doesn't seem to save anything significant, since you st= ill need a > whole RFC 5280 implementation for the fallback path. https://github.com/anima-wg/constrained-voucher/issues/125 The short of it is that on many IoT devices, we already have CBOR, COSE code present, because they are using ACE, OSCORE, etc. we'll make this more explicit thank you. > You've given "ECDSA" as a mandatory-to-implement algorithm, but haven= 't > specified what particular curves must be supported. Without this, you= haven't > gotten any closer to assuring interoperability. Noted: https://github.com/anima-wg/constrained-voucher/issues/126 > Appendix A looks like a funny thing to find in an RFC. Are you planni= ng to have > the RFC Editor remove this prior to publication, like you'd do for an > "Implementation Status" section? If so, you should include an explicit > instruction to that effect. The examples are intended to provide meaningful input for unit tests. This is quite common for anything involve cryptographic operations. We don't intend to remove it. Our experiences is that people outside of t= he IETF find protocols without examples to be challenging to implement. Should we merge Appendix A and B? =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmDiR2kACgkQgItw+93Q 3WVkAgf/YawqBxHQ4BBf6aGIG6s2JWGnE9qjSv9xxZeOWetFIRwpYh42Elf4UWXH /Mx028NUQNOcf8WSV426Jb/8w7ywnjkR5wFbIct8bBnewY8DRvQwzZZgnmwUnwj3 WIj/ucTiuxXAh3ahYhxNJklyFIwM//YMutZ9aGXVW5+fARg95yL3caUV6InQHMMp L9jQggBIyaYj/uFrJjwMxF9ZfJq3UH0k9AJra+6jO28ABgv7YOFfhBIvp7zMzoxM q/OwPCyxMUqpOtXKcUYV7Apb5w8djXtaJymYt0kTrXbEm+7aKmAzatXQ0OQR4q1u /kEfu2hVlfU5d7xuvNFD1BsyoRIEPg== =Yc+Q -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 8 02:22:21 2021 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 086263A195E for ; Thu, 8 Jul 2021 02:22:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <162573613853.8194.4670141373357942700@ietfa.amsl.com> Date: Thu, 08 Jul 2021 02:22:19 -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, 08 Jul 2021 09:22:19 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2021-07-15 Reviewer LC end Draft Nancy Cam-Winget R2021-06-28 draft-ietf-opsec-ipv6-eh-filtering Catherine Meadows 2021-04-14 draft-ietf-ntp-interleaved-modes Mališa Vučinić R2021-02-24 draft-ietf-curdle-ssh-kex-sha2 Liang Xia 2021-03-17 draft-ietf-core-sid Last calls: Reviewer LC end Draft John Bradley 2021-03-16 draft-ietf-idr-bgp-ls-registry Nancy Cam-Winget 2021-06-08 draft-ietf-oauth-par Nancy Cam-Winget R2021-06-28 draft-ietf-opsec-ipv6-eh-filtering Shaun Cooley 2021-02-25 draft-ietf-v6ops-ipv6-ehs-packet-drops Alan DeKok 2021-03-24 draft-ietf-cbor-tags-oid Daniel Gillmor 2021-03-26 draft-ietf-lamps-crmf-update-algs Steve Hanna 2021-03-22 draft-ietf-regext-secure-authinfo-transfer Leif Johansson None draft-ietf-netconf-crypto-types Watson Ladd None draft-ietf-netconf-tls-client-server Aanchal Malhotra None draft-ietf-opsawg-l3sm-l3nm Catherine Meadows 2021-07-07 draft-ietf-httpbis-cache-header Catherine Meadows 2021-04-14 draft-ietf-ntp-interleaved-modes Kathleen Moriarty 2021-04-27 draft-ietf-bess-mvpn-msdp-sa-interoperation Russ Mundy 2021-04-20 draft-ietf-dprive-xfr-over-tls Sandra Murphy R2021-04-05 draft-ietf-dmarc-psd Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Yoav Nir 2021-04-28 draft-ietf-core-new-block Hilarie Orman 2021-07-20 draft-ietf-opsawg-ipfix-mpls-sr-label-type Melinda Shore 2021-05-17 draft-ietf-payload-rtp-jpegxs Mališa Vučinić 2021-06-10 draft-ietf-httpbis-semantics Mališa Vučinić R2021-02-24 draft-ietf-curdle-ssh-kex-sha2 Carl Wallace R2021-02-22 draft-ietf-tcpm-2140bis Samuel Weiler 2021-02-22 draft-ietf-tls-dtls13 Brian Weis 2021-02-19 draft-ietf-lamps-cms-aes-gmac-alg Klaas Wierenga 2020-12-02 draft-ietf-core-echo-request-tag Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Paul Wouters 2021-06-10 draft-ietf-httpbis-messaging Liang Xia 2021-03-17 draft-ietf-core-sid Early review requests: Reviewer Due Draft Stephen Farrell 2021-06-21 draft-ietf-idr-bgpls-srv6-ext Daniel Migault 2021-07-31 draft-ietf-httpbis-message-signatures Magnus Nystrom 2021-07-23 draft-ietf-drip-rid Tina Tsou 2021-02-15 draft-ietf-idr-eag-distribution Dacheng Zhang 2020-12-07 draft-ietf-idr-eag-distribution Next in the reviewer rotation: Radia Perlman Derrell Piper Tim Polk Tirumaleswar Reddy.K Vincent Roca Kyle Rose Joseph Salowey Rich Salz Stefan Santesson Yaron Sheffer From nobody Tue Jul 13 08:18:03 2021 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 DEE1E3A16A8; Tue, 13 Jul 2021 08:17:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?b?TWFsacWhYSBWdcSNaW5pxIcgdmlhIERhdGF0cmFja2Vy?= To: Cc: curdle@ietf.org, draft-ietf-curdle-ssh-kex-sha2.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162618947268.22195.15300640251581898839@ietfa.amsl.com> Reply-To: =?utf-8?b?TWFsacWhYSBWdcSNaW5pxIc=?= Date: Tue, 13 Jul 2021 08:17:52 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-curdle-ssh-kex-sha2-19 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, 13 Jul 2021 15:17:53 -0000 Reviewer: Mališa Vučinić 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. I have previously reviewed version -14 of this document and have now went through version -19. I find that the document has significantly improved in quality and I would like to thank Mark for addressing my comments. From nobody Tue Jul 13 19:30:46 2021 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 8E87E3A1248; Tue, 13 Jul 2021 19:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1626229776; bh=dQKqrvupzKEIvYIFB2YTYnOaDlPlJPrekJWEzpMuf7I=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=MfQnaXKOgyo8/GPTwsBp94kMEO/u3y5ka2qTlZQmqpS2wG30Ato/Lzp8Ucx6CxjxN wsMpGbW8AsJRcwrkE9XNzIRSlXXlZetykMRDf7mqH+v41eKVQMiWHFS1/VtgIQd8Zv cscZ1+cEB7zT0mN3nGmysjkvwXHTm+SR5TArAVhA= X-Mailbox-Line: From new-work-bounces@ietf.org Tue Jul 13 19:29:36 2021 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC623A123F; Tue, 13 Jul 2021 19:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1626229775; bh=dQKqrvupzKEIvYIFB2YTYnOaDlPlJPrekJWEzpMuf7I=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=f7NjriJR+6RbMuVnMYl7584SOqSmnMX/fqSGgpLwDzIZPRw/Un50hmJdtohRhtOmi QSPewZ6OwkAqEn2V4RJEVJcszpTuZtKtEYq2MQbm0v+KNlXuMBe09z0bEpUvefQ7ET Ljk9i4KAYoK5c5k6a8SovIJoqKgJehAIyIl0Lp0U= 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 DA2FA3A123E for ; Tue, 13 Jul 2021 19:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_BLOCKED=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 dWTp1kDOHSS3 for ; Tue, 13 Jul 2021 19:29:29 -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 0D4C73A1235 for ; Tue, 13 Jul 2021 19:29:28 -0700 (PDT) Received: from [45.145.248.93] (helo=jiaxueyuandeMacBook-Pro.local) by raoul.w3.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1m3UeM-0003Ew-UG for new-work@ietf.org; Wed, 14 Jul 2021 02:29:27 +0000 To: new-work@ietf.org From: xueyuan Message-ID: <648b5aa4-223e-13e8-10f9-887699f38d71@w3.org> Date: Wed, 14 Jul 2021 10:29:22 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.11.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, 13 Jul 2021 19:30:45 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Spatial Data on the Web Working Group (until 2021-08-16/17) 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, 14 Jul 2021 02:29:40 -0000 SGVsbG8sCgpUb2RheSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcyByZWNl aXZlZCBhIFByb3Bvc2FsCnRvIHJldmlldyBhIGRyYWZ0IGNoYXJ0ZXIgZm9yIHRoZSBTcGF0aWFs IERhdGEgb24gdGhlIFdlYiBXb3JraW5nIEdyb3VwOgogwqAgaHR0cHM6Ly93d3cudzMub3JnLzIw MjEvMDcvcHJvcG9zZWQtc2R3d2ctY2hhcnRlci5odG1sCgpBcyBwYXJ0IG9mIGVuc3VyaW5nIHRo YXQgdGhlIGNvbW11bml0eSBpcyBhd2FyZSBvZiBwcm9wb3NlZCB3b3JrCmF0IFczQywgdGhpcyBk cmFmdCBjaGFydGVyIGlzIHB1YmxpYyBkdXJpbmcgdGhlIEFkdmlzb3J5CkNvbW1pdHRlZSByZXZp ZXcgcGVyaW9kLgoKVzNDIGludml0ZXMgcHVibGljIGNvbW1lbnRzIHRocm91Z2ggMDM6NTkgVVRD IG9uIDE3IEF1Z3VzdCwgMjAyMQooMjM6NTksIEJvc3RvbiB0aW1lIG9uIDE2IEF1Z3VzdCkgb24g dGhlIHByb3Bvc2VkIGNoYXJ0ZXIuClBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvIHB1YmxpYy1uZXct d29ya0B3My5vcmcsCndoaWNoIGhhcyBhIHB1YmxpYyBhcmNoaXZlOgogwqAgaHR0cDovL2xpc3Rz LnczLm9yZy9BcmNoaXZlcy9QdWJsaWMvcHVibGljLW5ldy13b3JrLwoKT3RoZXIgdGhhbiBjb21t ZW50cyBzZW50IGluIGZvcm1hbCByZXNwb25zZXMgYnkgVzNDIEFkdmlzb3J5CkNvbW1pdHRlZSBS ZXByZXNlbnRhdGl2ZXMsIFczQyBjYW5ub3QgZ3VhcmFudGVlIGEgcmVzcG9uc2UgdG8KY29tbWVu dHMuIElmIHlvdSB3b3JrIGZvciBhIFczQyBNZW1iZXIgWzFdLCBwbGVhc2UgY29vcmRpbmF0ZQp5 b3VyIGNvbW1lbnRzIHdpdGggeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRpdmUu IEZvcgpleGFtcGxlLCB5b3UgbWF5IHdpc2ggdG8gbWFrZSBwdWJsaWMgY29tbWVudHMgdmlhIHRo aXMgbGlzdCBhbmQKaGF2ZSB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZSBy ZWZlciB0byBpdCBmcm9tIGhpcwpvciBoZXIgZm9ybWFsIHJldmlldyBjb21tZW50cy4KCklmIHlv dSBzaG91bGQgaGF2ZSBhbnkgcXVlc3Rpb25zIG9yIG5lZWQgZnVydGhlciBpbmZvcm1hdGlvbiwg cGxlYXNlCmNvbnRhY3QgV2VuZHkgU2VsdHplciwgVzNDIFN0cmF0ZWd5IExlYWQsIGF0IDx3c2Vs dHplckB3My5vcmc+LgoKVGhhbmsgeW91LAoKWHVleXVhbiBKaWEswqAgVzNDIE1hcmtldGluZyAm IENvbW11bmljYXRpb25zCgpbMV0gaHR0cDovL3d3dy53My5vcmcvQ29uc29ydGl1bS9NZW1iZXIv TGlzdAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV3 LXdvcmsgbWFpbGluZyBsaXN0Cm5ldy13b3JrQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV3LXdvcmsK From nobody Thu Jul 15 11:14:42 2021 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 63E1A3A17CC; Thu, 15 Jul 2021 11:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEt-wK8KQ7o0; Thu, 15 Jul 2021 11:14:35 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CBF43A17A7; Thu, 15 Jul 2021 11:14:34 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 16FIESMf003183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Jul 2021 14:14:33 -0400 Date: Thu, 15 Jul 2021 11:14:28 -0700 From: Benjamin Kaduk To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Cc: secdir@ietf.org, curdle@ietf.org Message-ID: <20210715181428.GT74365@kduck.mit.edu> References: <162618947268.22195.15300640251581898839@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <162618947268.22195.15300640251581898839@ietfa.amsl.com> Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-curdle-ssh-kex-sha2-19 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, 15 Jul 2021 18:14:37 -0000 Thanks, Mali=C5=A1a! It's reassuring to hear that your comments have been addressed, and the document is certainly improved for them. -Ben On Tue, Jul 13, 2021 at 08:17:52AM -0700, Mali=C5=A1a Vu=C4=8Dini=C4=87 via= Datatracker wrote: > Reviewer: Mali=C5=A1a Vu=C4=8Dini=C4=87 > Review result: Ready >=20 > 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. These > comments were written primarily for the benefit of the security area dire= ctors. > Document editors and WG chairs should treat these comments just like any= other > last call comments. >=20 > I have previously reviewed version -14 of this document and have now went > through version -19. I find that the document has significantly improved = in > quality and =10I would like to thank Mark for addressing my comments. >=20 >=20 From nobody Fri Jul 16 12:20:16 2021 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 D65933A417B; Fri, 16 Jul 2021 12:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 eXs0vcMVDSXg; Fri, 16 Jul 2021 12:20:07 -0700 (PDT) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) (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 4B68B3A4177; Fri, 16 Jul 2021 12:20:03 -0700 (PDT) Received: from in02.mta.xmission.com ([166.70.13.52]) by out02.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1m4TNS-00CNas-Ng; Fri, 16 Jul 2021 13:20:02 -0600 Received: from [166.70.232.207] (port=7345 helo=rumpleteazer.rhmr.com) by in02.mta.xmission.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1m4TNR-00Dv26-QV; Fri, 16 Jul 2021 13:20:02 -0600 Received: from rumpleteazer.rhmr.com (localhost [127.0.0.1]) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 16GJJ8cj031708; Fri, 16 Jul 2021 13:19:08 -0600 Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id 16GJJ8V4031707; Fri, 16 Jul 2021 13:19:08 -0600 Date: Fri, 16 Jul 2021 13:19:08 -0600 Message-Id: <202107161919.16GJJ8V4031707@rumpleteazer.rhmr.com> From: "Hilarie Orman" Reply-To: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org Cc: draft-ietf-opsawg-ipfix-mpls-sr-label-type.all@ietf.org X-XM-SPF: eid=1m4TNR-00Dv26-QV; ; ; mid=<202107161919.16GJJ8V4031707@rumpleteazer.rhmr.com>; ; ; hst=in02.mta.xmission.com; ; ; ip=166.70.232.207; ; ; frm=hilarie@purplestreak.com; ; ; spf=pass X-XM-AID: U2FsdGVkX18YE+pN8iZlOHAN3sDaxJxl X-SA-Exim-Connect-IP: 166.70.232.207 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *******;iesg@ietf.org, secdir@ietf.org X-Spam-Relay-Country: X-Spam-Timing: total 459 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 11 (2.4%), b_tie_ro: 10 (2.1%), parse: 0.76 (0.2%), extract_message_metadata: 3.4 (0.7%), get_uri_detail_list: 0.61 (0.1%), tests_pri_-1000: 3.2 (0.7%), tests_pri_-950: 1.58 (0.3%), tests_pri_-900: 1.21 (0.3%), tests_pri_-90: 85 (18.5%), check_bayes: 83 (18.1%), b_tokenize: 7 (1.4%), b_tok_get_all: 5 (1.1%), b_comp_prob: 2.8 (0.6%), b_tok_touch_all: 65 (14.2%), b_finish: 0.99 (0.2%), tests_pri_0: 338 (73.6%), check_dkim_signature: 0.43 (0.1%), check_dkim_adsp: 46 (10.0%), poll_dns_idle: 39 (8.4%), tests_pri_10: 3.2 (0.7%), tests_pri_500: 10 (2.1%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Archived-At: Subject: [secdir] Security directorate review of draft-ietf-opsawg-ipfix-mpls-sr-label-type-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: Fri, 16 Jul 2021 19:20:10 -0000 Security review of Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX) draft-ietf-opsawg-ipfix-mpls-sr-label-type-07 Do not be alarmed. I generated this review of this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. The document introduces named code points support 4 new routing extensions for Segment Routing domains. It does not impact the security of the extended protocols. Hilarie From nobody Sat Jul 17 14:09:12 2021 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 653F93A21A1 for ; Sat, 17 Jul 2021 14:09:10 -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, 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 doc5ap3_YcgK for ; Sat, 17 Jul 2021 14:09:05 -0700 (PDT) Received: from mail.digitalbazaar.com (mail.digitalbazaar.com [96.89.14.193]) (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 C937D3A219F for ; Sat, 17 Jul 2021 14:09:04 -0700 (PDT) Received: from [73.152.135.186] (helo=[10.4.10.95]) by mail.digitalbazaar.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1m4rYO-0003Ql-Mn for secdir@ietf.org; Sat, 17 Jul 2021 17:09:01 -0400 To: secdir@ietf.org From: Manu Sporny Message-ID: Date: Sat, 17 Jul 2021 17:08:55 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 73.152.135.186 X-SA-Exim-Mail-From: msporny@digitalbazaar.com X-SA-Exim-Version: 4.2.1 (built Tue, 02 Aug 2016 21:08:31 +0000) X-SA-Exim-Scanned: Yes (on mail.digitalbazaar.com) Archived-At: Subject: [secdir] W3C VC/DID WG Security Review Coordination Request 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: Sat, 17 Jul 2021 21:09:11 -0000 Benjamin, Roman, and the IETF Security Area Directorate, I am writing on behalf of the Chairs, Staff, and Members of multiple current chartered W3C Working Groups related to Verifiable Credentials[1] (VCs) and Decentralized Identifiers[2] (DIDs). The outcome of this message also could affect future W3C Working Groups currently in the pre-chartering process related to RDF Dataset Canonicalization and Hashing, and Linked Data Integrity[3]. TL;DR: There are two requests in this message. The first is from the DID WG, for a best-effort security review of the Decentralized Identifier Core specification[4] by an appropriate IETF group. The second is from the current VC and DID WGs, on behalf of themselves and the above-mentioned pre-charter WGs, to set up regular and recurring security reviews of specific W3C specifications that will be developed over the next several years, in a capacity that is more coupled than a traditional W3C-IETF liaison relationship. Both requests are further detailed in the rest of this message. Review of DID Core Specification -------------------------------- Mark Nottingham, Co-Chair of the HTTP WG, recently inquired about the security and privacy reviews that were performed on DID Core. The W3C DID WG has performed multiple security and privacy reviews on the specification[6], per the W3C process. In addition to those reviews, we are hoping that the IETF secdir or CFRG will guide us toward receiving additional security reviews on the specification. What would be the best path to getting an initial best-effort security review of the DID Core specification, and subsequent security reviews every six months or so on iterations of that specification? I will note two important considerations. The first is that the initial DID WG charter expires in September 2021, the specification comes out of the 2nd W3C Candidate Recommendation phase in mid-July 2021, and according to W3C Process, the DID WG has enough implementation experience (32 implementations for many features) to move on to the W3C Proposed Recommendation phase. The second consideration is that the DID WG has only defined a data model and has not defined any cryptographic algorithms or protocols in this iteration of the specification. That said, the specification is expected to be used with cryptographic systems, and furthermore, protocol work might be included in the work of a re-chartered (future) group. Thus, we desire more eyes on the specification, especially from IETF Security Area Directorate and IRTF CFRG. Benjamin and Roman, what mechanism would be most effective for achieving a timely, best-effort review of the W3C Decentralized Identifiers specification? Targeted Engagement with Future DID and VC-related work at W3C -------------------------------------------------------------- Since the Recommendation of the W3C Verifiable Credentials specification[7], and the expected Recommendation of the W3C Decentralized Identifiers specification[4], there has been increased movement in government and the private sector towards issuing credentials for a variety of use cases in a production capacity. As a result, it is highly likely that both the W3C Verifiable Credentials WG and the W3C Decentralized Identifiers WG will be re-chartered to maintain and/or advance the work. In addition, new cryptographic packaging formats and protocols[3][8] based on active IETF work[9][10] and/or RFCs are expected to be advanced in parallel. The chartered W3C Working Groups are requesting a more direct liaison relationship that goes beyond periodic reviews of the specifications under development by these groups. Ideally, participants in the IETF Security Area would be active members of these W3C Working Groups with an additional liaison relationship to groups like the IRTF CFRG. There is a strong expectation that newly chartered groups that are related to the technologies mentioned throughout this email will request the same type of relationship. Benjamin and Roman, what mechanism would be most effective for setting up this more formal and active relationship between the IETF Security Area and the W3C Working Groups mentioned above? ----------------------------------------------------- Thank you for your time in considering the questions that we have put forward in this message. We know that this is only the beginning of the discussion, so don't expect definitive answers in initial responses, but hope for some concrete guidance on next steps. On behalf of the Editors, Chairs, and Staff contacts for W3C Verifiable Credentials WG and the W3C Decentralized Identifiers WG, -- manu [1]https://www.w3.org/2017/vc/WG/ [2]https://www.w3.org/2019/did-wg/ [3]https://w3c.github.io/lds-wg-charter/ [4]https://w3c.github.io/did-core/ [5]https://github.com/w3c/did-core/issues/768 [6]https://github.com/w3c/did-core/issues/768#issuecomment-869209663 [7]https://www.w3.org/TR/vc-data-model/ [8]https://w3c.github.io/lds-wg-charter/explainer.html [9]https://datatracker.ietf.org/doc/draft-irtf-cfrg-pairing-friendly-curves/ [10]https://datatracker.ietf.org/doc/draft-irtf-cfrg-bls-signature/ -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. News: Digital Bazaar Announces New Case Studies (2021) https://www.digitalbazaar.com/ From nobody Mon Jul 19 08:08:09 2021 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 974E23A36D3 for ; Mon, 19 Jul 2021 08:07:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <162670727752.16331.8646364387171425709@ietfa.amsl.com> Date: Mon, 19 Jul 2021 08:07:57 -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: Mon, 19 Jul 2021 15:08:08 -0000 Because of the IEEE meeting last week and this week, I did not have time to do assignments last week, so I am doing them now. This means there might be bit less time to review the documents than normally. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2021-08-12 Reviewer LC end Draft Catherine Meadows 2021-07-07 draft-ietf-httpbis-cache-header Last calls: Reviewer LC end Draft Nancy Cam-Winget R2021-06-28 draft-ietf-opsec-ipv6-eh-filtering Nancy Cam-Winget 2021-06-08 draft-ietf-oauth-par Steve Hanna 2021-03-22 draft-ietf-regext-secure-authinfo-transfer Leif Johansson None draft-ietf-netconf-crypto-types Watson Ladd None draft-ietf-netconf-tls-client-server Catherine Meadows 2021-04-14 draft-ietf-ntp-interleaved-modes Catherine Meadows 2021-07-07 draft-ietf-httpbis-cache-header Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Radia Perlman 2021-08-13 draft-housley-ers-asn1-modules Derrell Piper 2021-08-09 draft-ietf-mmusic-rfc8843bis Tim Polk 2021-08-06 draft-ietf-opsawg-vpn-common Tirumaleswar Reddy.K 2021-08-06 draft-ietf-opsawg-l3sm-l3nm Vincent Roca 2021-08-02 draft-ietf-alto-performance-metrics Kyle Rose 2021-08-02 draft-ietf-tcpm-rfc793bis Joseph Salowey 2021-07-23 draft-ietf-httpbis-bcp56bis Melinda Shore 2021-05-17 draft-ietf-payload-rtp-jpegxs Mališa Vučinić 2021-06-10 draft-ietf-httpbis-semantics Klaas Wierenga 2020-12-02 draft-ietf-core-echo-request-tag Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Paul Wouters 2021-06-10 draft-ietf-httpbis-messaging Liang Xia 2021-03-17 draft-ietf-core-sid Early review requests: Reviewer Due Draft Stephen Farrell 2021-06-21 draft-ietf-idr-bgpls-srv6-ext Daniel Migault 2021-07-31 draft-ietf-httpbis-message-signatures Magnus Nystrom 2021-07-23 draft-ietf-drip-rid Next in the reviewer rotation: Rich Salz Stefan Santesson Yaron Sheffer Rifaat Shekh-Yusef Melinda Shore Valery Smyslov Robert Sparks Tina Tsou Sean Turner Loganaden Velvindron From nobody Tue Jul 20 09:43:26 2021 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 760133A1627; Tue, 20 Jul 2021 00:30:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1626766222; bh=rmEgU2lvVT7LSnXeBSpxtqFZOFxAD4AJ7B8/O2i7bz4=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=AO2gayYjqCC6su6s297FHpDZCRbn3BlIRiHwV2PaQlvnKvILZkub4jb7cd7BrdgJZ 4h7ATuP3SK9lILnCTyhmmqQ9+6NDGPY1ljRR7HJX88eO1rg2Q0Vs4JuxG3Nd27XIvP fBo6hmRCTeh5HotdW+3zZd+Wppham+/i0p/QfVrI= X-Mailbox-Line: From new-work-bounces@ietf.org Tue Jul 20 00:30:21 2021 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C87B43A1629; Tue, 20 Jul 2021 00:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1626766221; bh=rmEgU2lvVT7LSnXeBSpxtqFZOFxAD4AJ7B8/O2i7bz4=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=Hl5mWVazsiREEgADTC/7NOrTsXPID0kP7k0m3Mz0N20T6MrbG5M0LRJQxij3UOdG/ QSaRQbTbQVRPdjYr8zVfEKfmVLO9xQ7bMLmo672km4k1FVA/JvO7XSol+Gip6VBC9D 7mkBcRu/6KgGz+GVaWMAVBC3Z9yyxIgJIMW2khgM= 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 9F6FB3A1628 for ; Tue, 20 Jul 2021 00:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, 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 dA4xfPPWBzPV for ; Tue, 20 Jul 2021 00:30:13 -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 99A713A1627 for ; Tue, 20 Jul 2021 00:30:13 -0700 (PDT) Received: from [45.145.248.126] (helo=jiaxueyuandeMacBook-Pro.local) by raoul.w3.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1m5kCh-000467-56 for new-work@ietf.org; Tue, 20 Jul 2021 07:30:11 +0000 To: new-work@ietf.org From: xueyuan Message-ID: <6fd12b03-85e1-636f-6e47-1156330bd9e5@w3.org> Date: Tue, 20 Jul 2021 15:30:05 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.12.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, 20 Jul 2021 09:43:25 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Portable Network Graphics (PNG) Working Group (until 2021-08-18/19) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2021 07:30:25 -0000 SGVsbG8sCgpUb2RheSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcyByZWNl aXZlZCBhIFByb3Bvc2FsCnRvIHJldmlldyBhIGRyYWZ0IGNoYXJ0ZXIgZm9yIHRoZSBQb3J0YWJs ZSBOZXR3b3JrIEdyYXBoaWNzIChQTkcpCldvcmtpbmcgR3JvdXA6CiDCoCBodHRwczovL3d3dy53 My5vcmcvR3JhcGhpY3MvUE5HL3BuZy0yMDIxLWFjLmh0bWwKCkFzIHBhcnQgb2YgZW5zdXJpbmcg dGhhdCB0aGUgY29tbXVuaXR5IGlzIGF3YXJlIG9mIHByb3Bvc2VkIHdvcmsKYXQgVzNDLCB0aGlz IGRyYWZ0IGNoYXJ0ZXIgaXMgcHVibGljIGR1cmluZyB0aGUgQWR2aXNvcnkKQ29tbWl0dGVlIHJl dmlldyBwZXJpb2QuCgpXM0MgaW52aXRlcyBwdWJsaWMgY29tbWVudHMgdGhyb3VnaCAwMzo1OSBV VEMgb24gMTkgQXVndXN0LCAyMDIxCigyMzo1OSwgQm9zdG9uIHRpbWUgb24gMTggQXVndXN0KSBv biB0aGUgcHJvcG9zZWQgY2hhcnRlci4KUGxlYXNlIHNlbmQgY29tbWVudHMgdG8gcHVibGljLW5l dy13b3JrQHczLm9yZywKd2hpY2ggaGFzIGEgcHVibGljIGFyY2hpdmU6CiDCoCBodHRwOi8vbGlz dHMudzMub3JnL0FyY2hpdmVzL1B1YmxpYy9wdWJsaWMtbmV3LXdvcmsvCgpPdGhlciB0aGFuIGNv bW1lbnRzIHNlbnQgaW4gZm9ybWFsIHJlc3BvbnNlcyBieSBXM0MgQWR2aXNvcnkKQ29tbWl0dGVl IFJlcHJlc2VudGF0aXZlcywgVzNDIGNhbm5vdCBndWFyYW50ZWUgYSByZXNwb25zZSB0bwpjb21t ZW50cy4gSWYgeW91IHdvcmsgZm9yIGEgVzNDIE1lbWJlciBbMV0sIHBsZWFzZSBjb29yZGluYXRl CnlvdXIgY29tbWVudHMgd2l0aCB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2 ZS4gRm9yCmV4YW1wbGUsIHlvdSBtYXkgd2lzaCB0byBtYWtlIHB1YmxpYyBjb21tZW50cyB2aWEg dGhpcyBsaXN0IGFuZApoYXZlIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZl IHJlZmVyIHRvIGl0IGZyb20gaGlzCm9yIGhlciBmb3JtYWwgcmV2aWV3IGNvbW1lbnRzLgoKSWYg eW91IHNob3VsZCBoYXZlIGFueSBxdWVzdGlvbnMgb3IgbmVlZCBmdXJ0aGVyIGluZm9ybWF0aW9u LCBwbGVhc2UKY29udGFjdCBDaHJpcyBMaWxsZXksIGF0IDxjaHJpc0B3My5vcmc+LgoKVGhhbmsg eW91LAoKWHVleXVhbiBKaWEswqAgVzNDIE1hcmtldGluZyAmIENvbW11bmljYXRpb25zCgpbMV0g aHR0cDovL3d3dy53My5vcmcvQ29uc29ydGl1bS9NZW1iZXIvTGlzdAoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV3LXdvcmsgbWFpbGluZyBsaXN0Cm5l dy13b3JrQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV3 LXdvcmsK From nobody Wed Jul 21 07:47:25 2021 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 6052E3A1A89; Wed, 21 Jul 2021 07:47:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Vincent Roca via Datatracker To: Cc: alto@ietf.org, draft-ietf-alto-performance-metrics.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162687883633.10402.5545650896931874658@ietfa.amsl.com> Reply-To: Vincent Roca Date: Wed, 21 Jul 2021 07:47:16 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-alto-performance-metrics-16 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, 21 Jul 2021 14:47:17 -0000 Reviewer: Vincent Roca Review result: Ready Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The "Security considerations" section extensively refers to RFC 7285 which makes sense. I have no comment. I consider this document as "READY" from the secdir point of view. Minor comment: the "TE" acronym is used without being defined (it is only the case in references) Regards, Vincent From nobody Wed Jul 21 22:54:50 2021 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 B9D3C3A3991; Wed, 21 Jul 2021 22:54:47 -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-netconf-tls-client-server.all@ietf.org, last-call@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162693328770.27111.6978873343722392140@ietfa.amsl.com> Reply-To: Watson Ladd Date: Wed, 21 Jul 2021 22:54:47 -0700 Archived-At: Subject: [secdir] Secdir last call partial review of draft-ietf-netconf-tls-client-server-25 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, 22 Jul 2021 05:54:49 -0000 Review is partially done. Another assignment may be needed to complete it. Reviewer: Watson Ladd Review result: Ready Dear readers, Forgive my completing this review almost a month late. 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, because I can't find anything wrong with it. Your comfort with this fact should be minimal. Benjamin Kaduk writes me to inform you that the issues with the PSK in TLS 1.3 are being worked on. And now on to my evaluation of the document. The problem is that I can't evaluate this in any substantive way: it is a whole bunch of YANG, a technology I am completely ignorant of. The few English sentences I saw looked fine, and I didn't spot anything wrong, but I likely wouldn't have. Sincerely, Watson Ladd From nobody Thu Jul 22 07:36:48 2021 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 69FF93A4895 for ; Thu, 22 Jul 2021 07:36:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <162696460641.20927.15446648272683672256@ietfa.amsl.com> Date: Thu, 22 Jul 2021 07:36:46 -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, 22 Jul 2021 14:36:46 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2021-08-12 Reviewer LC end Draft Catherine Meadows 2021-07-07 draft-ietf-httpbis-cache-header Robert Sparks R2021-02-15 draft-ietf-6lo-plc Last calls: Reviewer LC end Draft Nancy Cam-Winget R2021-06-28 draft-ietf-opsec-ipv6-eh-filtering Nancy Cam-Winget 2021-06-08 draft-ietf-oauth-par Steve Hanna 2021-03-22 draft-ietf-regext-secure-authinfo-transfer Leif Johansson None draft-ietf-netconf-crypto-types Catherine Meadows 2021-04-14 draft-ietf-ntp-interleaved-modes Catherine Meadows 2021-07-07 draft-ietf-httpbis-cache-header Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Radia Perlman 2021-08-13 draft-housley-ers-asn1-modules Derrell Piper 2021-08-09 draft-ietf-mmusic-rfc8843bis Tim Polk 2021-08-06 draft-ietf-opsawg-vpn-common Tirumaleswar Reddy.K 2021-08-06 draft-ietf-opsawg-l3sm-l3nm Kyle Rose 2021-08-02 draft-ietf-tcpm-rfc793bis Joseph Salowey 2021-07-23 draft-ietf-httpbis-bcp56bis Rich Salz 2021-08-11 draft-ietf-httpbis-proxy-status Stefan Santesson 2021-08-11 draft-ietf-bier-te-arch Yaron Sheffer None draft-ietf-lsr-pce-discovery-security-support Melinda Shore 2021-05-17 draft-ietf-payload-rtp-jpegxs Robert Sparks R2021-02-15 draft-ietf-6lo-plc Mališa Vučinić 2021-06-10 draft-ietf-httpbis-semantics Klaas Wierenga 2020-12-02 draft-ietf-core-echo-request-tag Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Paul Wouters 2021-06-10 draft-ietf-httpbis-messaging Liang Xia 2021-03-17 draft-ietf-core-sid Early review requests: Reviewer Due Draft Stephen Farrell 2021-06-21 draft-ietf-idr-bgpls-srv6-ext Daniel Migault 2021-07-31 draft-ietf-httpbis-message-signatures Magnus Nystrom 2021-07-23 draft-ietf-drip-rid Next in the reviewer rotation: Rifaat Shekh-Yusef Melinda Shore Valery Smyslov Robert Sparks Tina Tsou Sean Turner Loganaden Velvindron Mališa Vučinić Carl Wallace Samuel Weiler From nobody Thu Jul 22 11:29:09 2021 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 90C5F3A0D00; Thu, 22 Jul 2021 11:29:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rich Salz via Datatracker To: Cc: draft-ietf-httpbis-proxy-status.all@ietf.org, ietf-http-wg@w3.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162697854353.10606.9218891088339688790@ietfa.amsl.com> Reply-To: Rich Salz Date: Thu, 22 Jul 2021 11:29:03 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-httpbis-proxy-status-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: Thu, 22 Jul 2021 18:29:04 -0000 Reviewer: Rich Salz Review result: Has Nits This is the SECDIR review of the draft, primarily for the benefit of the Security AD's. All others can treat this as any other last-call comments. It's ready, there are some nits/confusions/inconsistencies that should be cleared up. While the draft says it is both for CDN like things and outgoing reverse proxies, it doesn't quite seem that way. For example, Sec 2 the Proxy-Status HTTP field says the order is first closest to the origin, and last closest to the user-agent. Shouldn't it always be in the direction of travel? The example, shows "FooProxy, ExampleCDN", but the explanation doesn't fit if there is an outbound proxy. Or maybe it's "FooProxy" is a proxy at the origin side? Either way, I think there's an ambiguity there that needs to be cleaned up. Implied, but should be stated, as that when the request arrives at the origin, any proxy-status headers should be removed before responding. Sec 2.1.3 should maybe refer to the ALPN registry directly. All current values are US-ASCII, and that seems unlikely to change. Saying UTF-8 seems contradictory since sf-string is ASCII-only. Sec 2.1.4 talks about received status, which is "in the opposite direction" from 2.1.3 Perhaps split this up into "common" "sender" "receiver" types of status fields? Sec 2.1.5 uses sf-string which doesn't allow utf8 localization or markers thereof. should it? Sec 2.2 says "[a] specification document is appreciated, but not required." Then the Reference bullet item needs editing. I prefer to make it spec required. Sec 2.3.3 says "destination not found" It should have a forward link to 2.3.6 Consider shuffling some of those error cases around so that they fall into things like "proxy failures" "infrastructure failures" "next hop did something bad" And consider making three subsections for each class. I think having both "connection_limit_reached" and "destination_ip_prohibited" is too fine a grain, but not worth arguing about. (shades of 451 I guess) The TLS errors should have "alert number" as extra info. (Not the alert-message as mentioned in 2.3.15) I am confused by 2.3.18 and 2.3.8 or even 2.3.10; maybe some guidance on when to use each? I think, again, splitting this section up is worthwhile. Maybe add "http errors" "tls errors" -- i.e., what layer in the IETF protocol model broke. That, or the traffic direction suggest above, might really help implementors. 2.3.29 has no recommended http stauts code. 2.4 says a specification is appreciated, but the registration form doesn't list one. Similar to the comments above about Sec 2.2 From nobody Thu Jul 22 18:59:06 2021 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 E090E3A1738; Thu, 22 Jul 2021 18:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=n/lBEhA7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GG+opeMr 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 QaFoN0DuHanV; Thu, 22 Jul 2021 18:58:55 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 941523A1732; Thu, 22 Jul 2021 18:58:54 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 281785C0131; Thu, 22 Jul 2021 21:58:53 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 22 Jul 2021 21:58:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=O Q+bvOfLBl3QjjAUuBnt7V6B5onIQyQT9phQZifNpr4=; b=n/lBEhA7zKSqKjOUD Hy/Wq1uL2A9TqI1GHA4srstYlkt3p9p5L9kjpJTSHXl23Nq222a0SvVrhldnPTMt CXybjpDUVMeGVweP4BrOXIiMjDiv8vwz0fEjgIa6t0QsOQCwG70Z1fUZOABnhRYO /8Iji+0uiTb+d1peblB1xRa5vUADTk9EuLxIeXlugEHbWrlb+sdDA9RjH1hN9Cmz jd9zwx8GqgTiOR/G6F6pzwNBPk7fnz9/+vS7gye4Vqk1/HvqFkD8ViWibeOziQKJ wzYxGSIDtR2T/ghMdwbSGBCLRvWKUhVxL6IQ3/ZjMQmIHkpe0ePe0Km+028Wuo0M CnRTA== 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=OQ+bvOfLBl3QjjAUuBnt7V6B5onIQyQT9phQZifNp r4=; b=GG+opeMr1Xc6mPTpJh23+05qVCL0RCt8aNvCmXpPF7Nec4nLoymCr9EQ8 vwLm3fKMC4QJ3RhuumrxxzfpONKTeL9Q952Udi5wijAxncMrOHTTmLuQmDmcnlZb PfDc8bPPuDnblYTrsvCvWCi+bz4xcUxe1VnzWgZ9qL3lIuS0jwydqiLTqU4tDtwI D0A31znVobkUl6HGihnRPfsKe8pZotopQS2leZWHdXkTYJ9x+9ggCBBLC3TKtG9n dBu0Rqh9N5sCX4SXV2oYAIPE3dXmAdna0diie1sODNzVlIrwJHmWQyNld63DGMli LXvjpFtKBOidvxB+kQv7YKy/ydk2A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrfeejgdeglecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepleffvdeuveffffekgefgffeugeehleekkeetjeelhfelkeevkeduieeivedvtefg necuffhomhgrihhnpehgihhthhhusgdrtghomhdpmhhnohhtrdhnvghtnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdr nhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 22 Jul 2021 21:58:49 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mark Nottingham In-Reply-To: <162697854353.10606.9218891088339688790@ietfa.amsl.com> Date: Fri, 23 Jul 2021 11:58:47 +1000 Cc: secdir@ietf.org, HTTP Working Group , last-call@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <10B337AE-C4A8-4F94-8F78-C68ECC22E16F@mnot.net> References: <162697854353.10606.9218891088339688790@ietfa.amsl.com> To: Rich Salz X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-httpbis-proxy-status-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: Fri, 23 Jul 2021 01:59:01 -0000 Thanks for the review, Rich. I've created: https://github.com/httpwg/http-extensions/issues/1580 > On 23 Jul 2021, at 4:29 am, Rich Salz via Datatracker = wrote: >=20 > Reviewer: Rich Salz > Review result: Has Nits >=20 > This is the SECDIR review of the draft, primarily for the benefit of = the > Security AD's. All others can treat this as any other last-call = comments. >=20 > It's ready, there are some nits/confusions/inconsistencies that should = be > cleared up. >=20 > While the draft says it is both for CDN like things and outgoing = reverse > proxies, it doesn't quite seem that way. For example, Sec 2 the = Proxy-Status > HTTP field says the order is first closest to the origin, and last = closest to > the user-agent. Shouldn't it always be in the direction of travel? = The > example, shows "FooProxy, ExampleCDN", but the explanation doesn't fit = if there > is an outbound proxy. Or maybe it's "FooProxy" is a proxy at the = origin side?=20 > Either way, I think there's an ambiguity there that needs to be = cleaned up. >=20 > Implied, but should be stated, as that when the request arrives at the = origin, > any proxy-status headers should be removed before responding. >=20 > Sec 2.1.3 should maybe refer to the ALPN registry directly. All = current values > are US-ASCII, and that seems unlikely to change. Saying UTF-8 seems > contradictory since sf-string is ASCII-only. >=20 > Sec 2.1.4 talks about received status, which is "in the opposite = direction" > from 2.1.3 Perhaps split this up into "common" "sender" "receiver" = types of > status fields? >=20 > Sec 2.1.5 uses sf-string which doesn't allow utf8 localization or = markers > thereof. should it? >=20 > Sec 2.2 says "[a] specification document is appreciated, but not = required."=20 > Then the Reference bullet item needs editing. I prefer to make it = spec > required. >=20 > Sec 2.3.3 says "destination not found" It should have a forward link = to 2.3.6=20 > Consider shuffling some of those error cases around so that they fall = into > things like "proxy failures" "infrastructure failures" "next hop did = something > bad" And consider making three subsections for each class. >=20 > I think having both "connection_limit_reached" and = "destination_ip_prohibited" > is too fine a grain, but not worth arguing about. (shades of 451 I = guess) >=20 > The TLS errors should have "alert number" as extra info. (Not the > alert-message as mentioned in 2.3.15) >=20 > I am confused by 2.3.18 and 2.3.8 or even 2.3.10; maybe some guidance = on when > to use each? >=20 > I think, again, splitting this section up is worthwhile. Maybe add = "http > errors" "tls errors" -- i.e., what layer in the IETF protocol model = broke.=20 > That, or the traffic direction suggest above, might really help = implementors. >=20 > 2.3.29 has no recommended http stauts code. >=20 > 2.4 says a specification is appreciated, but the registration form = doesn't list > one. Similar to the comments above about Sec 2.2 >=20 >=20 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Fri Jul 23 11:42:25 2021 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 285673A126D; Fri, 23 Jul 2021 11:42:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks via Datatracker To: Cc: 6lo@ietf.org, draft-ietf-6lo-plc.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162706573910.16734.11893490525630250602@ietfa.amsl.com> Reply-To: Robert Sparks Date: Fri, 23 Jul 2021 11:42:19 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-6lo-plc-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: Fri, 23 Jul 2021 18:42:19 -0000 Reviewer: Robert Sparks 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 is basically ready, but has nits that should be addressed before publication as Proposed Standard RFC. Context for the ADs, from my LC review: > This document's primary point is to standardize mappings of ipv6 identifiers for using ipv6 over IEEE 1901.1, 1901.2, and IT-T G.9903 networks. > Those standards are not publicy available, and I have not reviewed how these mappings and the security mechanisms in those protocols interact. My LC review suggested removing section 5 - Remy's response was that he would check with the WG. I don't find any discussion of that on the WG list? I still think it could be removed or moved to a separate document. My other comments have been addressed. This version introduces a few editorial nits that I will send directly to the editors. From nobody Fri Jul 23 22:14:49 2021 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 1B6173A2B52; Fri, 23 Jul 2021 22:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 0P6CZyxOXk8f; Fri, 23 Jul 2021 22:14:42 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 B46CB3A2B50; Fri, 23 Jul 2021 22:14:41 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id l126so4977767ioa.12; Fri, 23 Jul 2021 22:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=NQ4MjXiR8wjrB/fs+Cfbfj0NJJv0yy1ZsFY6T+ISKEw=; b=KdEwCsUkUqF/DszP8WLgqsR8qPbb9aBw9VuA4GJg8jeBl2oz2W+PtfgGfF8dsokrPp ixsbTOPK8B3ZfMOovfda030vNmKOT3kUEbbF5Nvs2sG2LKX1YBmGJpyYqlVdSoE8ygsT N4DxQxGRkreL1yJ+LK9gjtjmWNiD88zcgeQj+sCGco/TLwL6mYYZLwwx5JA/1AUMhDk3 KJSMWGUYBNQL1Y+GAyXVdGQ9Wnz0VPpvutrErhWfTpFbGfKxZRNJ2ZiW4hMEGXtK1beO hkDTHsWOk1ji5hmelG3fKBlGh13j/yONB55NHhlye8sICjE1PeaeZ7qXJAjd/8lfGoAh k0Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=NQ4MjXiR8wjrB/fs+Cfbfj0NJJv0yy1ZsFY6T+ISKEw=; b=VA+oebReTZViJMxY8ZnO0fft8jq8xlBcL0WfbWT7618QjAfJJ+3l6EIW2YFn4CCIAT 3+ulZOYelzJDANIY1GgwFEeO7I3L6xRFDvOnKpUR5whgjx5eOVYEKRiXid+J0tMuxPhe bkPMrA6oBy0YLv4qNgMexMjkNEzlletuzVQbOZAt4JP1rG5aWHVwdMR4STY5Zv3XREHf 5A2oQpqG889QNfXl9E9VSsmJ65XDwrBLlbHpozEyfqfo4KF0P4rk3BRUbgtgtbhAdIsd 5M3tyjazWiaA+Miv68udOb3i9ZkKdQsIhsC77dYaWwseUb/lI6yVaKGbEIKJE681rL2C h40Q== X-Gm-Message-State: AOAM530q0FG8it9zW9S3/G8GG8ExI4gpa01+dEBbhAIYpIz5V6A9a1S2 mlDzXpNDQQZ6soU1qzviQglL1MlYiQubP54o/974z/hnefE= X-Google-Smtp-Source: ABdhPJzMujNL4DptV+mdN6ZD1PjcIWExy5qIdBMD346set3p23QzxpDmWxtu6TV8LQH8O3z5kH5yOhuYY01P1uzf3VI= X-Received: by 2002:a02:cebb:: with SMTP id z27mr7084415jaq.72.1627103679940; Fri, 23 Jul 2021 22:14:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Date: Fri, 23 Jul 2021 22:14:29 -0700 Message-ID: To: secdir@ietf.org, draft-ietf-drip-rid@ietf.org Content-Type: multipart/alternative; boundary="000000000000db0a6105c7d79822" Archived-At: Subject: [secdir] Secdir review of draft-ietf-drip-rid-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: Sat, 24 Jul 2021 05:14:48 -0000 --000000000000db0a6105c7d79822 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 comments. This document describes the use of "Hierarchical Host Identity Tags" as self-asserting IPv6 addresses and thereby trustable identifiers for use as Remote IDs. As the security of HHITs to a large degree relies on the security of the cryptographic constructs and primitives described in this document, I would recommend that the IRTF CFRG or a similar group with cryptographic expertise reviews this memo (unless it has already been done). The security of the HHITs also seem to depend to a large degree on the registrars (registry operators) that will act as backstops to ensure no duplicate registrations etc. It might be helpful with a clear statement as to the conditions that must be met by registrars in order for this scheme to be secure. As noted, the use of a 64-bit hash is weak when considering pre-image attacks. I do not understand the constraints the authors have been working under in this context enough to say if there was an option for a longer hash, but I think this should be part of the above suggested CFRG review. The text "Another mitigation of HHIT hijacking is if the HI owner (UA) supplies an object containing the HHIT and signed by the HI private key of the HDA such as Appendix E.1 as shown in Section 3.5" confuses me a bit since I don't see how the subject of an attack would be able to tell should the HHIT hijack attempt occur before the HI owner has supplied such an object? Lastly, the statement "The authors believe that the probability of such an attack is low when Registry operators are using best practices" seems weak and would preferably be backed with some more quantitative analysis or at least specific statements around best practices and how they would reduce the probability. Editorial: The document is in need of a grammar / wording polish but I expect the rfc-editors to handle this. Thanks, -- Magnus --000000000000db0a6105c7d79822 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= div class=3D"gmail_quote">
I have reviewed this document as part of the security directorate's ong= oing effort to review all IETF documents being processed by the IESG. These= comments were written primarily for the benefit of the security area direc= tors.=C2=A0 Document editors and WG chairs should treat these comments just= like any other comments.

This document describes the use of "Hierarchical H= ost Identity Tags" as self-asserting IPv6 addresses and thereby trusta= ble identifiers for use as Remote IDs.

As the security of HHITs to a large degree relies= on the security of the cryptographic constructs and primitives described i= n this document, I would recommend that the IRTF CFRG or a similar group wi= th cryptographic expertise reviews this memo (unless it has already been do= ne).

The security of the HHITs also seem to depend= to a large degree on the registrars (registry operators) that will act as = backstops to ensure no duplicate registrations etc. It might be helpful wit= h a clear statement as to the conditions that must be met by registrars in = order for this scheme to be secure.

As noted, the = use of a 64-bit hash is weak when considering pre-image attacks. I do not u= nderstand the constraints the authors have been working under in this conte= xt enough to say if there was an option for a longer hash, but I think this= should be part of the above suggested CFRG review.

The text "Another mitigation of HHIT hijacking is if the HI owner (U= A) supplies an object containing the HHIT and signed by the HI private ke= y of the HDA such as Appendix E.1 as shown in Section = 3.5"=C2=A0 confuses me a bit since I don't see how the subject= of an attack would be able to tell should the HHIT hijack attempt occur be= fore the HI owner has supplied such an object?

Las= tly, the statement "The authors believe that the probability of such a= n attack is low when Registry operators are using best practices" se= ems weak and would preferably be backed with some more quantitative analysi= s or at least specific statements around best practices and how they would = reduce the probability.

Editorial: The documen= t is in need of a grammar / wording polish but I expect the rfc-editors to = handle this.

Thanks,
<= div>
-- Magnus


--000000000000db0a6105c7d79822-- From nobody Sun Jul 25 10:30:28 2021 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 2F4C23A32E9; Sun, 25 Jul 2021 10:30:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey via Datatracker To: Cc: draft-ietf-httpbis-bcp56bis.all@ietf.org, ietf-http-wg@w3.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162723422613.4754.2816752947598222075@ietfa.amsl.com> Reply-To: Joseph Salowey Date: Sun, 25 Jul 2021 10:30:26 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-httpbis-bcp56bis-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2021 17:30:26 -0000 Reviewer: Joseph Salowey Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is has issues The document is well written and very useful. There are a few issues I think need to be addressed. Major Issues: + I had trouble with section 4.12 Client Authentication which states: "Applications can use HTTP authentication Section 11 of [I-D.ietf-httpbis-semantics] to identify clients. The Basic authentication scheme [RFC7617] MUST NOT be used unless the underlying transport is authenticated, integrity-protected and confidential (e.g., as provided the "HTTPS" URI scheme, or another using TLS). The Digest scheme [RFC7616] MUST NOT be used unless the underlying transport is similarly secure, or the chosen hash algorithm is not "MD5"." I'm not sure what the "or chosen hash algorithm is not "MD5" is meant to say. What I think the document should say is: The Digest scheme [RFC7616] MUST NOT be used unless the underlying transport is similarly secure. The "MD5" digest algorithm MUST NOT be used. + There is a security consideration that I think the document should cover. Many HTTP based protocols make heavy use of bearer tokens, such as session cookies, for authentication and authorization purposes. This means that an attacker that can eavesdrop on HTTP communications can often escalate their privilege to perform operations on resources. I think you could add this to the security considerations: " Section 4.4.2 requires support for 'https' URLs, and discourages the use of 'http' URLs, to provide authentication, integrity and confidentiality, as well as mitigate pervasive monitoring attacks. Many HTTP based protocols make heavy use of bearer tokens, such as session cookies, for authentication and authorization purposes. This means that an attacker that can eavesdrop on HTTP communications can often escalate their privilege to perform operations on resources. " Minor Issues: + Section 4.5.1 - This could be a good place to mention RFC-8470 on TLS 1.3 early data which can also be a source of GET request replay From nobody Sun Jul 25 13:55:04 2021 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 B9A673A0763; Sun, 25 Jul 2021 13:54:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rifaat Shekh-Yusef via Datatracker To: Cc: draft-ietf-opsawg-l3sm-l3nm.all@ietf.org, last-call@ietf.org, opsawg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162724649271.1477.16367299362861096101@ietfa.amsl.com> Reply-To: Rifaat Shekh-Yusef Date: Sun, 25 Jul 2021 13:54:52 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-opsawg-l3sm-l3nm-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2021 20:54:53 -0000 Reviewer: Rifaat Shekh-Yusef Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines an L3VPN Network YANG Model (L3NM) that can be used for the provisioning of Layer 3 Virtual Private Network (VPN) services within a service provider network. The model provides a network-centric view of L3VPN services. Issues: 1. The following is a quote from Security Consideration section: "Several data nodes defined in the L3NM rely upon [RFC8177] for authentication purposes." I think it would be helpful to elaborate on which nodes need the mechanism defined in RFC8177 and why? 2. The summary bullets: o Malicious clients attempting to delete or modify VPN services. Why 'create' and 'read' are not part of the risks in this case? From nobody Sun Jul 25 19:44:01 2021 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 B91FA3A15B1; Sun, 25 Jul 2021 19:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=ywSxhtIt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=maFmtYoU 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 hffE88kwHzbA; Sun, 25 Jul 2021 19:43:51 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA1163A15AA; Sun, 25 Jul 2021 19:43:50 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B3DDA5C00AD; Sun, 25 Jul 2021 22:43:49 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Sun, 25 Jul 2021 22:43:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=N bIBjqzrmaoFGt1svjWzkmjcYrchHEExp3VTBOUNUDg=; b=ywSxhtItSik1TpzPb pvGZXUoIvlFl02J+zqWn4ipsiULkbPHx0wn2lGCF4LTv6Qk07BVIIY2WqkqPo2vg uKgF3pzo8KZnKb6QBStBHDhMqoRJYu/HtBeftK94E/Y6lsN9fKUUsLWuR0tSYb72 4U6WjVYUEQR7Cj7CgAW8KFE++jDHbtYCM+dQmH20m3vwzb8+1KpDO0rjw/NwnT8k Ngfi4S5SBnASyH+PxDvyYdsAmnP1OnwlTQs7kDoDsYkoAV4ULzdRPis586Zw0X6g S+Gpg4v8YV5WPK1haBxbzUsLyHyHdXPYWoWi6vaK0q2+gAi3YAx54IgHIr3ucz6n xpZPg== 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=NbIBjqzrmaoFGt1svjWzkmjcYrchHEExp3VTBOUNU Dg=; b=maFmtYoUmdOWvW1u8Fw8U/UYXHqQpl7lVc5KNZHtKa22HAN+rQThckFko RghJXNQxNqMNuz5mNog9F3ln6N3oi1inC5n9g7FVYFivt6ecV6gePI1SUcoMHt/w ItzPdFMzx8eelCuSZZpSM07rIFiFSH35qF8CS3GJ6nR0VLbGOWwKteOHtzdnEjNv 4mPvXQjpdahQjXoS6lvSCadi5Udns9VyKkABud/9KppZOWp67CgPyrWW1PmeTXd7 E6PjziLki5AyuOGXnM4GtPmeeIJbRQGpBGqoGgKO1cmfblDaMqsknrWjjbrBlJVE HBFDNKoplzAtdLkGdxDuqvD5RhvLA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrgeeggdehkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmh dthhdtvdenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhn ohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeelffdvueevffffkeeggfffueegheelke ekteejlefhleekveekudeiieevvdetgfenucffohhmrghinhepghhithhhuhgsrdgtohhm pdhmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 25 Jul 2021 22:43:46 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mark Nottingham In-Reply-To: <162723422613.4754.2816752947598222075@ietfa.amsl.com> Date: Mon, 26 Jul 2021 12:43:44 +1000 Cc: secdir@ietf.org, draft-ietf-httpbis-bcp56bis.all@ietf.org, ietf-http-wg@w3.org, last-call@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <86B9EF7F-8AC1-49A5-B33D-F9A8D5A96A45@mnot.net> References: <162723422613.4754.2816752947598222075@ietfa.amsl.com> To: Joseph Salowey X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-httpbis-bcp56bis-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 02:43:56 -0000 Thanks for the review. I've opened an issue to track it: https://github.com/httpwg/http-extensions/issues/1582 Responses below. > On 26 Jul 2021, at 3:30 am, Joseph Salowey via Datatracker = wrote: > Major Issues: >=20 > + I had trouble with section 4.12 Client Authentication which states: >=20 > "Applications can use HTTP authentication Section 11 of > [I-D.ietf-httpbis-semantics] to identify clients. The Basic = authentication > scheme [RFC7617] MUST NOT be used unless the underlying transport is > authenticated, integrity-protected and confidential (e.g., as provided = the > "HTTPS" URI scheme, or another using TLS). The Digest scheme [RFC7616] = MUST NOT > be used unless the underlying transport is similarly secure, or the = chosen hash > algorithm is not "MD5"." >=20 > I'm not sure what the "or chosen hash algorithm is not "MD5" is meant = to say.=20 > What I think the document should say is: >=20 > The Digest scheme [RFC7616] MUST NOT be used unless the underlying = transport is > similarly secure. The "MD5" digest algorithm MUST NOT be used. Hmm. I forgot that RFC7616 has a pre-existing requirement in Section = 5.1: > If Digest Authentication is being used, it SHOULD be over a secure = channel like HTTPS [RFC2818]. Are we saying that that SHOULD is really a MUST for all uses of HTTP, or = just those in scope for this document? Likewise for the effective = deprecation of md5. If so, perhaps the easiest thing to do would be to state that clearly; = e.g., """ [RFC7616] Section 5.1 recommends that the Digest scheme be used over a = secure channel like HTTPS. This document strengthens that recommendation = to MUST, and deprecates the md5 hash algorithm in the Digest scheme. """ ... and listing 7616 as being updated by this document. Thoughts? > + There is a security consideration that I think the document should = cover.=20 > Many HTTP based protocols make heavy use of bearer tokens, such as = session > cookies, for authentication and authorization purposes. This means = that an > attacker that can eavesdrop on HTTP communications can often escalate = their > privilege to perform operations on resources. I think you could add = this to > the security considerations: >=20 > " Section 4.4.2 requires support for 'https' URLs, and discourages the = use of > 'http' URLs, to provide authentication, integrity and confidentiality, = as well > as mitigate pervasive monitoring attacks. Many HTTP based protocols = make heavy > use of bearer tokens, such as session cookies, for authentication and > authorization purposes. This means that an attacker that can = eavesdrop on HTTP > communications can often escalate their privilege to perform = operations on > resources. " See = https://github.com/httpwg/http-extensions/commit/fe3f298e4d60514306e391398= cc870abaedd8bf9 > Minor Issues: >=20 > + Section 4.5.1 - This could be a good place to mention RFC-8470 on = TLS 1.3 > early data which can also be a source of GET request replay See = https://github.com/httpwg/http-extensions/commit/b03c376179e278deb3d994eac= 152c6a131702840 Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Mon Jul 26 04:20:36 2021 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 B1C793A0C0E; Mon, 26 Jul 2021 04:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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=btconnect.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 z0P92dq5Ljso; Mon, 26 Jul 2021 04:20:22 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80127.outbound.protection.outlook.com [40.107.8.127]) (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 0FA643A0C05; Mon, 26 Jul 2021 04:20:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OJD4Sxzi5Qy28JklwdFviprUgywkEZh9CODb0YKQFaFZ6pwyDTtdM3GMgUnHDpZ9LxRN3WvK7t0goYe9B0JadQeEdtAEW4dIqu//+a3LLeoIRjVnZVqWK9BCcbXZ4qCFrX4yDmPrDxmZ5ilf5EInTbwcLCC41DAbA29fqq62bVv7ZVdv7LtGVB7xql08JuVKJitPw0zXYAyl09XNS3+CeL8Du7jxAFnKTw7r+Q/WjwYqfTvdukSTnDAsFsNLpKaMIUtcypnnmxJxnhyKD01sdu45PibvKgF1S9o4Prhl9hL66Np//ZKGOPQFkX8KVhZQw6VOkK88HYLFq0QhQYjaIw== 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=g+RHH4ZpYbQED7jjSNRTnoC5rAWqv+/+gmfi8FZzb7U=; b=Kwvt12quO7lDj7hbvUC66JEGcRsAaOFjMNt1eoY4iy+qe73BnR3FiOsfZA4mjgRzCaBLbNuxd5HYREIm/oItpOzXfJG7QT58ghDjvuPiO474QOVRyrJna1SSWLhSOIp/oxgtQ+NUrp+X5WwTsTnKy5y6fviHhzdrzx0V/CCIMVpkQseJVtEjpAyjTt2KMVVTzluDpdW8sG18w17YWCwrHF4CvD+JQvJFNXw0/S2wQB+URUywan5FjgQ3Yssp6PHUbUNo29f+53UJzvMgRxkX+XE6XioilEKUnlj5zsj6E4zfevCYGCo+6NvXUQfb9pmjUWIf1y7Ru5z0Z9SjaYtoMQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=g+RHH4ZpYbQED7jjSNRTnoC5rAWqv+/+gmfi8FZzb7U=; b=DMH0nt8OTaeDt0JwAQURWFWj8mXORu3SnBkFSeLlFsufwASYURISJZ2IUsxVDLsKpLjT1xvcrafjoRVjJgaihBjl5qjou3S5qI+AtoLH5dV5R9r8+gv5saG46OqQQpIBIMWMe6wQl4cnPl/zEZQBeG5iAl4FO6lH91yE9Ic7/U4= Received: from VI1PR07MB6256.eurprd07.prod.outlook.com (2603:10a6:800:133::7) by VI1PR07MB6224.eurprd07.prod.outlook.com (2603:10a6:800:139::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.9; Mon, 26 Jul 2021 11:20:16 +0000 Received: from VI1PR07MB6256.eurprd07.prod.outlook.com ([fe80::f964:3eed:2d44:a3c0]) by VI1PR07MB6256.eurprd07.prod.outlook.com ([fe80::f964:3eed:2d44:a3c0%9]) with mapi id 15.20.4373.015; Mon, 26 Jul 2021 11:20:16 +0000 From: tom petch To: "secdir@ietf.org" , Watson Ladd CC: "last-call@ietf.org" , "draft-ietf-netconf-tls-client-server.all@ietf.org" , "netconf@ietf.org" Thread-Topic: [netconf] Secdir last call partial review of draft-ietf-netconf-tls-client-server-25 Thread-Index: AQHXfr4h0+l6xYEIU0q94nrO/Yk2EKtVGccK Date: Mon, 26 Jul 2021 11:20:16 +0000 Message-ID: References: <162693328770.27111.6978873343722392140@ietfa.amsl.com> In-Reply-To: <162693328770.27111.6978873343722392140@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 81ad94c0-358a-428d-fbc8-08d95027583a x-ms-traffictypediagnostic: VI1PR07MB6224: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3276; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PgrTfPtVq4Gft8cYg5LsEvtUtXLJ1NEqjp1j/aroJdgj2/shXRXo4PdfbpenAZnJorx/BWP14PZ2ig82zXXlYXeRSAaSiniwuOJ7J6YAKY/mWvDFmFnMh1EkGJeIVBVYWDQJdacu881kDSIhoca2zHqcb737aWjlwMWlBz+EvUiPA3POf2ltwhaQ1y5qd/J2Ysq8kdECQuM+Tff/a5qLu2lZZS9fI6YugnB6GtIzEQAVmqUX5LuFHYN/mEuvinHQjj52RLMBo/J/BS5j9aJXafOm2dkmXK5zNuCPveyxL4Jnd2clo2MnXS2BZuS8APeenEsXDFX3Xn8iKOfYraS2SmJTyXWaHOdUHJTrpf9kGeN0YeoQtuDWUTL19uyfBe8/DRCDuBDrSA9UEq3eRkDJPKEUlyOHs3ccY/8wABZomeGvnblsi9XLCqYcxfHfX9GexdlHWjsDicVueUo+2uXx95fiFE8qLCq57BB7uAXJ7JvMOrmnpXyLoc7fTWfUZOq0GfUVnBo3LrDCTRaV3VS0Z21NGnzvnKDMtfaQDsKJJKlmAuKdAmwEUe4+aRVrNy7GF784YBHKpabTOTXlgt0CimX4I0G3PwxWsVmq22E1yqZ0tvUw+EOmA5p53LQOSgp6oNwz/YWyhdS5m/VoOwk4gaLlxmlCooloT9GaUTJ/H89QVcgijzgf9VHUxXP7eO28cokZ0OEZz+ba5bdJ7BuQB2yDtjVZe3gAadq5JYsdOEw8e0/ODTyHyFhEBvlkuyPJgq7yndj8Qp/p3NE4QmSazg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB6256.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39860400002)(396003)(366004)(346002)(376002)(54906003)(38100700002)(316002)(52536014)(66556008)(66446008)(26005)(86362001)(71200400001)(110136005)(5660300002)(83380400001)(66476007)(33656002)(7696005)(8936002)(4326008)(64756008)(186003)(66946007)(2906002)(122000001)(6506007)(966005)(55016002)(478600001)(8676002)(91956017)(76116006)(9686003)(38070700004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?23zRwY4RQ/9wvBUyWRcvRliw7H3C9LL+3E/QLIxEyTO5kan1kWW6GndHu1?= =?iso-8859-1?Q?ISlw85V8dF5EpCnCM6QwXCcEXY8DvH6XWRDHprfNUAsg5pJBeoHIQPIfA5?= =?iso-8859-1?Q?E2W5Pw1Y0PMPgHq6HXgXMnR/4K37RH363uLLh93RP7l4GwIurx9IsJ1sLF?= =?iso-8859-1?Q?zv7VKETRskdt8DGyPZVcxXdBYjmqjYcSWbadmEBMyfAm2tD+eNeRC/3rhW?= =?iso-8859-1?Q?OdubbTAWRJHNwyDdHc6e/3abksAa4mzLKcSzv9ZS1VRuPj7PdqRz2Uen/t?= =?iso-8859-1?Q?ut6lDiTSj20biIucz+H6CbQ4xk8PVA0IWa9eRRDoFc7ooRQMtzc7e5FTsc?= =?iso-8859-1?Q?GO0LDseeQJjYO9J5bvK9dEP3ziVldmKa2HJ+j/gniJ2oWwZ/5Jl4iC5C1Q?= =?iso-8859-1?Q?tLsLEnE43o5R0uwWH+VKiq1KY04rkPO0b+YD3VvbDgcESwYMRUc4SZ4h8C?= =?iso-8859-1?Q?dec+LQF5uwfZlA24eUOqhfwfXAJT3o5sWfSmkxZfrrCF39pV9fhY4OlQVy?= =?iso-8859-1?Q?W42K+4Qzz4Mca4DrZKHquhZ9j03y96dousSJfaZD+pFjZIKyZrZXh9FHx/?= =?iso-8859-1?Q?pkFQMLRbi1HwU50uzCAhTb2qxk97tMOhx24PiddqU/IAcSnM5EbJEE2eC+?= =?iso-8859-1?Q?7YBj41E1DaA9rfiQpf/Tsr8FZmix+emX547mQsIP6X1JpdBbAkVH+vKGMu?= =?iso-8859-1?Q?P6lYhEQ0PiELwNNysTqkcnHErD7xIaGaxA7HL++PCJE6+dUZMoDj2erIth?= =?iso-8859-1?Q?H9M0HZzH4Deei/am8CxA1gZNdW3Ha6HCyJXflTKhtLbeKt2zm5kqjWdYmQ?= =?iso-8859-1?Q?NIhxZXEerayaRzxMK2QK9Ilk04GMChjoc2zPRw6AeQKU7OSGbEOIYLuzoY?= =?iso-8859-1?Q?F+a83aobJncEXPnbEnVPOyW3lnYPYM+njD72OBs/D2wpPSz+fOF3+gTX25?= =?iso-8859-1?Q?UHJXu9wtMYTqn4HqBzo27qQb3F6uXJj77Lvv1OUmm67KRB+d1PCjCGE7vu?= =?iso-8859-1?Q?zO8GZi9aYAXFI4ykbWZh2kTTdrjzK4ftHVNXfpKWmEaSSuXbTxqJVXacc8?= =?iso-8859-1?Q?3gYIqUiJTGaue8aQGRE6nNQj4+Kg1SpWXLollUerI2XtDslSMfArNyBm32?= =?iso-8859-1?Q?X/gXqXq2zh/nbAUNFU7uKKb5CF2FZEXJ12/DacnwnqWQ3mul/+zaL64exX?= =?iso-8859-1?Q?BgqrIhJ+5V0Qg6/KhavVjShjRsiBRdlLI4gxKEaNOhG0zdRA0787LJvueh?= =?iso-8859-1?Q?a+r1DEEDb0lhjQ0lP4r+Ue7aLmVwHKfgIDOoRc2OrnaqYpqZDGscCpzLGA?= =?iso-8859-1?Q?70WfOTN3uD718ceLsNUseSbGiBpCT4SRTpW8VKWS+yUIqNo=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6256.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 81ad94c0-358a-428d-fbc8-08d95027583a X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2021 11:20:16.2140 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: zbSDdjQXFVjgwIIs8lFcvc9mI8Mw7+UKRCe3nYQf4/FF3BgcPSWOZEH1KWw9aUuWhwGoioSN5SwU5lZ78cv0uQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6224 Archived-At: Subject: Re: [secdir] [netconf] Secdir last call partial review of draft-ietf-netconf-tls-client-server-25 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, 26 Jul 2021 11:20:27 -0000 From: netconf on behalf of Watson Ladd via Datat= racker =0A= Sent: 22 July 2021 06:54=0A= =0A= Review is partially done. Another assignment may be needed to complete it.= =0A= =0A= Reviewer: Watson Ladd=0A= Review result: Ready=0A= =0A= Dear readers,=0A= Forgive my completing this review almost a month late.=0A= =0A= I have reviewed this document as part of the security directorate's=0A= ongoing effort to review all IETF documents being processed by the=0A= IESG. These comments were written primarily for the benefit of the=0A= security area directors. Document editors and WG chairs should treat=0A= these comments just like any other last call comments.=0A= =0A= The summary of the review is ready, because I can't find anything wrong wit= h=0A= it. Your comfort with this fact should be minimal.=0A= =0A= Benjamin Kaduk writes me to inform you that the issues with the PSK in TLS = 1.3=0A= are being worked on.=0A= =0A= And now on to my evaluation of the document. The problem is that I can't=0A= evaluate this in any substantive way: it is a whole bunch of YANG, a techno= logy=0A= I am completely ignorant of. The few English sentences I saw looked fine, a= nd I=0A= didn't spot anything wrong, but I likely wouldn't have.=0A= =0A= =0A= =0A= Watson,=0A= =0A= I am the one who has been stirring this, FUD mostly.=0A= =0A= One issue is the support for TLS1.0, TLS1.1 which originally was more compr= ehensive than that for TLS1.3 and in some respects still is, as in the exam= ples. These versions are now deprecated in YANG; I would have omitted the= m entirely, but the WG consensus was otherwise. I take it you are ok with = this. Of the TLS RFC, only RRC8446 is a Normative Reference.=0A= =0A= PSK and raw public keys were a late addition to the I-D. I had forgotten t= hat the latter were a type of certificate and so likely has no issues with = TLS1.3 but with PSK I see little resemblance to earlier versions of TLS. M= y sense is that the TLS WG really wants to have nothing to do with PSK (unl= ess following a full handshake) even if there are two TLS I-D spelling out = the consequences of using PSK alone . Together with changes in terminology= and protocol for PSK, I think it challenging to produce a model for PSK fo= r both TLS1.2 and TLS1.3. The I-D does tackle the TLS1,3 changes from ciph= ersuite but says nothing about the features it specifies for 3DES, GCM, EC= C and their interaction with TLS1.3 (should it?)=0A= =0A= I am aware of the issues EMU have had with TLS1.3 and see some application = I-D providing a profile for the use of TLS1.3 but overall doubt the feasib= ility of producing an I-D which covers both TLS1.2 and TLS1.3 without going= into the sort of detail that uta-tls13-iot-profile does.=0A= =0A= My comfort is minimal!=0A= =0A= Tom Petch=0A= =0A= Sincerely,=0A= Watson Ladd=0A= =0A= =0A= _______________________________________________=0A= netconf mailing list=0A= netconf@ietf.org=0A= https://www.ietf.org/mailman/listinfo/netconf=0A= From nobody Mon Jul 26 10:53:22 2021 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 E99CC3A1EC4; Mon, 26 Jul 2021 10:53:17 -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, NICE_REPLY_A=-0.001, 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 pC8wTPkZL_iK; Mon, 26 Jul 2021 10:53:13 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 014A33A1EC1; Mon, 26 Jul 2021 10:53:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 35FB6624FD; Fri, 1 Jan 2010 01:42:08 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7nR64VkdgQYw; Fri, 1 Jan 2010 01:42:00 -0500 (EST) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 747B3624EE; Fri, 1 Jan 2010 01:42:00 -0500 (EST) To: =?UTF-8?Q?Magnus_Nystr=c3=b6m?= , secdir@ietf.org, draft-ietf-drip-rid@ietf.org References: From: Robert Moskowitz Message-ID: <74ffc92c-6847-aaa2-120f-8ca9bce845ac@labs.htt-consult.com> Date: Mon, 26 Jul 2021 13:52:53 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1AF50D628AA3130E42E4DDE6" Content-Language: en-US Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-drip-rid-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 17:53:18 -0000 This is a multi-part message in MIME format. --------------1AF50D628AA3130E42E4DDE6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Magnus, Thank you for your comments.  I have been with minimal connectivity due to storm induced power outage. I did push out ver 08.  I quick read through your comments show I fixed other stuff. I will go over your comments and get with CFRG (and about some light crypto stuff) in the coming weeks. Bob On 7/24/21 1:14 AM, Magnus Nyström wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors.  Document editors and WG chairs should treat > these comments just like any other comments. > > This document describes the use of "Hierarchical Host Identity Tags" > as self-asserting IPv6 addresses and thereby trustable identifiers for > use as Remote IDs. > > As the security of HHITs to a large degree relies on the security of > the cryptographic constructs and primitives described in this > document, I would recommend that the IRTF CFRG or a similar group with > cryptographic expertise reviews this memo (unless it has already been > done). > > The security of the HHITs also seem to depend to a large degree on the > registrars (registry operators) that will act as backstops to ensure > no duplicate registrations etc. It might be helpful with a clear > statement as to the conditions that must be met by registrars in order > for this scheme to be secure. > > As noted, the use of a 64-bit hash is weak when considering pre-image > attacks. I do not understand the constraints the authors have been > working under in this context enough to say if there was an option for > a longer hash, but I think this should be part of the above suggested > CFRG review. > > The text "Another mitigation of HHIT hijacking is if the HI owner (UA) > supplies an object containing the HHIT and signed by the HI private > key of the HDA such as Appendix E.1 > > as shown in Section 3.5" > > confuses me a bit since I don't see how the subject of an attack would > be able to tell should the HHIT hijack attempt occur before the HI > owner has supplied such an object? > > Lastly, the statement "The authors believe that the probability of > such an attack is low when Registry operators are using best > practices" seems weak and would preferably be backed with some more > quantitative analysis or at least specific statements around best > practices and how they would reduce the probability. > > Editorial: The document is in need of a grammar / wording polish but I > expect the rfc-editors to handle this. > > Thanks, > -- Magnus > > --------------1AF50D628AA3130E42E4DDE6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Magnus,

Thank you for your comments.  I have been with minimal connectivity due to storm induced power outage.

I did push out ver 08.  I quick read through your comments show I fixed other stuff.

I will go over your comments and get with CFRG (and about some light crypto stuff) in the coming weeks.

Bob

On 7/24/21 1:14 AM, Magnus Nyström wrote:
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other comments.

This document describes the use of "Hierarchical Host Identity Tags" as self-asserting IPv6 addresses and thereby trustable identifiers for use as Remote IDs.

As the security of HHITs to a large degree relies on the security of the cryptographic constructs and primitives described in this document, I would recommend that the IRTF CFRG or a similar group with cryptographic expertise reviews this memo (unless it has already been done).

The security of the HHITs also seem to depend to a large degree on the registrars (registry operators) that will act as backstops to ensure no duplicate registrations etc. It might be helpful with a clear statement as to the conditions that must be met by registrars in order for this scheme to be secure.

As noted, the use of a 64-bit hash is weak when considering pre-image attacks. I do not understand the constraints the authors have been working under in this context enough to say if there was an option for a longer hash, but I think this should be part of the above suggested CFRG review.

The text "Another mitigation of HHIT hijacking is if the HI owner (UA) supplies an object containing the HHIT and signed by the HI private key of the HDA such as Appendix E.1 as shown in Section 3.5"  confuses me a bit since I don't see how the subject of an attack would be able to tell should the HHIT hijack attempt occur before the HI owner has supplied such an object?

Lastly, the statement "The authors believe that the probability of such an attack is low when Registry operators are using best practices" seems weak and would preferably be backed with some more quantitative analysis or at least specific statements around best practices and how they would reduce the probability.

Editorial: The document is in need of a grammar / wording polish but I expect the rfc-editors to handle this.

Thanks,
-- Magnus





--------------1AF50D628AA3130E42E4DDE6-- From nobody Tue Jul 27 03:00:38 2021 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 3C24B3A1DB9; Tue, 27 Jul 2021 03:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 kq8n4vEitZiU; Tue, 27 Jul 2021 03:00:26 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7DE93A1DB7; Tue, 27 Jul 2021 03:00:25 -0700 (PDT) Received: from fraeml703-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GYsS05JGjz6L9kJ; Tue, 27 Jul 2021 17:48:32 +0800 (CST) Received: from dggpeml100010.china.huawei.com (7.185.36.14) by fraeml703-chm.china.huawei.com (10.206.15.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Tue, 27 Jul 2021 12:00:21 +0200 Received: from dggpeml500011.china.huawei.com (7.185.36.84) by dggpeml100010.china.huawei.com (7.185.36.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Tue, 27 Jul 2021 18:00:14 +0800 Received: from dggpeml500011.china.huawei.com ([7.185.36.84]) by dggpeml500011.china.huawei.com ([7.185.36.84]) with mapi id 15.01.2176.012; Tue, 27 Jul 2021 18:00:14 +0800 From: "Liubing (Remy)" To: Robert Sparks , "secdir@ietf.org" CC: "6lo@ietf.org" <6lo@ietf.org>, "draft-ietf-6lo-plc.all@ietf.org" , "last-call@ietf.org" Thread-Topic: Secdir telechat review of draft-ietf-6lo-plc-06 Thread-Index: AdeCzeG20waqsFskM0iYuCIAoGKJ1w== Date: Tue, 27 Jul 2021 10:00:14 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.110.9.243] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-6lo-plc-06 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, 27 Jul 2021 10:00:31 -0000 SGVsbG8gUm9iZXJ0LA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMuIFBsZWFzZSBmaW5k IG15IHJlc3BvbnNlIGlubGluZS4NCg0KSSB3aWxsIGZpeCB0aGUgdHlwb3MgeW91IG1lbnRpb25l ZCBpbiBhbm90aGVyIG1haWwuDQoNCkJlc3QgcmVnYXJkcywNClJlbXkNCg0KLS0tLS3pgq7ku7bl jp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBSb2JlcnQgU3BhcmtzIHZpYSBEYXRhdHJhY2tlciBbbWFp bHRvOm5vcmVwbHlAaWV0Zi5vcmddIA0K5Y+R6YCB5pe26Ze0OiAyMDIx5bm0N+aciDI05pelIDI6 NDINCuaUtuS7tuS6ujogc2VjZGlyQGlldGYub3JnDQrmioTpgIE6IDZsb0BpZXRmLm9yZzsgZHJh ZnQtaWV0Zi02bG8tcGxjLmFsbEBpZXRmLm9yZzsgbGFzdC1jYWxsQGlldGYub3JnDQrkuLvpopg6 IFNlY2RpciB0ZWxlY2hhdCByZXZpZXcgb2YgZHJhZnQtaWV0Zi02bG8tcGxjLTA2DQoNClJldmll d2VyOiBSb2JlcnQgU3BhcmtzDQpSZXZpZXcgcmVzdWx0OiBIYXMgTml0cw0KDQpJIGhhdmUgcmV2 aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdz IG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vz c2VkIGJ5IHRoZSBJRVNHLiBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZv ciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuIERvY3VtZW50IGVk aXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtl IGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoNClRoaXMgZG9jdW1lbnQgaXMgYmFzaWNh bGx5IHJlYWR5LCBidXQgaGFzIG5pdHMgdGhhdCBzaG91bGQgYmUgYWRkcmVzc2VkIGJlZm9yZSBw dWJsaWNhdGlvbiBhcyBQcm9wb3NlZCBTdGFuZGFyZCBSRkMuDQoNCkNvbnRleHQgZm9yIHRoZSBB RHMsIGZyb20gbXkgTEMgcmV2aWV3Og0KDQo+IFRoaXMgZG9jdW1lbnQncyBwcmltYXJ5IHBvaW50 IGlzIHRvIHN0YW5kYXJkaXplIG1hcHBpbmdzIG9mIGlwdjYgDQo+IGlkZW50aWZpZXJzDQpmb3Ig dXNpbmcgaXB2NiBvdmVyIElFRUUgMTkwMS4xLCAxOTAxLjIsIGFuZCBJVC1UIEcuOTkwMyBuZXR3 b3Jrcy4gPiBUaG9zZSBzdGFuZGFyZHMgYXJlIG5vdCBwdWJsaWN5IGF2YWlsYWJsZSwgYW5kIEkg aGF2ZSBub3QgcmV2aWV3ZWQgaG93IHRoZXNlIG1hcHBpbmdzIGFuZCB0aGUgc2VjdXJpdHkgbWVj aGFuaXNtcyBpbiB0aG9zZSBwcm90b2NvbHMgaW50ZXJhY3QuDQoNCk15IExDIHJldmlldyBzdWdn ZXN0ZWQgcmVtb3Zpbmcgc2VjdGlvbiA1IC0gUmVteSdzIHJlc3BvbnNlIHdhcyB0aGF0IGhlIHdv dWxkIGNoZWNrIHdpdGggdGhlIFdHLiBJIGRvbid0IGZpbmQgYW55IGRpc2N1c3Npb24gb2YgdGhh dCBvbiB0aGUgV0cgbGlzdD8gSSBzdGlsbCB0aGluayBpdCBjb3VsZCBiZSByZW1vdmVkIG9yIG1v dmVkIHRvIGEgc2VwYXJhdGUgZG9jdW1lbnQuDQpbUmVteV0gSSd2ZSBjaGVja2VkIHdpdGggdGhl IFdHIGluIElFVEYxMTAuIFRoZSBXRyBzdWdnZXN0cyB0byBrZWVwIHRoZSBzZWN0aW9uLiBQbGVh c2UgdmVyaWZ5IGl0IGluIHRoZSBtaW51dGVzLg0KDQpNeSBvdGhlciBjb21tZW50cyBoYXZlIGJl ZW4gYWRkcmVzc2VkLg0KDQpUaGlzIHZlcnNpb24gaW50cm9kdWNlcyBhIGZldyBlZGl0b3JpYWwg bml0cyB0aGF0IEkgd2lsbCBzZW5kIGRpcmVjdGx5IHRvIHRoZSBlZGl0b3JzLg0KDQoNCg== From nobody Wed Jul 28 23:07:21 2021 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 86F483A1103; Wed, 28 Jul 2021 23:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 s4i8I2C32PJ1; Wed, 28 Jul 2021 23:07:13 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 9610E3A1100; Wed, 28 Jul 2021 23:07:12 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id j21so5576857ioo.6; Wed, 28 Jul 2021 23:07:11 -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=Nb1LXYS/eA8iwOtxgcYrzYiYs320T8sL58JkdhjO2G8=; b=tX2f5kGaTaH7YiOMmuN2TpNkfztUE2lz1EeDg1/ktqEeF9ER/9hPA4Gk9PjfHGlNap olhTyj7JH927HSjzU7nUfxL4+Kgm0+BTrQyUlptNUMoDe6CxuersKJqoR4ttk8+Aavip NCBkPSnRELWfg4ieu2UvkWQBngj0e0n4l0ILUfhayG6wiM0XhX2ZMBSQogvGVttmP6UE mwT32UX/fGKNAtueKiar8yzWa7m47wTS2x1NguiS+zwaX6r3K6lPhdUymTMl+o/c8mtp Ft1/wg0h3irZp4RmVRfWuMcdVqAsdWHU4uHOkKj0EyImaEh8yntKMa41uP6toYrkQ7Tf O1ZQ== 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=Nb1LXYS/eA8iwOtxgcYrzYiYs320T8sL58JkdhjO2G8=; b=R2WnhOifgedhxQyEwsNyYnFojVD4H+GgN8/fWOn3PE2YxDHC4KZzNx5F6W3J9L5kj3 GS1lnp4FAd21VOhu+fpQzeHqMQO95ECOQ0WSXqjNT+FXm4hLDRv5AxeCDX+E0nMMvBJu vSkgrNPTZPAiA1Z6daMcrlBGNnzlpcU9Nml3bo0RR3Zc9ui3SArYfAyAzWML1FqNoBVZ ZlZVBv/LUcpDEDioDcoo73V9C8MRzXAQXyFsv8F+75AcMCMVRURYsR9AABmZdaBX/1H7 NL3PW38TJMZY95xUJZFguGsC7rGSV1yavFOXugh5iqiCKXIBPkI/QiDoocK4hr5iCjlJ npFw== X-Gm-Message-State: AOAM532Fs8MMaEi6EjoutjZ5o4mB39yroiX2PfyeRsHAve/dC7A3sS4P lfq+a262Af97Z8LvakliGOFLz5JAWujxZnH3QTF0X+9Jax4= X-Google-Smtp-Source: ABdhPJyy1nk+GYzbK8be8Ki7TfIxic2tCfW/6i6FW4/cUzxh6T8kFhaIBCUfo79P8zl8t1q0BFnCIV9uVv8NVBVD7ug= X-Received: by 2002:a6b:db18:: with SMTP id t24mr2750567ioc.163.1627538830236; Wed, 28 Jul 2021 23:07:10 -0700 (PDT) MIME-Version: 1.0 From: Radia Perlman Date: Wed, 28 Jul 2021 23:06:59 -0700 Message-ID: To: secdir@ietf.org, The IESG , draft-housley-ers-asn1-modules.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000d59f5005c83ce915" Archived-At: Subject: [secdir] Secdir review of draft-housley-ers-asn1-modules-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2021 06:07:15 -0000 --000000000000d59f5005c83ce915 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready This document is intended to be Informational. This document gives alternative ASN.1 specifications for RFC5276 (Evidence Record Syntax). These alternative specifications are intended to produce the same bits-on-the wire as the originals but follow newer ASN.1 specifications (2002 vs. 1988); follow the conventions established in RFC5911, RFC5912, and RFC6268; and are freestanding rather than referencing specifications from non-RFCs. I=E2=80=99m not qualified to judge whether the translation was done correct= ly, but the authors are. Radia --000000000000d59f5005c83ce915 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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

=C2=A0

The summary of the review is Ready

=C2=A0

This document is intended to be Informational.<= /p>

=C2=A0

This document gives alternative ASN.1 specifica= tions for RFC5276 (Evidence Record Syntax). These alternative specifications are inte= nded to produce the same bits-on-the wire as the originals but follow newer ASN.= 1 specifications (2002 vs. 1988); follow the conventions established in RFC59= 11, RFC5912, and RFC6268; and are freestanding rather than referencing specifications from non-RFCs.

=C2=A0

I=E2=80=99m not qualified to judge whether the = translation was done correctly, but the authors are.

=C2=A0

Radia

=
--000000000000d59f5005c83ce915-- From nobody Thu Jul 29 03:47:51 2021 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 2D1373A1D96 for ; Thu, 29 Jul 2021 03:47:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <162755566916.7713.15970662179534629840@ietfa.amsl.com> Date: Thu, 29 Jul 2021 03:47:49 -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, 29 Jul 2021 10:47:49 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2021-08-12 Reviewer LC end Draft Catherine Meadows 2021-07-07 draft-ietf-httpbis-cache-header Christopher Wood R2021-06-15 draft-ietf-6man-ipv6-alt-mark Last calls: Reviewer LC end Draft Nancy Cam-Winget R2021-06-28 draft-ietf-opsec-ipv6-eh-filtering Nancy Cam-Winget 2021-06-08 draft-ietf-oauth-par Steve Hanna 2021-03-22 draft-ietf-regext-secure-authinfo-transfer Catherine Meadows 2021-04-14 draft-ietf-ntp-interleaved-modes Catherine Meadows 2021-07-07 draft-ietf-httpbis-cache-header Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Derrell Piper 2021-08-09 draft-ietf-mmusic-rfc8843bis Tim Polk 2021-08-06 draft-ietf-opsawg-vpn-common Kyle Rose 2021-08-02 draft-ietf-tcpm-rfc793bis Stefan Santesson 2021-08-11 draft-ietf-bier-te-arch Yaron Sheffer None draft-ietf-lsr-pce-discovery-security-support Melinda Shore 2021-08-11 draft-ietf-regext-epp-registry-maintenance Valery Smyslov None draft-ietf-netconf-crypto-types Robert Sparks 2021-08-09 draft-ietf-sacm-coswid Mališa Vučinić 2021-06-10 draft-ietf-httpbis-semantics Klaas Wierenga 2020-12-02 draft-ietf-core-echo-request-tag Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Christopher Wood R2021-06-15 draft-ietf-6man-ipv6-alt-mark Paul Wouters 2021-06-10 draft-ietf-httpbis-messaging Liang Xia 2021-03-17 draft-ietf-core-sid Early review requests: Reviewer Due Draft Stephen Farrell 2021-06-21 draft-ietf-idr-bgpls-srv6-ext Daniel Migault 2021-07-31 draft-ietf-httpbis-message-signatures Next in the reviewer rotation: Tina Tsou Sean Turner Loganaden Velvindron Mališa Vučinić Carl Wallace Samuel Weiler Brian Weis Klaas Wierenga Christopher Wood Paul Wouters From nobody Thu Jul 29 09:10:37 2021 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 06A873A09C3; Thu, 29 Jul 2021 09:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-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=btconnect.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 r8Vl_oz5bFJN; Thu, 29 Jul 2021 09:10:25 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2098.outbound.protection.outlook.com [40.107.21.98]) (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 CCCF53A0A6C; Thu, 29 Jul 2021 09:10:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aLcJrgPF3p0zA7ctwOSoG49TWm0cuD0QouikYhdL3Ne89Ztt6W864mS59H2Jh1ixqLUOng34E38neRxjit6XEJDXUGyp9uzHWPB1bNDgnFIC8G3o7fTqKS7J5J6SF6M0h3gYyLXgl/5R3pimUvfHp7Iq0gZAMzvMS+3xE+tnzOEK69mTgMhSeKUV1qC+h2muEJhnV6Ua3nCMVmE1LgCINJjJHfCSiSSgie3rDyMwxuhItrG/jLnMlVstIaSOb3OzcPQDwAX8RNKSOq++AnHne9FeOesT6kEOmcoNVIg0t8hkxpZhsNjWaKeWtyl/wJS8IblnT0hwHkJgVaWv/gHXog== 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=EnGpGZHBKk7asvHjzc2Xnr6kz6/8G7kXGKNwqze6fWA=; b=mIWJi7ncn9W7mUObB7XODqZ9QDVjUENyWQ5qRgVN3S2YXLck3t7mYf8truZvIpRWJb8x6wWeIis7icWX/rfEwX4a7Oo9IU4VUIOeqyLh8iOs5RDJFK+kINFM9zvx6ayCGQIVcoEcyoYaZ+5vBW3vr+JhjzZ78hE9Tqw3h76YLuOS25E/djwf/u9EhiZd7VLqpu7jVi6+V/zt87hcllN7RWKAJmW4aS78QnwoQyOpgir0j0fovC0MqUoj1jVU83EpUiYIKXfEGdlk1SWue4PxxVY5i8kOSJvDD64Nu6wbD/yRyOrnwpB+RJrnuITeJSSBFayAyL9tNht2MQ6kgV90ag== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EnGpGZHBKk7asvHjzc2Xnr6kz6/8G7kXGKNwqze6fWA=; b=cjcamqafK/6qP5/blWLwgIfibm72alVhS7Du1IecpMzRMeQZ1h4poCBMRKWHf9G84B9nFcZPJo+Uz5v69qxmKqPvLKF1mDzyZCabeNfixu8R4c7gtV0tJV6jur1NbjD+PzFVXtdrOyuYa6e12vPMNOANz+RKzWbx2Y042Wqa4HI= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com; Received: from VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) by VI1PR0701MB2397.eurprd07.prod.outlook.com (2603:10a6:800:69::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.9; Thu, 29 Jul 2021 16:10:18 +0000 Received: from VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::10f5:d159:cfea:1b95]) by VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::10f5:d159:cfea:1b95%3]) with mapi id 15.20.4373.019; Thu, 29 Jul 2021 16:10:17 +0000 To: Rifaat Shekh-Yusef , secdir@ietf.org References: <162724649271.1477.16367299362861096101@ietfa.amsl.com> Cc: last-call@ietf.org, draft-ietf-opsawg-l3sm-l3nm.all@ietf.org From: tom petch Message-ID: <6102D2D8.6010106@btconnect.com> Date: Thu, 29 Jul 2021 17:10:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: <162724649271.1477.16367299362861096101@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0453.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1aa::8) To VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.65] (86.146.121.231) by LO4P123CA0453.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1aa::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.4373.17 via Frontend Transport; Thu, 29 Jul 2021 16:10:17 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4e3f5d55-46c1-4d0b-2bd5-08d952ab5b79 X-MS-TrafficTypeDiagnostic: VI1PR0701MB2397: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: SdejW/xVduRENkvKUlIUboMRS0MDwXG+Yx1jAp28jKeMog6yHz0oTLCAtC8J/XwXbFxFV9JyL9Hd5pRp5hg+2ehxWsdZ0p5/cTEY4oHGtex/XJpUSzXpKi+ckvpD7kTgqPqx7QZcpO2ShBG7sHS/gZgB1LfkEwrOosb/kXTwS/nxInFaO3x1pyAZSGyasH96bL7i7Zg+WJioLjScTKbrG2qmhrqCISbrzdJsbcWDeB8whBsE0ZNyj9PD5uVBsjWLMG4zIbz2mqRL9joH2JRZ6YQMaYtoFb3KhVf5Y/3vgu/GoA+ddN38IOF7x5glmMhBGZYu63xBKaMf2sXbtgXUrIGJYJJ8skFTLCm2V40aScl3MFaUCSUJQJ0XL85hfoevnp658hFb1XExb7OCocvDpvqjECVbed45FL1da6AjpVnXpQqisvu/2VS6BzVf7VwnDyvR9hfS+/1oBsH2ofQnjycsaeH298X6LbldFM32Ri5aTsifnhW4RxLVavktljSqMsFuqgulYKIjSgY9S4u2uk+8Pzv4UpITk+3xV4TxxLYC6R4R0ZW1ao5OO8Ej2P2kjcC6lsAinHEXqMtlq3aP64xcqKbBCvodXJGhL8EG0+osldcuANFOHT+Yh5tEE2G3kbCTUqwJfjGLUFeaahfU7njKFfwabPcy/oYpTMoTYuSLqi/WsZrSKuGSDj41wqvMV8ZblpeGSUC5SOCfH8Un/g== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB6704.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(366004)(136003)(39860400002)(396003)(186003)(5660300002)(53546011)(26005)(2616005)(2906002)(8936002)(956004)(8676002)(6486002)(4326008)(38350700002)(66556008)(66476007)(86362001)(83380400001)(478600001)(16576012)(87266011)(38100700002)(66946007)(36756003)(52116002)(6666004)(33656002)(316002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?Windows-1252?Q?8duB+miiE/+EcstLEyxmHL8sjvnPQb3wFMqfkvRPg/NsGAMHGyl3LDEI?= =?Windows-1252?Q?rFL5KHfcl/W8Ho0cVpvvJdYb/cruZ5xk+ydT+FiI5Aie8dh3DhJr6QJa?= =?Windows-1252?Q?uJwpynzjCYupoRnMwjFugqUmnOURa0UeeRBPtI5pkZZNL/O5oTWIB+UR?= =?Windows-1252?Q?11eKOO7usGAaHs7rXyrLDWl+85qEq6ov9JToHjeI7IJaUVPyX89nwnHq?= =?Windows-1252?Q?9oNFmlTCom7/n91K/cnG1lpi0lZMOUX68mTXXF9DrpOmcoF/JEbPZyWD?= =?Windows-1252?Q?IWrf6LNVS2dieb7VomeFNnPoawF3ip8M+ftI77/LJaSXb+0SIM6c3NIQ?= =?Windows-1252?Q?AKDV9ame6lDZEZriEHdaS+66vsKmdDuI0AqgX2BrcAhucS2qu32grazw?= =?Windows-1252?Q?ufp740GvSgMy/zVfPlJkeKBEzt82/xEmDQ4QyrgFpVp9sPrp7fm95xfE?= =?Windows-1252?Q?CQ+sAN6fyJdnWPaxzNe9CaaOhfV+hXDbb9ByIVeIF1yra5j9ysCcfzoU?= =?Windows-1252?Q?5DEJ8uD3WFCPlRU+YjlFiCrvoE29iFtkf6ePistdgv3YKYyF3pP5evNz?= =?Windows-1252?Q?lMU2dewIRPiMWEJoownvYS6NWSmAgt6Jwh4P7s4IHONahiaxRQ4rQA4o?= =?Windows-1252?Q?khxm2ioJ5kuJ7hg/AJztsT/elbPMlXUYjPFpBAUVqZHuaN75UfGPhDql?= =?Windows-1252?Q?/tY+1HH9uLQN4Fod+APw6imqoXNj5Xvuae4hvpHnOznz3j9Mt9VREuHw?= =?Windows-1252?Q?NnjxV/m3P1154kO9Gp6p5TbxGdNJVJvubRJGAYwaQPz8+qqyprPsmqKp?= =?Windows-1252?Q?lR9oeOlvQQqvp6spH9SnDJUk13UW4Vg46iMFyexwJcCJ74IDhtcmS4Ub?= =?Windows-1252?Q?HtN25i6dVINXSG565yYo08W9WvZeTUdM+CqZrs+T8soSiUB7Vzm7668Q?= =?Windows-1252?Q?UlYFAJdkp6eSGceexCvi6OEsGTKPNXHvrciXcFrMdb2Gq9zed37J3EB0?= =?Windows-1252?Q?P15QDEQ3SZtCteX70xdU+JgkeUTZF8qC7rkFZbp8GWtXHF1f/eWM07Jk?= =?Windows-1252?Q?3qvahd7OwLGxa6VYUCYypnffPgSk54asd/LQhm40o3vs7A1lE6fwclPY?= =?Windows-1252?Q?AgjwYLsW4HG0KHw9O7JRyFL3RsKpgQa3/Oc5LhfpKESD9IE0akmnuqaa?= =?Windows-1252?Q?TwtB34LOoxyhFlKUtVtsA5VPTve0NgJ3u9dm6vt9flrO7PkAQ+0rcgg7?= =?Windows-1252?Q?jxeNA0YxYgW6RJtWZ3JVwuMWo82/2nFhaxfrXVfhxma9n7t/kaR5Jrt1?= =?Windows-1252?Q?qZykKZb46kE4pCGZMVf2FYCdLY3ceKO2nRbkcPADjt+1paFaooTzS/XH?= =?Windows-1252?Q?SzldtCLf0GjNdL3a5yvY6JI/ru7yImbdkrMM2aWEbSQ01v/6vqLJtf9B?= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4e3f5d55-46c1-4d0b-2bd5-08d952ab5b79 X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6704.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jul 2021 16:10:17.8413 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: h93FfShdupFw8rtoPa8KQoxtFpl/qx3iWB6RF+yvtkQykIA4AgLsxfLwMxSM2sBoQVUQFOT/4vjJ6S6g5uR3jw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2397 Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-opsawg-l3sm-l3nm-10 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, 29 Jul 2021 16:10:32 -0000 On 25/07/2021 21:54, Rifaat Shekh-Yusef via Datatracker wrote: > Reviewer: Rifaat Shekh-Yusef > Review result: Has Issues > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document defines an L3VPN Network YANG Model (L3NM) that can be > used for the provisioning of Layer 3 Virtual Private Network (VPN) > services within a service provider network. The model provides a > network-centric view of L3VPN services. > > Issues: > > 1. The following is a quote from Security Consideration section: > "Several data nodes defined in the L3NM rely upon [RFC8177] for > authentication purposes." > > I think it would be helpful to elaborate on which nodes need the mechanism > defined in RFC8177 and why? > > 2. The summary bullets: > > o Malicious clients attempting to delete or modify VPN services. > > Why 'create' and 'read' are not part of the risks in this case? Rifat Reading this I-D, I wondered what the secdir view is of recommending the use of MD5 to secure the session as this I-D does for BGP. (Such a use in NTP did generate a comment). Tom Petch From nobody Fri Jul 30 13:36:00 2021 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 A92353A0F02; Fri, 30 Jul 2021 13:35:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kyle Rose via Datatracker To: Cc: draft-ietf-tcpm-rfc793bis.all@ietf.org, last-call@ietf.org, tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162767735763.27351.5673596060247016004@ietfa.amsl.com> Reply-To: Kyle Rose Date: Fri, 30 Jul 2021 13:35:57 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-tcpm-rfc793bis-24 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, 30 Jul 2021 20:35:58 -0000 Reviewer: Kyle Rose Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is Almost Ready for publication. The Security and Privacy Considerations section briefly outlines the implications of TCP's long legacy, stretching back to the halcyon days of a friendlier internet. The paragraphs outlining layered security (e.g., IPsec, TLS) and TCP option-based security (e.g., TCP-AO, tcpcrypt) provide a good summary of the mechanisms since developed to add security to a protocol that has otherwise met the challenges of an internet that is many orders of magnitude larger than it was 40 years ago. The one item I see missing from this section is a mention of lessons learned and subsequently applied to the design of QUIC. I think it is worth mentioning, for instance, that TCP's large surface area of cleartext metadata exposes more information to the path than required to successfully route packets to their destination, including to on-path adversaries that may be able to use this metadata to bolster targeted or pervasive surveillance. There is one more omission, adjacent to (but not explicitly about) security, that I think warrants some text in this document: that is around ossification. Given the lengthy back-and-forth I witnessed as chair of the TCPINC WG regarding the (in)feasibility of protecting segmentation and header values on the public internet, it is probably worth adding to a 793bis document a section that briefly outlines the ossification impact of voluminous cleartext and unprotected/un-GREASEd metadata, maybe with a reference to the wire image as defined by RFC 8546. The reason I think this is worthwhile is that it would be good to have the practical limits of TCP extensibility (i.e., in a world with middleboxes and other deeply TCP-aware network elements) documented where folks might look for it when thinking about new options or other new functionality. I would be happy to help flesh out some text here. From nobody Fri Jul 30 15:49:58 2021 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 BA86D3A14EC; Fri, 30 Jul 2021 15:49:55 -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-httpbis-message-signatures.all@ietf.org, ietf-http-wg@w3.org X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162768539570.14788.6438448354422571640@ietfa.amsl.com> Reply-To: Daniel Migault Date: Fri, 30 Jul 2021 15:49:55 -0700 Archived-At: Subject: [secdir] Secdir early review of draft-ietf-httpbis-message-signatures-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, 30 Jul 2021 22:49:57 -0000 Reviewer: Daniel Migault Review result: Has Issues 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 main issue I have is the absence of security considerations ;-), but otherwise the text appears to me quite clear. I will review the document once the security consideration is completed. I do not see the document mentioning any sort of negotiation which limits the scope of possible downgrade attacks or the ability from one party to "orchestrate" in some ways, what the other party. In other words, if I did not missed anything the signature is a local policy. This typically means that a client may sign while responses may not be signed. Section 1.5 defines what needs to be agreed between multiple parties, but does not provides details how this could be achieved. Some very minor editorial comments. section 1.4 The qualified term "digital signature" refers specifically to the output of an asymmetric cryptographic signing operation. May be that would be clearer to define digital signature before mentioning "signature" is used for both digital signature and Keyed MAC. section 1.5 * The set of content identifiers (Section 2) that are expected and required. I suppose that the content are security related, but it is unclear at least to me at this stage if the content have any kind of limitation. Typically, if a party is able require an specific header that leaks private information, that may be an issue. I think the text might be able to clarify this. Though I expected it to be detailed later and "expected" security related information is always suspicious of ending in a best effort situation where security is optional. These are simply what come to my mind when reading these lines. There is no necessary some actions to be taken if you believe that is not necessary. section 2.4 If covered content references an identifier that cannot be resolved to a value in the message, the implementation MUST produce an error. Such situations are included but not limited to: * The signer or verifier does not understand the content identifier. * The identifier identifies a header field that is not present in the message or whose value is malformed. If the value is malformed, it may indicate that the value is interpreted previously the integrity has been checked. I am sure this is not what the text is meaning, but this is how I read it, so I believe that some clarification may be needed. From nobody Fri Jul 30 21:48:28 2021 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 8A5023A12E8; Fri, 30 Jul 2021 21:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=x7yOud9I; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rL1pjlot 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 P8vwr4dMHbDA; Fri, 30 Jul 2021 21:48:21 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B1C83A12E1; Fri, 30 Jul 2021 21:48:18 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id BEC1E5C00B6; Sat, 31 Jul 2021 00:48:15 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 31 Jul 2021 00:48:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=4 gC3WAjzyUbe19w+vmFaHUZY67vINE7P2MkM3tisSUE=; b=x7yOud9INzpfqf1wv S5tJeVcNwCTYZ5pRU2PxdACjVUK2LLYDrGvbMc7nbSgY4HbRgs0Zrkx3Ubc1V6U2 0UlIdLQXKKgiJnpj9+dCKdH7EdwJ4wZ5gpZjCESOpADDC1n7yp0lLA3DF6alXpnl ds1BpN3WYTiLU1eaXlwr3KgrYD0nmzs1bIxHkCM7C972EpE9DLJShbSxlJx9/K1M 7EBZOh3LYud9lhwCXkcHOnSSOJKBf8WTzk4X2mhgO9IcIR52VL3gsOn2cYCsv1Ou 7yrK4NueuLd8uKC6F+wlX3JoENnuHbsVOqoO6mvAYNI4AHzHZrz2TBxgRYzqfe7z dNx7w== 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=4gC3WAjzyUbe19w+vmFaHUZY67vINE7P2MkM3tisS UE=; b=rL1pjlotNZg7uiHkDeypZI91oBxMTsoxN1HkckiHnlZ4aPlC+I+fUMpm7 zJLosODzic/syiFhmrOOexb752pKToLmV1L0D5tLYDEZrw3nZxwYy3ufd9FQWj78 ja63EP0Xnaz4DWRFp/7rUoO7y2ULioA9BqLQ8NV/Z+mLvZqW4yGf5Q5C/yhgjicR O2RsTqOwMref2l0RkxTfGop51G3ldCVgPNga36HI4vYfDbkaQpPFnOHPwqc/51KA mvllizn8ucH3tB92qLDwWZDYODHl5hd7JjxiRDVjt4cEpxobbFpV2kfmC+9Ze7OK vS6L7730EvT7Cv7MtOekH0cVjPTEg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrheeigdekhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepvefffffhudetveevhfeuffeigedtuedtheffleetffeftddtgeegjeehieeuteet necuffhomhgrihhnpehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 31 Jul 2021 00:48:12 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mark Nottingham In-Reply-To: <162768539570.14788.6438448354422571640@ietfa.amsl.com> Date: Sat, 31 Jul 2021 14:48:10 +1000 Cc: secdir@ietf.org, draft-ietf-httpbis-message-signatures.all@ietf.org, ietf-http-wg@w3.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <162768539570.14788.6438448354422571640@ietfa.amsl.com> To: Daniel Migault X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-httpbis-message-signatures-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: Sat, 31 Jul 2021 04:48:27 -0000 Thanks for the review, Daniel - much appreciated. > On 31 Jul 2021, at 8:49 am, Daniel Migault via Datatracker = wrote: >=20 > Reviewer: Daniel Migault > Review result: Has Issues >=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 main issue I have is the absence of security considerations ;-), = but > otherwise the text appears to me quite clear. I will review the = document once > the security consideration is completed. >=20 > I do not see the document mentioning any sort of negotiation which = limits the > scope of possible downgrade attacks or the ability from one party to > "orchestrate" in some ways, what the other party. In other words, if I = did not > missed anything the signature is a local policy. This typically means = that a > client may sign while responses may not be signed. Section 1.5 = defines what > needs to be agreed between multiple parties, but does not provides = details how > this could be achieved. >=20 > Some very minor editorial comments. > section 1.4 > > The qualified term "digital > signature" refers specifically to the output of an asymmetric > cryptographic signing operation. >=20 > May be that would be clearer to define digital signature before = mentioning > "signature" is used for both digital signature and Keyed MAC. >=20 > section 1.5 > * The set of content identifiers (Section 2) that are expected and > required. > > I suppose that the content are security related, but it is unclear at = least to > me at this stage if the content have any kind of limitation. = Typically, if a > party is able require an specific header that leaks private = information, that > may be an issue. I think the text might be able to clarify this. >=20 > Though I expected it to be detailed later and "expected" security = related > information is always suspicious of ending in a best effort situation = where > security is optional. These are simply what come to my mind when = reading these > lines. There is no necessary some actions to be taken if you believe = that is > not necessary. >=20 > section 2.4 > > If covered content references an identifier that cannot be resolved > to a value in the message, the implementation MUST produce an error. > Such situations are included but not limited to: >=20 > * The signer or verifier does not understand the content = identifier. >=20 > * The identifier identifies a header field that is not present in > the message or whose value is malformed. >=20 > If the value is malformed, it may indicate that the value is = interpreted > previously the integrity has been checked. I am sure this is not what = the text > is meaning, but this is how I read it, so I believe that some = clarification may > be needed. >=20 >=20 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Sat Jul 31 04:39:13 2021 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 B6B533A22FF; Sat, 31 Jul 2021 04:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 NB7n_VVosGBN; Sat, 31 Jul 2021 04:39:07 -0700 (PDT) Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (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 E1BC83A22FE; Sat, 31 Jul 2021 04:39:06 -0700 (PDT) Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id 16VBXQCG025468; Sat, 31 Jul 2021 07:34:23 -0400 Received: from w92expo18.exchange.mit.edu (18.7.74.72) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Sat, 31 Jul 2021 07:33:43 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92expo18.exchange.mit.edu (18.7.74.72) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Sat, 31 Jul 2021 07:33:55 -0400 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1497.023; Sat, 31 Jul 2021 07:33:55 -0400 From: Justin Richer To: Mark Nottingham , Daniel Migault CC: "secdir@ietf.org" , "draft-ietf-httpbis-message-signatures.all@ietf.org" , "ietf-http-wg@w3.org" Thread-Topic: Secdir early review of draft-ietf-httpbis-message-signatures-05 Thread-Index: AQHXhZWrWg4OIyRVykuj7GZtQXGhA6tcxmgAgAAuHAo= Date: Sat, 31 Jul 2021 11:33:55 +0000 Message-ID: <898a6fb4002e46a7a964c083400ef272@oc11expo18.exchange.mit.edu> References: <162768539570.14788.6438448354422571640@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [71.174.62.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-httpbis-message-signatures-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: Sat, 31 Jul 2021 11:39:12 -0000 Thank you for the review, these are all excellent comments and we'll incorp= orate them into the next drafts. - Justin ________________________________________ From: Mark Nottingham [mnot@mnot.net] Sent: Saturday, July 31, 2021 12:48 AM To: Daniel Migault Cc: secdir@ietf.org; draft-ietf-httpbis-message-signatures.all@ietf.org; ie= tf-http-wg@w3.org Subject: Re: Secdir early review of draft-ietf-httpbis-message-signatures-0= 5 Thanks for the review, Daniel - much appreciated. > On 31 Jul 2021, at 8:49 am, Daniel Migault via Datatracker wrote: > > Reviewer: Daniel Migault > Review result: Has Issues > > Hi, > > 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. These co= mments > were written primarily for the benefit of the security area directors. Do= cument > editors and WG chairs should treat these comments just like any other las= t call > comments. > > The main issue I have is the absence of security considerations ;-), but > otherwise the text appears to me quite clear. I will review the document = once > the security consideration is completed. > > I do not see the document mentioning any sort of negotiation which limits= the > scope of possible downgrade attacks or the ability from one party to > "orchestrate" in some ways, what the other party. In other words, if I di= d not > missed anything the signature is a local policy. This typically means tha= t a > client may sign while responses may not be signed. Section 1.5 defines w= hat > needs to be agreed between multiple parties, but does not provides detail= s how > this could be achieved. > > Some very minor editorial comments. > section 1.4 > > The qualified term "digital > signature" refers specifically to the output of an asymmetric > cryptographic signing operation. > > May be that would be clearer to define digital signature before mentionin= g > "signature" is used for both digital signature and Keyed MAC. > > section 1.5 > * The set of content identifiers (Section 2) that are expected and > required. > > I suppose that the content are security related, but it is unclear at lea= st to > me at this stage if the content have any kind of limitation. Typically, i= f a > party is able require an specific header that leaks private information, = that > may be an issue. I think the text might be able to clarify this. > > Though I expected it to be detailed later and "expected" security related > information is always suspicious of ending in a best effort situation whe= re > security is optional. These are simply what come to my mind when reading = these > lines. There is no necessary some actions to be taken if you believe that= is > not necessary. > > section 2.4 > > If covered content references an identifier that cannot be resolved > to a value in the message, the implementation MUST produce an error. > Such situations are included but not limited to: > > * The signer or verifier does not understand the content identifier. > > * The identifier identifies a header field that is not present in > the message or whose value is malformed. > > If the value is malformed, it may indicate that the value is interpreted > previously the integrity has been checked. I am sure this is not what the= text > is meaning, but this is how I read it, so I believe that some clarificati= on may > be needed. > > > -- Mark Nottingham https://www.mnot.net/