From nobody Fri Apr 1 06:51:03 2022 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 EBA8F3A100F; Fri, 1 Apr 2022 06:50:49 -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: avt@ietf.org, draft-ietf-avtcore-cryptex.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164882104986.17214.4620967098716441367@ietfa.amsl.com> Reply-To: Rifaat Shekh-Yusef Date: Fri, 01 Apr 2022 06:50:49 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-avtcore-cryptex-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, 01 Apr 2022 13:50:50 -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. The summary of the review is Ready with One Issue Section 5.2, First paragraph, last sentence: "The implementation MAY stop and report an error if it considers use of this specification mandatory for the RTP stream." If the implementation considers this to be *mandatory*, why is the above statement state "MAY stop and report an error"? It seems to me that in this case, at least a SHOULD is warranted here. Am I missing something? Regards, Rifaat From nobody Mon Apr 4 06:34:33 2022 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 070E23A08AE; Mon, 4 Apr 2022 06:34:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sean Turner via Datatracker To: Cc: draft-davies-int-historic.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164907925893.8122.10821570495810142802@ietfa.amsl.com> Reply-To: Sean Turner Date: Mon, 04 Apr 2022 06:34:19 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-davies-int-historic-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2022 13:34:19 -0000 Reviewer: Sean Turner Review result: Ready The two things I could think of were addressed in the security considerations. I think this I-D is ready to go. From nobody Mon Apr 4 09:42:32 2022 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 A5C583A0D1B; Mon, 4 Apr 2022 09:42:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Schwartz via Datatracker To: Cc: draft-ietf-teep-architecture.all@ietf.org, last-call@ietf.org, teep@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164909055057.18923.16848620844126899064@ietfa.amsl.com> Reply-To: Benjamin Schwartz Date: Mon, 04 Apr 2022 09:42:30 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-teep-architecture-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: Mon, 04 Apr 2022 16:42:31 -0000 Reviewer: Benjamin Schwartz Review result: Has Nits This draft is (obviously) highly relevant to the Security Area. It is clear and well-written, but the complexity of subject matter leads to some difficulties and oversights. Section 1: The use of the term "applications" carries an implication of a client-side device with installable software, but TEEP seems to extend also to server software sharing a kernel, hypervisors sharing a mainboard, etc. A term like "software" would be more neutral. "An application component ... is referred to as a Trusted Application": This is confusing. A component, explicitly not an entire "application", is referred to as an "application". "Trusted Component" would be more consistent. Also, "trusted" seems to be the wrong adjective here, as it is the environment, and not the software, that carries an elevated level of trust. "Isolated" might be a better descriptor. If this is common terminology for the field, a citation would be good. I would appreciate some discussion of whether the Device Owner needs to trust the Trusted Application, i.e. interaction between enclaves and sandboxes. "verify the ... rights of TA developers": "rights" is a loaded term. Rather than get into constitutional law, consider "permissions". "so that the Untrusted Application can complete" -> "so that installation of the Untrusted Application can complete". "is considered confidential" -- By whom? From whom? Consider "A developer who wants to provide a TA without revealing its code to the device owner..." "A TEE ... wants to determine" ... excessive personification. I suggest "needs". Section 2: "it is more common for the enterprise to own the device, and any device user has no or limited administration rights": Grammar issue. Perhaps "and for any device user to have ...". Section 3.1 "trusted user interface" ... can you cite an example of a mobile device with a trusted peripheral that is not accessible to the REE OS? This seems theoretical. Section 3.3 Similarly, are there any examples of IoT devices that prevent the REE OS from operating certain actuators? Section 4.1 the TAM cannot directly contact a TEEP Agent, but must wait for the TEEP Broker to contact the TAM requesting a particular service. This architecture is intentional in order to accommodate network and application firewalls This is true in many use cases, but for Confidential Cloud the reverse logic applies. In fact, the TAM could be operating on-site inside an enterprise, requiring a firewall exception to be reachable from the TEEP Broker. This architecture is also unnatural: it converts an event-driven "update command" into a polling loop that adds delay and wastes resources. Why is this part of the TEEP architecture? Surely it could be handled by a reversal-of-control pattern one layer below TEEP (e.g. Server-sent events)? I think the real motivation here is (1) installation is presumed to be triggered locally, by the Untrusted Application, so the TAM must be reachable as a "server", and the other side naturally should keep the client role; (2) the TAM is intended to have O(1) state while serving N devices. For a TAM to be successful, it must have its public key or certificate installed in a device's Trust Anchor Store. This needs discussion of threat model. What damage can a hostile TAM do? What does the device administrator need to know for adding a trust anchor to be safe? Section 4.4 Implementations must support encryption of such Personalization Data to preserve the confidentiality of potentially sensitive data contained within it, Implementations of what? and must support integrity protection of the Personalization Data. Lower-case "must" without explanation. Why, and is this a normative requirement? Section 4.4.2 "e.g., OP-TEE" -> What is this? Section 5.4 When a PKI is used, many intermediate CA certificates can chain to a root certificate, each of which can issue many certificates. Intermediate CAs have a troubled history (e.g. [1]), and techniques that make them safer (e.g. x.509 name constraints) can't be deployed as a retrofit. Does TEEP need some rules about supported x.509 extensions? Section 6.2.1 If an Untrusted Application is summarily deleted, how do you avoid leaking the TA? Section 7 TEEP is format-agnostic for attestations, but what about message-sequence-agnostic? Can it tunnel arbitrary challenge-response sequences? Section 9.3 We have already seen examples of attacks on the public Internet with billions of compromised devices being used to mount DDoS attacks. Citation please. Also, are you sure it has reached into billions? Section 9: Nothing here seems to discuss attacks on the TEE's properties, and the post-compromise implications of those attacks. For example, if all instances of a TA share a secret key, used for decrypting the Personalization Data, then a single successful attack on a TEE is sufficient to decrypt all Personalization Data (previous and future). Given the prevalence of such attacks (especially via hardware fault injection), it seems likely to be worth mentioning. [1] https://arstechnica.com/information-technology/2015/03/google-warns-of-unauthorized-tls-certificates-trusted-by-almost-all-oses/ From nobody Tue Apr 5 03:27:43 2022 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 DBF4E3A1FF8; Tue, 5 Apr 2022 03:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es 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 RTH2nHVl5bbx; Tue, 5 Apr 2022 03:27:25 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2783A2026; Tue, 5 Apr 2022 03:27:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1649154438; x=1649759238; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=DYLjnYYs/MZ0siOgHPFigla/g0owQ5WbmMpmu+iSIbQ=; b=wnfF8gozCeIzr xXi4oUy0VtXqdFLmVy/HWj2aoHcF2dRcPfpIHqLZAWe//P9nOtWLM9Zc9n5c+NwT GgQxwPbxSxW509b2SXwUlRGtF8u++dhTSMrKOzCVizQLmqhXb1YiZAnhN0yfbjue orMEtmys0sVTojC9+7CwR5dcPCEetw= X-Spam-Processed: mail.consulintel.es, Tue, 05 Apr 2022 12:27:18 +0200 Received: from [10.10.10.145] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000837540.msg; Tue, 05 Apr 2022 12:27:17 +0200 X-MDRemoteIP: 2001:470:1f09:495:99c9:f462:557b:2045 X-MDHelo: [10.10.10.145] X-MDArrival-Date: Tue, 05 Apr 2022 12:27:17 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1094617358=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/16.60.22022702 Date: Tue, 05 Apr 2022 12:27:17 +0200 From: JORDI PALET MARTINEZ To: CC: , , , Message-ID: <3AA6F7E2-3C79-4C6A-A2F1-83FED3EFC450@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-comparison-03.txt References: <164915364489.6833.1561854650298933331@ietfa.amsl.com> In-Reply-To: <164915364489.6833.1561854650298933331@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [secdir] [v6ops] I-D Action: draft-ietf-v6ops-transition-comparison-03.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2022 10:27:30 -0000 Hi all, I just submitted the new version of this document, which includes correctio= ns to the nits suggested by the TSV, OPSDIR, Gen-ART and SECDIR reviews. Tk= s a lot for all the inputs! Corrected also a wrong reference to PCP with the correct one (RFC6887). Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 5/4/22, 12:15, "v6ops-bounces@ietf.org en nombre de internet-dr= afts@ietf.org" escribi=C3=B3: A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Pros and Cons of IPv6 Transition Technologies= for IPv4aaS Authors : Gabor Lencse Jordi Palet Martinez Lee Howard Richard Patterson Ian Farrer Filename : draft-ietf-v6ops-transition-comparison-03.txt Pages : 33 Date : 2022-04-05 Abstract: Several IPv6 transition technologies have been developed to provide customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-onl= y access and/or core network. All these technologies have their advantages and disadvantages, and depending on existing topology, skills, strategy and other preferences, one of these technologies ma= y be the most appropriate solution for a network operator. This document examines the five most prominent IPv4aaS technologies considering a number of different aspects to provide network operators with an easy to use reference to assist in selecting the technology that best suits their needs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-comparison= / There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-compa= rison-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-transition-compari= son-03 Internet-Drafts are also available by rsync at rsync.ietf.org::internet= -drafts _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Tue Apr 5 07:45:48 2022 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 6013D3A099D; Tue, 5 Apr 2022 07:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.107 X-Spam-Level: X-Spam-Status: No, score=-7.107 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_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=inria.fr 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 S-9TvYssdCtz; Tue, 5 Apr 2022 07:45:34 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C79C3A0908; Tue, 5 Apr 2022 07:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=6by8RQExbhB30hJUJ7e5IFM60mY4zQPj000VvrMXoH0=; b=icwnqzufnrdkW7Faql0R7W5GQVNIXTUdt6u6CGv29Cz60oFJIzJFYshI 2/peB0lM3l/MdvMgYYcjI2eJ0YC+XpFmMX4OGMysVg/Tapx7aM+8rGJ/Z P+Y2CigSWYSONvglMJeN4+Bl1a1GMj9jMx3BYQIqxGnZyXexJA1G/GGlQ k=; Authentication-Results: mail2-relais-roc.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=vincent.roca@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr X-IronPort-AV: E=Sophos;i="5.90,236,1643670000"; d="scan'208";a="30181218" Received: from vulpes.inrialpes.fr (HELO smtpclient.apple) ([194.199.28.46]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Apr 2022 16:45:30 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) From: Vincent Roca In-Reply-To: Date: Tue, 5 Apr 2022 16:45:29 +0200 Cc: Vincent Roca , "secdir@ietf.org" , Alvaro Retana , "bier@ietf.org" , "draft-ietf-bier-bar-ipa.all@ietf.org" , "last-call@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <164811782957.30345.1786492893062018914@ietfa.amsl.com> To: "Jeffrey (Zhaohui) Zhang" X-Mailer: Apple Mail (2.3693.60.0.1.1) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-bier-bar-ipa-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: Tue, 05 Apr 2022 14:45:45 -0000 Dear Jeffrey, I=E2=80=99m okay with your update. The introduction could be clarified a bit more, but you=E2=80=99re = right, a newbie will read another document. Cheers, Vincent > Le 24 mars 2022 =C3=A0 23:52, Jeffrey (Zhaohui) Zhang = a =C3=A9crit : >=20 > Hi Vicent, Alvaro, >=20 > I have posted -11 revision to address comments from you. > @Vincent Roca - please see zzh> below. >=20 >=20 > Juniper Business Use Only >=20 > -----Original Message----- > From: Vincent Roca via Datatracker =20 > Sent: Thursday, March 24, 2022 11:30 AM > To: secdir@ietf.org > Cc: bier@ietf.org; draft-ietf-bier-bar-ipa.all@ietf.org; = last-call@ietf.org > Subject: Secdir last call review of draft-ietf-bier-bar-ipa-10 >=20 > [External Email. Be cautious of content] >=20 >=20 > Reviewer: Vincent Roca > Review result: Ready >=20 > Hello, >=20 > I have reviewed this document as part of the security directorate=E2=80=99= s ongoing effort to review all IETF documents being processed by the = IESG. These comments were written primarily for the benefit of the = security area directors. Document editors and WG chairs should treat = these comments just like any other last call comments. >=20 > Summary: Ready >=20 > I have no comment regarding the security part, little is said in = section 6 which seems appropriate. The three RFCs referenced are = appropriate and I agree with the authors the present document does not = change the situation. >=20 > However, I have a few comments on non-SecDir aspects, so feel free to = ignore it. >=20 > For someone who's not aware of the topic, the abstract and = introduction are really obscur and of little help to understand the = context (e.g., no mention of multicast). > After reading the abstract of RFC8279, then everything became clear. > Sure, RFC8279 is prominently mentioned in the introduction, yet I = think a sentence to position this document in the full architecture = would be very helpful. >=20 > Zzh> I hope updated introduction section makes it a bit clearer. >=20 > Also, the document makes use of several acronyms that are not defined: > Section 1 mentions BFERs that is never defined/expended. > Section 2 mentions BFRs that is defined only in section 3. >=20 > Zzh> Fixed. >=20 > Finally, shouldn't step 4 be rewritten to highlight the case where = RC(BC(X)), is empty as in: > 4. if (RC(BC(X) non empty) > then run AG on RC(BC(X) > else throw an exception. > As explained in Section 4, this is an exception caused by a bad = network design. >=20 > Zzh> I did not change here, because a router always run the AG on a = topology. If the topology is empty, not exception/error is thrown - the = result is just that not routes will be found. >=20 > Typo: >=20 > - Section 2: mistake, this is probably RFC 8444 and not 8441. >> The definition for the BAR and IPA fields in [RFC8401] and [RFC8441] >> are updated as following. >=20 > Zzh> Thanks for spotting it. Fixed. > Zzh> Appreciate your review and comments! > Zzh> Jeffrey >=20 > Cheers, >=20 > Vincent >=20 From nobody Tue Apr 5 14:05:00 2022 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 175D63A11AA; Tue, 5 Apr 2022 14:04:58 -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-use-cases.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164919269800.5647.13515861264060312018@ietfa.amsl.com> Reply-To: Robert Sparks Date: Tue, 05 Apr 2022 14:04:58 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-6lo-use-cases-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: Tue, 05 Apr 2022 21:04:58 -0000 Reviewer: Robert Sparks 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 has issues to address before publication as an Informational RFC Issues: >From the abstract: "The document targets an audience who would like to understand and evaluate running end-to-end IPv6 over the constrained node networks for local or Internet connectivity." Its security considerations section claims "Security considerations are not directly applicable to this document". Yet the text of the draft has several places that rightly call out thing like "there exist implications for privacy", "privacy also becomes a serious issue", and "the assumption is that L2 security must be present." A summary of these things in the security considerations section seems prudent. At _least_ call out again the assumption about L2 security. The "Security Requirement"A summary of these things in the security considerations section seems prudent. At _least_ call out again the assumption about L2 security. The "Security Requirement" row in Table 2 is not well explained. The values in that row are explained at all. (For instance, the word "Partially" appears exactly once in the document - it is unclear what it means). Nits/Comments: Appendix A is neither introduced nor referenced from the body of the document. Why is it here? I'm a little concerned about some of the technology descriptions possibly moving beyond simple facts into interpretation or even marketing. The last paragraph of section 2.5 is a particularly strong example. Look for phrases section 4 that include "targets" or "targeted by" and make sure that's what the organizations ins that define those technologies say (consider references). At 'superior "range"', why is range in quotes? Think about restructuring the sentences that use 'superior' to avoid the connotation of "better than". All this document really needs to acknowledge is "goes further". From nobody Tue Apr 5 14:10:50 2022 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 D97BC3A11B7; Tue, 5 Apr 2022 14:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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, NICE_REPLY_A=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 qeRICcPBd6aB; Tue, 5 Apr 2022 14:09:42 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D8763A11BB; Tue, 5 Apr 2022 14:09:41 -0700 (PDT) Received: from [192.168.1.114] ([47.186.48.51]) (authenticated bits=0) by nostrum.com (8.17.1/8.16.1) with ESMTPSA id 235L9dZt077330 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 5 Apr 2022 16:09:39 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1649192979; bh=GNeigeFFHIykbOOc9FIQ/I9x269P75yAm/Hw27BvRns=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=Er+6Ne+9sOFA2R7jsuP6L9OjWgUA398kN6gDOLr20a8gtalvyuTxJJSE640m3515U 5r25cMO5i1zXQ2PXZfr7z5wb9L84zhXnDm+ibOxmqSoW+Eb63SomXMs+h9u0lSvFWT ERiCtE5m3tn44hoBTPLV0sxBGa5kSC7JyuOjsqOM= X-Authentication-Warning: raven.nostrum.com: Host [47.186.48.51] claimed to be [192.168.1.114] Message-ID: Date: Tue, 5 Apr 2022 16:09:33 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: secdir@ietf.org Cc: last-call@ietf.org, draft-ietf-6lo-use-cases.all@ietf.org, 6lo@ietf.org References: <164919269800.5647.13515861264060312018@ietfa.amsl.com> From: Robert Sparks In-Reply-To: <164919269800.5647.13515861264060312018@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-6lo-use-cases-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: Tue, 05 Apr 2022 21:09:47 -0000 Apologies, there's an edit-buffer glitch below, corrected in what's uploaded at https://datatracker.ietf.org/doc/review-ietf-6lo-use-cases-12-secdir-lc-sparks-2022-04-05/. On 4/5/22 4:04 PM, Robert Sparks via Datatracker wrote: > Reviewer: Robert Sparks > 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 has issues to address before publication as an Informational RFC > > Issues: > > >From the abstract: "The document targets an audience who would like to > understand and evaluate running end-to-end IPv6 over the constrained node > networks for local or Internet connectivity." > > Its security considerations section claims "Security considerations are not > directly applicable to this document". Yet the text of the draft has several > places that rightly call out thing like "there exist implications for privacy", > "privacy also becomes a serious issue", and "the assumption is that L2 security > must be present." A summary of these things in the security considerations > section seems prudent. At _least_ call out again the assumption about L2 > security. > > The "Security Requirement"A summary of these things in the security > considerations section seems prudent. At _least_ call out again the assumption > about L2 security. > > The "Security Requirement" row in Table 2 is not well explained. The values in > that row are explained at all. (For instance, the word "Partially" appears > exactly once in the document - it is unclear what it means). > > Nits/Comments: > > Appendix A is neither introduced nor referenced from the body of the document. > Why is it here? > > I'm a little concerned about some of the technology descriptions possibly > moving beyond simple facts into interpretation or even marketing. The last > paragraph of section 2.5 is a particularly strong example. Look for phrases > section 4 that include "targets" or "targeted by" and make sure that's what the > organizations ins that define those technologies say (consider references). > > At 'superior "range"', why is range in quotes? Think about restructuring the > sentences that use 'superior' to avoid the connotation of "better than". All > this document really needs to acknowledge is "goes further". > > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview From nobody Thu Apr 7 05:03:24 2022 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 444753A00E0 for ; Thu, 7 Apr 2022 05:03: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.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <164933299925.6833.7266587073201004538@ietfa.amsl.com> Date: Thu, 07 Apr 2022 05:03: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, 07 Apr 2022 12:03:20 -0000 Review instructions and related resources are at: https://trac.ietf.org/trac/sec/wiki/SecDirReview For telechat 2022-04-07 Reviewer LC end Draft Watson Ladd R2022-02-08 draft-ietf-detnet-bounded-latency Aanchal Malhotra 2022-02-03 draft-ietf-bfd-rfc9127-bis Daniel Migault R2021-06-28 draft-ietf-ipwave-vehicular-networking Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Last calls: Reviewer LC end Draft Alan DeKok 2021-12-30 draft-ietf-sidrops-6486bis Daniel Franke 2022-01-19 draft-ietf-pim-igmp-mld-extension Daniel Gillmor 2022-01-28 draft-ietf-rats-yang-tpm-charra Watson Ladd R2022-02-08 draft-ietf-detnet-bounded-latency Aanchal Malhotra 2021-10-15 draft-ietf-kitten-tls-channel-bindings-for-tls13 Aanchal Malhotra 2022-02-03 draft-ietf-bfd-rfc9127-bis Daniel Migault R2021-06-28 draft-ietf-ipwave-vehicular-networking Sandra Murphy 2022-03-07 draft-rsalz-2028bis Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Tirumaleswar Reddy.K 2022-04-07 draft-koster-rep Stefan Santesson 2022-04-07 draft-ietf-teep-otrp-over-http Stefan Santesson 2021-08-11 draft-ietf-bier-te-arch Melinda Shore 2022-04-08 draft-ietf-tls-subcerts Tina Tsou 2022-04-04 draft-ietf-raw-ldacs Loganaden Velvindron 2022-04-12 draft-ietf-lisp-vendor-lcaf Mališa Vučinić 2022-04-08 draft-ietf-anima-constrained-join-proxy Carl Wallace 2022-04-08 draft-ietf-avtext-framemarking Brian Weis 2021-08-19 draft-ietf-dnsop-svcb-https Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Christopher Wood 2022-04-15 draft-ietf-cbor-file-magic Liang Xia 2021-03-17 draft-ietf-core-sid Early review requests: Reviewer Due Draft Stephen Farrell 2021-09-15 draft-ietf-ippm-ioam-direct-export Stephen Farrell 2021-06-21 draft-ietf-idr-bgpls-srv6-ext Tina Tsou 2021-08-25 draft-ietf-opsawg-sbom-access Loganaden Velvindron 2021-08-18 draft-ietf-taps-arch Brian Weis 2022-05-16 draft-ietf-ippm-capacity-protocol Next in the reviewer rotation: Klaas Wierenga Christopher Wood Liang Xia Dacheng Zhang John Bradley Nancy Cam-Winget Shaun Cooley Alan DeKok Linda Dunbar Donald Eastlake From nobody Fri Apr 8 06:23:48 2022 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 E39AD3A1A2A; Fri, 8 Apr 2022 06:23:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?b?TWFsacWhYSBWdcSNaW5pxIcgdmlhIERhdGF0cmFja2Vy?= To: Cc: anima@ietf.org, draft-ietf-anima-constrained-join-proxy.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164942421882.15991.10648263530009015921@ietfa.amsl.com> Reply-To: =?utf-8?b?TWFsacWhYSBWdcSNaW5pxIc=?= Date: Fri, 08 Apr 2022 06:23:38 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-anima-constrained-join-proxy-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: Fri, 08 Apr 2022 13:23:40 -0000 Reviewer: Mališa Vučinić Review result: Has Issues I have reviewed this document as part of the security directorate’s ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document standardizes the functionality of a Join Proxy, which is a node that relays the traffic between the joining node, Pledge, and the network Registrar, at the time of the network join. The document defines two modes of operation of a Join Proxy: Stateful Join Proxy and Stateless Join Proxy. I have reservations on the progress of this document in its current state from the interoperability and security points of view. Interoperability-wise, the operation of a Stateful Join Proxy does not seem to necessitate a standardization effort as the processing is contained on a single network node. The Registrar processes the packet from the Join Proxy as any other packet. The language that describes the operation of a Stateful Join Proxy in Section 5.1 is informational and describes the process rather than the protocol. I would consider moving this text outside the “Join Proxy Specification” section, perhaps into Section 4, which contains informational text. Stateless Join Proxy specification in Section 5.3 defines the message format that the Registrar and the Join Proxy agree on, which is necessary from the interoperability point of view. The message is split into Header and Content parts, where Header is opaque to the Registrar and just returned verbatim to the Join Proxy. In that sense, I don’t understand the need to specify the inner structure of the Header part. I believe this will only introduce interoperability issues with future version of the specification. In the last paragraph in Section 5.3, you argue that if any (new) field is not recognized by the Registrar, it should be ignored. But then, the protocol simply won’t be backwards compatible because Stateless Join Proxy will have expected the Registrar to echo the new fields. Why complicate this and not leave the whole “Header” struct as an opaque byte string that is just echoed by the Registrar? Security-wise, document is incomplete. Without protection of the Header field, an on-path attacker can easily alter the return address of the pledge to DoS it. This is all discussed in RFC8974 and RFC9031 so I don’t understand why none of those concerns are addressed, given the similarity of the topic. Security considerations or Figure 5 do not elaborate on DoS considerations of either approach. In general, I think that the document would use an editorial pass as there seem to be many small inconsistencies. For example, Security Considerations talk about a “CBOR map” while the normative message structure uses CBOR arrays. From nobody Fri Apr 8 09:49:42 2022 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 B1B4E3A1786; Fri, 8 Apr 2022 09:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDauA7cDV3QV; Fri, 8 Apr 2022 09:49:35 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (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 EC6753A178B; Fri, 8 Apr 2022 09:49:32 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 58E4A58C4AF; Fri, 8 Apr 2022 18:49:26 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4607A4EAB58; Fri, 8 Apr 2022 18:49:26 +0200 (CEST) Date: Fri, 8 Apr 2022 18:49:26 +0200 From: Toerless Eckert To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Cc: secdir@ietf.org, anima@ietf.org, draft-ietf-anima-constrained-join-proxy.all@ietf.org, last-call@ietf.org Message-ID: References: <164942421882.15991.10648263530009015921@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <164942421882.15991.10648263530009015921@ietfa.amsl.com> Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-anima-constrained-join-proxy-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2022 16:49:40 -0000 Malisa, Thanks a lot for the review. Just quick feedback on one of your points On Fri, Apr 08, 2022 at 06:23:38AM -0700, Mališa Vučinić via Datatracker wrote: > Interoperability-wise, the operation of a Stateful Join Proxy does not seem to > necessitate a standardization effort as the processing is contained on a single > network node. I disagree with this assessment. The stateful join proxy is a new element establishing a distributed machinery between three components, the pledge, the proxy and the registrar, which requires interoperability between the three. > The Registrar processes the packet from the Join Proxy as any > other packet. The fact that the DTLS state machinery of registrar and pledge do not have to change over a proxy-free operation is the result of the miticulous, packet by packet forwarding specified in 5.1. Rather a proof of the opposite of what you claim. For example: i can easily see how i could build a proxy that would break the connection by working differently. > The language that describes the operation of a Stateful Join > Proxy in Section 5.1 is informational and describes the process rather than the > protocol. It describes packet forwarding based on flow lookup, network header rewrite/recreate and delivery to new destination. If that isn't a standard demanding protocol operation, then we should have prohibited single-router-hop rfc791 networks, bcause this is already sso much more interoperable machinery than what is described in that rfc. Btw: Nobody says you can't build a multi-proxy-hop-network, its just not the desire of this spec to standardize it. Cheers Toerless > Stateless Join Proxy specification in Section 5.3 defines the message format > that the Registrar and the Join Proxy agree on, which is necessary from the > interoperability point of view. The message is split into Header and Content > parts, where Header is opaque to the Registrar and just returned verbatim to > the Join Proxy. In that sense, I don’t understand the need to specify the inner > structure of the Header part. I believe this will only introduce > interoperability issues with future version of the specification. In the last > paragraph in Section 5.3, you argue that if any (new) field is not recognized > by the Registrar, it should be ignored. But then, the protocol simply won’t be > backwards compatible because Stateless Join Proxy will have expected the > Registrar to echo the new fields. Why complicate this and not leave the whole > “Header” struct as an opaque byte string that is just echoed by the Registrar? > > Security-wise, document is incomplete. Without protection of the Header field, > an on-path attacker can easily alter the return address of the pledge to DoS > it. This is all discussed in RFC8974 and RFC9031 so I don’t understand why none > of those concerns are addressed, given the similarity of the topic. Security > considerations or Figure 5 do not elaborate on DoS considerations of either > approach. > > In general, I think that the document would use an editorial pass as there seem > to be many small inconsistencies. For example, Security Considerations talk > about a “CBOR map” while the normative message structure uses CBOR arrays. > -- --- tte@cs.fau.de From nobody Fri Apr 8 10:42:33 2022 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 A350A3A1963; Fri, 8 Apr 2022 10:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=inria.fr 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 kUJzlVZcxhe3; Fri, 8 Apr 2022 10:41:18 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AB183A1960; Fri, 8 Apr 2022 10:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=vvJ8S/HUMNo4FcLdbK9dRHQO+dySVBqEGa0Uw3Hfg2Y=; b=OujDk4AzTnu2V9M1q6gu6deK2zKIKmj7In7JC+8urpbHhEsmdFgX3b79 jCfuK0v6cW3+8ERBetmJ4rIxtEEj8BMgo2yXmtZw1Ko88M7hCikr1W6La QsyPKDyGbQGORXzVoL+rG+YtbVz6JZCgxsOqCmtdCVRIHS1DeW/xS1+D+ Q=; Authentication-Results: mail2-relais-roc.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=malisa.vucinic@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr X-IronPort-AV: E=Sophos;i="5.90,245,1643670000"; d="scan'208";a="30858277" Received: from unknown (HELO smtpclient.apple) ([109.190.253.11]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Apr 2022 19:41:12 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= In-Reply-To: Date: Fri, 8 Apr 2022 19:41:04 +0200 Cc: secdir@ietf.org, anima@ietf.org, draft-ietf-anima-constrained-join-proxy.all@ietf.org, last-call@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <164942421882.15991.10648263530009015921@ietfa.amsl.com> To: Toerless Eckert X-Mailer: Apple Mail (2.3693.60.0.1.1) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-anima-constrained-join-proxy-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2022 17:41:27 -0000 Toerless, Thanks for the prompt feedback. See inline. Mali=C5=A1a > On 8 Apr 2022, at 18:49, Toerless Eckert wrote: >=20 > Malisa, >=20 > Thanks a lot for the review. >=20 > Just quick feedback on one of your points >=20 > On Fri, Apr 08, 2022 at 06:23:38AM -0700, Mali=C5=A1a Vu=C4=8Dini=C4=87 = via Datatracker wrote: >> Interoperability-wise, the operation of a Stateful Join Proxy does = not seem to >> necessitate a standardization effort as the processing is contained = on a single >> network node. >=20 > I disagree with this assessment. The stateful join proxy is a new = element > establishing a distributed machinery between three components, the = pledge, the > proxy and the registrar, which requires interoperability between the = three. The following sentence attracted my attention: "The Pledge initiates its request as if the Join Proxy is the intended = Registrar." My line of thinking was that if the pledge were specified to contact any = node it discovers through the discovery mechanism, be it a Registrar or = a Join Proxy, and sends to its link-local address, the processing would = still be the same on the pledge and on the Registrar. But, as you say, = there would still need to be a component implemented in each node to = handle the Join Proxy functionality to make it work multiple hops away = from the Registrar. So, indeed, text that describes that is needed from = the interop point of view, so I acknowledge that my initial assessment = was wrong. >> The Registrar processes the packet from the Join Proxy as any >> other packet. >=20 > The fact that the DTLS state machinery of registrar and pledge do not = have to > change over a proxy-free operation is the result of the miticulous, = packet by > packet forwarding specified in 5.1. Rather a proof of the opposite of = what you > claim. For example: i can easily see how i could build a proxy that = would break the > connection by working differently. I see your point and thanks for elaborating on it.=20 >> The language that describes the operation of a Stateful Join >> Proxy in Section 5.1 is informational and describes the process = rather than the >> protocol. >=20 > It describes packet forwarding based on flow lookup, network header = rewrite/recreate > and delivery to new destination. If that isn't a standard demanding = protocol operation, then > we should have prohibited single-router-hop rfc791 networks, bcause = this is already sso > much more interoperable machinery than what is described in that rfc. I was referring to the following text in the normative 5.1 section: "Assume that the Pledge does not know the IP address of the Registrar it = needs to contact. The Join Proxy has been enrolled via the Registrar and = learns the IP address and port of the Registrar, for example by using = the discovery mechanism described in Section 6. The Pledge first = discovers (see Section 6) and selects the most appropriate Join Proxy. = (Discovery can also be based upon [RFC8995] section 4.1). For service = discovery via DNS-SD [RFC6763], this document specifies the service = names in Section 9.2. The Pledge initiates its request as if the Join = Proxy is the intended Registrar. The Join Proxy receives the message at = a discoverable join-port.=E2=80=9D I am not arguing to *remove* this text, rather to separate it from the = rest of the paragraph, which clearly describes the processing at the = Stateful Join Proxy. Is this text also applicable to the Stateless Join = Proxy case, or I got that wrong? > Btw: Nobody says you can't build a multi-proxy-hop-network, its just = not > the desire of this spec to standardize it. >=20 > Cheers > Toerless >=20 >> Stateless Join Proxy specification in Section 5.3 defines the message = format >> that the Registrar and the Join Proxy agree on, which is necessary = from the >> interoperability point of view. The message is split into Header and = Content >> parts, where Header is opaque to the Registrar and just returned = verbatim to >> the Join Proxy. In that sense, I don=E2=80=99t understand the need to = specify the inner >> structure of the Header part. I believe this will only introduce >> interoperability issues with future version of the specification. In = the last >> paragraph in Section 5.3, you argue that if any (new) field is not = recognized >> by the Registrar, it should be ignored. But then, the protocol simply = won=E2=80=99t be >> backwards compatible because Stateless Join Proxy will have expected = the >> Registrar to echo the new fields. Why complicate this and not leave = the whole >> =E2=80=9CHeader=E2=80=9D struct as an opaque byte string that is just = echoed by the Registrar? >>=20 >> Security-wise, document is incomplete. Without protection of the = Header field, >> an on-path attacker can easily alter the return address of the pledge = to DoS >> it. This is all discussed in RFC8974 and RFC9031 so I don=E2=80=99t = understand why none >> of those concerns are addressed, given the similarity of the topic. = Security >> considerations or Figure 5 do not elaborate on DoS considerations of = either >> approach. >>=20 >> In general, I think that the document would use an editorial pass as = there seem >> to be many small inconsistencies. For example, Security = Considerations talk >> about a =E2=80=9CCBOR map=E2=80=9D while the normative message = structure uses CBOR arrays. >>=20 >=20 > --=20 > --- > tte@cs.fau.de From nobody Sun Apr 10 06:23:46 2022 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 095963A1250; Sun, 10 Apr 2022 06:23:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Watson Ladd via Datatracker To: Cc: detnet@ietf.org, draft-ietf-detnet-bounded-latency.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164959702293.14454.14070167077085193809@ietfa.amsl.com> Reply-To: Watson Ladd Date: Sun, 10 Apr 2022 06:23:43 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-detnet-bounded-latency-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, 10 Apr 2022 13:23:43 -0000 Reviewer: Watson Ladd Review result: Ready Apologies for my tardy rereview. The issues I spotted earlier have been addressed and I don't see any others. From nobody Mon Apr 11 00:35:27 2022 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 25D0C3A1D81; Mon, 11 Apr 2022 00:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.nl 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 G8_upbru-aIs; Mon, 11 Apr 2022 00:35:17 -0700 (PDT) Received: from relay4.hostedemail.com (relay4.hostedemail.com [64.99.140.36]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5910D3A1D7D; Mon, 11 Apr 2022 00:35:16 -0700 (PDT) Received: from omf01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 66BE823DA0; Mon, 11 Apr 2022 07:35:15 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: stokcons@bbhmail.nl) by omf01.hostedemail.com (Postfix) with ESMTPA id BE81E6000E; Mon, 11 Apr 2022 07:35:14 +0000 (UTC) MIME-Version: 1.0 Date: Mon, 11 Apr 2022 09:35:14 +0200 From: Peter van der Stok To: =?UTF-8?Q?Mali=C5=A1a_Vu=C4=8Dini=C4=87?= Cc: secdir@ietf.org, anima@ietf.org, draft-ietf-anima-constrained-join-proxy.all@ietf.org, last-call@ietf.org Reply-To: stokcons@bbhmail.nl Mail-Reply-To: stokcons@bbhmail.nl In-Reply-To: <164942421882.15991.10648263530009015921@ietfa.amsl.com> References: <164942421882.15991.10648263530009015921@ietfa.amsl.com> Message-ID: X-Sender: stokcons@bbhmail.nl Organization: vanderstok consultancy Content-Type: multipart/alternative; boundary="=_0700dcd953896ba6b3321612322d1a08" X-Rspamd-Queue-Id: BE81E6000E X-Stat-Signature: gjpt8whpmgto5c5n4boquqhx31s6x5zk X-Rspamd-Server: rspamout03 X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Session-ID: U2FsdGVkX1+NIex4yrIfVJ930sI/fZ6md0+NYOPTlh4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h=mime-version:date:from:to:cc:subject:reply-to:in-reply-to:references:message-id:content-type; s=key; bh=62xAXEQUaX1H6o3+8QCEIHL8P6tN7gH5ftqb/WkaHEo=; b=OXgumJE4Ama60laWLTvU/fidPe2Uid4tvPUVHAaYSclE0nFHxNenszDLcDbt1hUpOaBbXwUTqcaWgtQ4Q77OnbMtntGfbEpoEx1jZi/M3PldFCIhEOBZj8U3U5FDNkmtDMjeuZqjYbI/EGwHJXmNhdMZZBHhl64ML2XUlYbwujE= X-HE-Tag: 1649662514-541092 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-anima-constrained-join-proxy-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2022 07:35:23 -0000 --=_0700dcd953896ba6b3321612322d1a08 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed HI Malisa, thanks for the review. Toerless having reacted to the first pargraph, I will react to the last part. Plese, see below. Peter Mališa Vučinić via Datatracker schreef op 2022-04-08 15:23: > Reviewer: Mališa Vučinić > Review result: Has Issues > > I have reviewed this document as part of the security directorate's > ongoing > effort to review all IETF documents being processed by the IESG. These > comments > were written primarily for the benefit of the security area directors. > Document editors and WG chairs should treat these comments just like > any other > last call comments. > > The document standardizes the functionality of a Join Proxy, which is a > node > that relays the traffic between the joining node, Pledge, and the > network > Registrar, at the time of the network join. The document defines two > modes of > operation of a Join Proxy: Stateful Join Proxy and Stateless Join > Proxy. > > I have reservations on the progress of this document in its current > state from > the interoperability and security points of view. > > Interoperability-wise, the operation of a Stateful Join Proxy does not > seem to > necessitate a standardization effort as the processing is contained on > a single > network node. The Registrar processes the packet from the Join Proxy as > any > other packet. The language that describes the operation of a Stateful > Join > Proxy in Section 5.1 is informational and describes the process rather > than the > protocol. I would consider moving this text outside the "Join Proxy > Specification" section, perhaps into Section 4, which contains > informational > text. > > Stateless Join Proxy specification in Section 5.3 defines the message > format > that the Registrar and the Join Proxy agree on, which is necessary from > the > interoperability point of view. The message is split into Header and > Content > parts, where Header is opaque to the Registrar and just returned > verbatim to > the Join Proxy. In that sense, I don't understand the need to specify > the inner > structure of the Header part. I believe this will only introduce > interoperability issues with future version of the specification. In > the last > paragraph in Section 5.3, you argue that if any (new) field is not > recognized > by the Registrar, it should be ignored. But then, the protocol simply > won't be > backwards compatible because Stateless Join Proxy will have expected > the > Registrar to echo the new fields. Why complicate this and not leave the > whole > "Header" struct as an opaque byte string that is just echoed by the > Registrar? > > pvds==> > Yes, I think you are right. The header structure should be opaque. > If the Registrar needs information stored in the header, then IMO a new > draft shoudl] > address this. > I will change the text accordingly if my co-authors agree. > ==> > > Security-wise, document is incomplete. Without protection of the Header > field, > an on-path attacker can easily alter the return address of the pledge > to DoS > it. This is all discussed in RFC8974 and RFC9031 so I don't understand > why none > of those concerns are addressed, given the similarity of the topic. > Security > considerations or Figure 5 do not elaborate on DoS considerations of > either > approach. > > pvds==> > I see. The text of RFC8974 seems the most appropriate one. I will refer > to it > in the security consideration, taking over the recommended encryption > algorithm. > ==> > > In general, I think that the document would use an editorial pass as > there seem > to be many small inconsistencies. For example, Security Considerations > talk > about a "CBOR map" while the normative message structure uses CBOR > arrays. > > pvds==> > Very good. Apologies. This mistake reflects the hitory traject of the > document. > ==> --=_0700dcd953896ba6b3321612322d1a08 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 HI Malisa,

thanks for the review.
Toerless having reacted t= o the first pargraph, I will react to the last part.

Plese, see = below.

Peter

Mališa Vu=C4=8Dini=C4=87 via Datatracker schre= ef op 2022-04-08 15:23:

= Reviewer: Mališa Vu=C4=8Dini=C4=87
Review result: Has Issues
I have reviewed this document as part of the security directorate&= rsquo;s ongoing
effort to review all IETF documents being processed by= the IESG. These comments
were written primarily for the benefit of th= e security area directors.
Document editors and WG chairs should trea= t these comments just like any other
last call comments.

Th= e document standardizes the functionality of a Join Proxy, which is a node<= br />that relays the traffic between the joining node, Pledge, and the netw= ork
Registrar, at the time of the network join. The document defines t= wo modes of
operation of a Join Proxy: Stateful Join Proxy and Statele= ss Join Proxy.

I have reservations on the progress of this docum= ent in its current state from
the interoperability and security points= of view.

Interoperability-wise, the operation of a Stateful Joi= n Proxy does not seem to
necessitate a standardization effort as the p= rocessing is contained on a single
network node. The Registrar process= es the packet from the Join Proxy as any
other packet. The language th= at describes the operation of a Stateful Join
Proxy in Section 5.1 is = informational and describes the process rather than the
protocol. I wo= uld consider moving this text outside the “Join Proxy
Specificat= ion” section, perhaps into Section 4, which contains informationaltext.

Stateless Join Proxy specification in Section 5.3 defin= es the message format
that the Registrar and the Join Proxy agree on, = which is necessary from the
interoperability point of view. The messag= e is split into Header and Content
parts, where Header is opaque to th= e Registrar and just returned verbatim to
the Join Proxy. In that sens= e, I don’t understand the need to specify the inner
structure of= the Header part. I believe this will only introduce
interoperability = issues with future version of the specification. In the last
paragraph= in Section 5.3, you argue that if any (new) field is not recognized
b= y the Registrar, it should be ignored. But then, the protocol simply won&rs= quo;t be
backwards compatible because Stateless Join Proxy will have e= xpected the
Registrar to echo the new fields. Why complicate this and = not leave the whole
“Header” struct as an opaque byte stri= ng that is just echoed by the Registrar?

pvds=3D=3D>
Yes= , I think you are right. The header structure should be opaque.
If the= Registrar needs information stored in the header, then IMO a new draft sho= udl]
address this.
I will change the text accordingly if my co-au= thors agree.
=3D=3D>

Security-wise, document is incomple= te. Without protection of the Header field,
an on-path attacker can ea= sily alter the return address of the pledge to DoS
it. This is all dis= cussed in RFC8974 and RFC9031 so I don’t understand why none
of = those concerns are addressed, given the similarity of the topic. Securityconsiderations or Figure 5 do not elaborate on DoS considerations of ei= ther
approach.


pvds=3D=3D>
I see. The text of= RFC8974 seems the most appropriate one. I will refer to it
in the sec= urity consideration, taking over the recommended encryption algorithm.
=3D=3D>

In general, I think that the document would use an e= ditorial pass as there seem
to be many small inconsistencies. For exam= ple, Security Considerations talk
about a “CBOR map” while= the normative message structure uses CBOR arrays.

pvds=3D=3D>= ;
Very good. Apologies. This mistake reflects the hitory traject of th= e document.
=3D=3D>


--=_0700dcd953896ba6b3321612322d1a08-- From nobody Mon Apr 11 03:33:33 2022 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 3CAE13A1328; Mon, 11 Apr 2022 03:32:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Carl Wallace via Datatracker To: Cc: avt@ietf.org, draft-ietf-avtext-framemarking.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164967314513.32128.2582071611829692564@ietfa.amsl.com> Reply-To: Carl Wallace Date: Mon, 11 Apr 2022 03:32:25 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-avtext-framemarking-13 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, 11 Apr 2022 10:32:26 -0000 Reviewer: Carl Wallace Review result: Ready This is an experimental document that describes a Frame Marking RTP header extension used to convey information about video frames that is critical for error recovery and packet forwarding in RTP middleboxes or network nodes. It is well written and ready to go. The only minor comment I had was that the security considerations may benefit from a reference to the security considerations in RFC 8285, if only to pull in the SHOULD regarding header integrity protection. From nobody Thu Apr 14 09:01:19 2022 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 C86FF3A0412; Thu, 14 Apr 2022 02:01:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1649926870; bh=mqT+WtoS+12RTl3ktlYsgX87YhzTwkBKpZeiQhinMPg=; h=Date:To:From:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=jDHGIw8c+izxRX7JcC5JLA677EhlmqiYh+BkgNsEy2n2+qXQyKqLI6wqlOKpx/g2f F3sOcDXxO71mrhDiCT1rKGF3MVCkORRL+akT+TYJS3gZS1HHXivup0kbqOrIKNAYwu p0TEKxMYFLGNldWLrV30uePiqQLPHVX/sI5ZID50= X-Mailbox-Line: From new-work-bounces@ietf.org Thu Apr 14 02:01:10 2022 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBF03A03FC; Thu, 14 Apr 2022 02:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1649926870; bh=mqT+WtoS+12RTl3ktlYsgX87YhzTwkBKpZeiQhinMPg=; h=Date:To:From:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=jDHGIw8c+izxRX7JcC5JLA677EhlmqiYh+BkgNsEy2n2+qXQyKqLI6wqlOKpx/g2f F3sOcDXxO71mrhDiCT1rKGF3MVCkORRL+akT+TYJS3gZS1HHXivup0kbqOrIKNAYwu p0TEKxMYFLGNldWLrV30uePiqQLPHVX/sI5ZID50= 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 65EFB3A03FC for ; Thu, 14 Apr 2022 02:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.914 X-Spam-Level: X-Spam-Status: No, score=-4.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.998, HK_RANDOM_FROM=0.998, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmgNgxHBPYes for ; Thu, 14 Apr 2022 02:01:02 -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 75CC13A0163 for ; Thu, 14 Apr 2022 02:01:01 -0700 (PDT) Received: from moon.w3.org ([128.30.55.110] helo=[10.87.51.5]) by raoul.w3.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nevLX-0003XZ-NK for new-work@ietf.org; Thu, 14 Apr 2022 09:01:00 +0000 Message-ID: <76106b04-3000-25fe-d996-f34d3e50a312@w3.org> Date: Thu, 14 Apr 2022 17:00:55 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Content-Language: en-US To: new-work@ietf.org From: xueyuan 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: Thu, 14 Apr 2022 09:01:18 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: HTML Working Group (until 2022-05-22/23) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2022 09:01:14 -0000 SGVsbG8sCgpUb2RheSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcyByZWNl aXZlZCBhIFByb3Bvc2FsCnRvIHJldmlldyBhIGRyYWZ0IGNoYXJ0ZXIgZm9yIHRoZSBIVE1MIFdv cmtpbmcgR3JvdXA6CiDCoCBodHRwczovL3d3dy53My5vcmcvMjAyMi8wNC9wcm9wb3NlZC1odG1s LXdnLWNoYXJ0ZXIuaHRtbAoKQXMgcGFydCBvZiBlbnN1cmluZyB0aGF0IHRoZSBjb21tdW5pdHkg aXMgYXdhcmUgb2YgcHJvcG9zZWQgd29yawphdCBXM0MsIHRoaXMgZHJhZnQgY2hhcnRlciBpcyBw dWJsaWMgZHVyaW5nIHRoZSBBZHZpc29yeQpDb21taXR0ZWUgcmV2aWV3IHBlcmlvZC4KClczQyBp bnZpdGVzIHB1YmxpYyBjb21tZW50cyB0aHJvdWdoIDAzOjU5IFVUQyBvbiAyMyBNYXkgMjAyMgoo MjM6NTksIEJvc3RvbiB0aW1lIG9uIDIyIE1heSkgWzBdIG9uIHRoZSBwcm9wb3NlZCBjaGFydGVy LiBQbGVhc2UKc2VuZCBjb21tZW50cyB0byBwdWJsaWMtbmV3LXdvcmtAdzMub3JnLCB3aGljaCBo YXMgYSBwdWJsaWMgYXJjaGl2ZToKIMKgIGh0dHBzOi8vbGlzdHMudzMub3JnL0FyY2hpdmVzL1B1 YmxpYy9wdWJsaWMtbmV3LXdvcmsvCgpPdGhlciB0aGFuIGNvbW1lbnRzIHNlbnQgaW4gZm9ybWFs IHJlc3BvbnNlcyBieSBXM0MgQWR2aXNvcnkKQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcywgVzND IGNhbm5vdCBndWFyYW50ZWUgYSByZXNwb25zZSB0bwpjb21tZW50cy4gSWYgeW91IHdvcmsgZm9y IGEgVzNDIE1lbWJlciBbMV0sIHBsZWFzZSBjb29yZGluYXRlCnlvdXIgY29tbWVudHMgd2l0aCB5 b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZS4gRm9yCmV4YW1wbGUsIHlvdSBt YXkgd2lzaCB0byBtYWtlIHB1YmxpYyBjb21tZW50cyB2aWEgdGhpcyBsaXN0IGFuZApoYXZlIHlv dXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlIHJlZmVyIHRvIGl0IGZyb20gaGlz Cm9yIGhlciBmb3JtYWwgcmV2aWV3IGNvbW1lbnRzLgoKVGhlIGN1cnJlbnQgSFRNTCBXb3JraW5n IEdyb3VwIGNoYXJ0ZXIgaXMgaGVyZWJ5IGV4dGVuZGVkIHVudGlsCjMwIEp1bmUgMjAyMi4gVGhp cyBleHRlbnNpb24gd2lsbCBnaXZlIFczQyBhZGRpdGlvbmFsIHRpbWUgZm9yIHRoZQpBZHZpc29y eSBDb21taXR0ZWUgcmV2aWV3LgpodHRwczovL3d3dy53My5vcmcvMjAyMC8xMi9odG1sLXdnLWNo YXJ0ZXIuaHRtbAoKSWYgeW91IHNob3VsZCBoYXZlIGFueSBxdWVzdGlvbnMgb3IgbmVlZCBmdXJ0 aGVyIGluZm9ybWF0aW9uLCBwbGVhc2UKY29udGFjdCBNaWNoYWVsIFNtaXRoIDxtaWtlQHczLm9y Zz4gYW5kIFhpYW9xaWFuIFd1IDx4aWFvcWlhbkB3My5vcmc+LApIVE1MIFdHIFRlYW0gQ29udGFj dHMuCgpUaGFuayB5b3UsCgpYdWV5dWFuIEppYSzCoCBXM0MgTWFya2V0aW5nICYgQ29tbXVuaWNh dGlvbnMKClswXSAKaHR0cHM6Ly93d3cudGltZWFuZGRhdGUuY29tL3dvcmxkY2xvY2svZml4ZWR0 aW1lLmh0bWw/aXNvPTIwMjIwNTIyVDIzNTkmcDE9NDMKWzFdIGh0dHBzOi8vd3d3LnczLm9yZy9D b25zb3J0aXVtL01lbWJlci9MaXN0CgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCm5ldy13b3JrIG1haWxpbmcgbGlzdApuZXctd29ya0BpZXRmLm9yZwpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldy13b3JrCg== From nobody Thu Apr 14 16:40:10 2022 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 925DE3A0E00 for ; Thu, 14 Apr 2022 16:40:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <164997960157.2619.13586754780059415629@ietfa.amsl.com> Date: Thu, 14 Apr 2022 16:40:01 -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, 14 Apr 2022 23:40:09 -0000 Review instructions and related resources are at: https://trac.ietf.org/trac/sec/wiki/SecDirReview For telechat 2022-04-21 Reviewer LC end Draft Tina Tsou 2022-04-04 draft-ietf-raw-ldacs Loganaden Velvindron 2022-04-12 draft-ietf-lisp-vendor-lcaf Christopher Wood 2022-04-15 draft-ietf-cbor-file-magic Last calls: Reviewer LC end Draft Daniel Franke 2022-01-19 draft-ietf-pim-igmp-mld-extension Daniel Gillmor 2022-01-28 draft-ietf-rats-yang-tpm-charra Aanchal Malhotra 2022-02-03 draft-ietf-bfd-rfc9127-bis Aanchal Malhotra 2021-10-15 draft-ietf-kitten-tls-channel-bindings-for-tls13 Daniel Migault R2021-06-28 draft-ietf-ipwave-vehicular-networking Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Tirumaleswar Reddy.K 2022-04-07 draft-koster-rep Stefan Santesson 2022-04-07 draft-ietf-teep-otrp-over-http Stefan Santesson 2021-08-11 draft-ietf-bier-te-arch Melinda Shore 2022-04-08 draft-ietf-tls-subcerts Tina Tsou 2022-04-04 draft-ietf-raw-ldacs Loganaden Velvindron 2022-04-12 draft-ietf-lisp-vendor-lcaf Brian Weis 2021-08-19 draft-ietf-dnsop-svcb-https Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Christopher Wood 2022-04-15 draft-ietf-cbor-file-magic Liang Xia 2022-04-27 draft-ietf-idr-bgp-ls-sbfd-extensions Liang Xia 2021-03-17 draft-ietf-core-sid Early review requests: Reviewer Due Draft Stephen Farrell 2021-09-15 draft-ietf-ippm-ioam-direct-export Stephen Farrell 2021-06-21 draft-ietf-idr-bgpls-srv6-ext Tina Tsou 2021-08-25 draft-ietf-opsawg-sbom-access Loganaden Velvindron 2021-08-18 draft-ietf-taps-arch Brian Weis 2022-05-16 draft-ietf-ippm-capacity-protocol Next in the reviewer rotation: Klaas Wierenga Christopher Wood Liang Xia Dacheng Zhang Derek Atkins John Bradley Nancy Cam-Winget Shaun Cooley Alan DeKok Linda Dunbar From nobody Fri Apr 15 10:37:27 2022 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 5475B3A0B0D; Fri, 15 Apr 2022 10:36:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christopher Wood via Datatracker To: Cc: cbor@ietf.org, draft-ietf-cbor-file-magic.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <165004421223.2657.13933771758777228182@ietfa.amsl.com> Reply-To: Christopher Wood Date: Fri, 15 Apr 2022 10:36:52 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-cbor-file-magic-11 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, 15 Apr 2022 17:36:53 -0000 Reviewer: Christopher Wood Review result: Has Nits Section 2.1: The use of a sequence of four US-ASCII codes which are mnemonic to the protocol is encouraged, but not required. This seems like good advice. Including an example for one of the CBOR Protocols under development might be helpful. Section 2.2: The tag content of that tag is a second CBOR Tag that has been allocated to describe the specific Protocol involved, as described above. I'd replace "as described above" with an explicit reference to Section 2.1. Moreover, I might rephrase this to something like the following: The tag content of the outer tag is a second CBOR Tag whose number has been allocated to describe the specific Protocol involved, as described above. The tag content of this inner tag is the single CBOR data item. Section 2.3: Unlike 2.2, there's no accompanying example. I think it would improve readability if one were included, even though conceptually the wrapping mechanism is simple. Section 3.2: If only one item is ever expected in the file, the use of Labeled CBOR Sequence may present an implementation hurdle to programs that previously just read a single data item and used it. What stood out to me when reading this document is that the CBOR Sequence wrapper could (seemingly) be used for all use cases -- it just happens to be a little more complicated to implement when all one requires is a single data item and doesn't expected to be concatenating files (wrappers) together. However, the additional complexity seems pretty minimal. Would it be worth just dropping the Tag Wrapped variant entirely? At the very least, that would seem to not fracture parsing support, where some parsing programs expect a single wrapped Protocol data item in a file, whereas others might expect multiple. Encouraging the latter seems more generally useful, especially give the PEM certificate format example in Section 3. Section 3.3: If the Protocol expects to use other tags values at the top-level, then the use of the tag wrapped format may be easier to explain in the protocol description. I didn't quite follow this. In particular, the "top-level" for the Protocol is is the wrapped CBOR data item, right? That is, using the example from Section 2.2.1, the top-level is here: d9 d9f7 # tag(55799) da 63740070 # tag(1668546672) 81 # array(1) <----- top-level? But this text in Section 3.3 seems to suggest that the top-level is: d9 d9f7 # tag(55799) <----- suggested top-level da 63740070 # tag(1668546672) 81 # array(1) My understanding is that the Protocol's use of CBOR is entirely encapsulated by the wrappers, so I'm not sure I understand the guidance in this section. Clarification might be helpful, if only for me. =)