From nobody Tue Feb 1 07:32:05 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 2157A3A1312; Tue, 1 Feb 2022 07:31:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Phillip Hallam-Baker via Datatracker To: Cc: dns-privacy@ietf.org, draft-ietf-dprive-dnsoquic.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164372951108.32553.12601779903676632717@ietfa.amsl.com> Reply-To: Phillip Hallam-Baker Date: Tue, 01 Feb 2022 07:31:51 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-dprive-dnsoquic-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2022 15:31:51 -0000 Reviewer: Phillip Hallam-Baker Review result: Has Issues The draft addresses the longstanding problem of DNS using an insecure transport protocol in the way that it should have been addressed from the start - encrypting the UDP packets. It is an important and overdue addition to the network protocol stack. The approach to using QUIC is about as straightforward as is possible given the legacy infrastructure. One area that is likely to require attention that is not addressed is the interaction of DNS and PKI and DHCP in the context of WiFi roaming networks. The principled way to address this use case would be for WiFi networks requiring authentication and/or agreement to terms to advertise via a standardized interaction signaled through e.g. DHCP. But there being no such agreed standard, public WiFi access points engage in a wide variety of approaches to intercepting the user's attention. Many of these intercept DNS connections. Thus, the assumption that DNS is insecure is built into legacy systems. While the incoherence of existing infrastructure is outside the remit of this specification. Guidance to implementers on this point might help reduce the amount of additional incoherence generated. Just noting that this is an issue might spur folk to correct this situation. The security considerations section forwards to RFC7858. This specification is six years old and represents the state of knowledge before deployment of the specification. Further the scope of 7858 is stub-to-recursive traffic, the new draft discusses zone transfer which is far outside that scope. The document has a privacy considerations section but all of the text would normally come under the 'confidentiality' heading in security considerations. The distinction is helpful in some cases but does not appear to add much in this one. The section on traffic analysis states information can be gained from observing packet lengths. Given the sensitivity of DNS traffic to analysis, this seems like a significant oversight. Even if QUIC does not provide a convenient mechanism for doing this, it could easily be added within the DPRIVE binding. From nobody Tue Feb 1 10:05:17 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 9D1183A1886; Tue, 1 Feb 2022 10:05:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: Cc: draft-ietf-quic-manageability.all@ietf.org, last-call@ietf.org, quic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164373870457.6016.43082043298646216@ietfa.amsl.com> Reply-To: Barry Leiba Date: Tue, 01 Feb 2022 10:05:04 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-quic-manageability-14 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, 01 Feb 2022 18:05:05 -0000 Reviewer: Barry Leiba Review result: Has Nits Thanks for a clear, well-written document that was very easy to read. From a security point of view, there’s quite a bit of explanation about how encryption is negotiated, the different contexts before and after handshakes, and the like, and how all that makes any tampering discoverable. I appreciate having that explanation, and it all looks solid to me. As I went through it, I thought about whether QUIC-INVARIANTS, RFC 8999, should be a normative reference: it’s cited several times, and in places where it seems that the information might be critical to fully understanding this document. As I looked back and forth between this document and that one, I decided that it’s correctly classified as informative (the normative information is in QUIC-TRANSPORT), but I can see how another reviewer might fall on the other side of that. Just something to be aware of. I only have a few minor editorial suggestions: — Section 2.4 — The content of Initial packets is encrypted using Initial Secrets, which are derived from a per-version constant and the client's destination connection ID; they are therefore observable by any on- path device that knows the per-version constant and considered visible in this illustration. The content of QUIC Handshake packets are encrypted using keys established during the initial handshake exchange, and are therefore not visible. I found this a little hard to read, as I initially attached “considered visible” to the on-path device and thought the word “is” was missing. I now realize that it’s meant to connect to “they”, but then *that* makes me realize that “they” is wrong because it’s supposed to refer to the bit that’s encrypted, which is “the content of Initial packets”. While “packets” is plural, “the content” is singular and is used singularly above (“is encrypted”). Whoo. I suggest splitting it into two sentences, rather than using the semicolon, handling it this way, and making sure to refer to the content as singular: NEW The content of Initial packets is encrypted using Initial Secrets, which are derived from a per-version constant and the client's destination connection ID. That content is therefore observable by any on-path device that knows the per-version constant and is considered visible in this illustration. The content of QUIC Handshake packets is encrypted using keys established during the initial handshake exchange, and is therefore not visible. END — Section 2.6 — This allows rebinding of a connection after one of the endpoints experienced an address change - usually the client. Nit, to take or leave: “usually the client” is, strictly speaking, misplaced: “This allows rebinding of a connection after one of the endpoints - usually the client - has experienced an address change.” — Section 3.4.1 — Further, the client's Initial packet(s) may contain other frames, so the first bytes of each frame need to be checked to identify the frame type, and if needed skipped over it. The last phrase isn’t well formed grammatically. Are you talking about identifying frame types and skipping over frames that you’re not interested in? If so, maybe this works?: NEW Further, the client's Initial packet(s) may contain other frames, so the first bytes of each frame need to be checked to identify the frame type and determine which frames can be skipped over. END From nobody Tue Feb 1 10:50:40 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 A598E3A19EF; Tue, 1 Feb 2022 10:50:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Robert Sparks via Datatracker To: Cc: draft-ietf-sacm-coswid.all@ietf.org, last-call@ietf.org, sacm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164374142964.30506.5747811489693066422@ietfa.amsl.com> Reply-To: Robert Sparks Date: Tue, 01 Feb 2022 10:50:29 -0800 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-sacm-coswid-20 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, 01 Feb 2022 18:50:30 -0000 Reviewer: Robert Sparks Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is ready publication as a Proposed Standard RFC. Thanks for addressing my last call comments. I still think you are missing an opportunity to avoid real implementation and registry trouble by not further constraining the characters that can appear in a name that will be registered. NMTOKEN, especially as defined in the references you point to here, has a big expansion set. Do you really want someone to be able to register the name "'̀·_·-·_·́'"? (fwiw, that's b'\xcc\x80\xc2\xb7_\xc2\xb7-\xc2\xb7_\xc2\xb7\xcc\x81') ) From nobody Tue Feb 1 16:07:53 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 C16863A1715; Tue, 1 Feb 2022 16:07:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: Cc: babel@ietf.org, draft-ietf-babel-v4viav6.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164376046073.3024.11843958658714304588@ietfa.amsl.com> Reply-To: Tero Kivinen Date: Tue, 01 Feb 2022 16:07:40 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-babel-v4viav6-07 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, 02 Feb 2022 00:07:41 -0000 Reviewer: Tero Kivinen 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 specifies how to add extensions to Babel routing protocol so that it can route IPv4 packets over network core without IPv4 addresses. Its security considerations section do mention the fact that this feature might invalidate the assumptions made by the network administrators, and suggest packet filters to mitigate this issue. I think the current security considerations section covers issues caused by this extension. From nobody Wed Feb 2 15:23:17 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 A6CD53A0A30 for ; Wed, 2 Feb 2022 15:23:07 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.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 CsJaHwWOpi-I for ; Wed, 2 Feb 2022 15:23:03 -0800 (PST) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 2CE013A0A32 for ; Wed, 2 Feb 2022 15:23:03 -0800 (PST) Received: by mail-wr1-x434.google.com with SMTP id j16so1350209wrd.8 for ; Wed, 02 Feb 2022 15:23:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aKzS8bDKUNSjeY05xyzW3oFcM6X9eGknaM8+zBf8Qlg=; b=iefa8QpE41nD5XTzoOn58LN5WJljAbQq3imMULlW8u8Sp+rSyRrqMynIL2F372M2kY m3ZhLHYYm1G1VxpgkGQxsn1cVJYkdeWOK5Q4XHBJaoQrVq2htTXi+IdcMvdUqosH4CtB 2c7X+bK/SWHusqb/7c6XOJG/F/WHk4IgNaP9A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aKzS8bDKUNSjeY05xyzW3oFcM6X9eGknaM8+zBf8Qlg=; b=Srzf9NsijAlgSBX7jvSV6JgPbnJG9TFlcwzcrJW5/1/3SvzIQj587I32y0ZHQsCSqo QQzM16Ee/SOsNAflGXFqeuzlbkwAV3Sj0kh+PVuFy+PWXsPTeAf9XnkEhWLmE8e1g39D WfYmyMJvh8hxZU8pBv7aDL6lj2vS5PJLo9Vd6SCmlTQ1ln1f6gsQRylCeBnlFsK8oeJn B5VgvR7JgYISbHQHIgKsNnshEcl6VoMJao+HxmHDCyWgsa9DbX7MTuLpSto8/JTCa/d+ CXtkpgsxRRcDrmr1R9Nj7pmoYpGYnrj9995x70/N4x1JELBIIzPphyefDnLsT+6Cestj oBNQ== X-Gm-Message-State: AOAM533leSm+983QenBz/wP40wIMVGBQi91F9QkUGsuCnURisNo8SrN2 wfOBXs9kQnmUXCI2ZzAqfcsuRH8R1QyiN39JNBwnVA== X-Google-Smtp-Source: ABdhPJzazWwTcPNtSbfOaX9DQ4nGX501G+ZuTsLB9LzDFOXKoYEl0ZiI9skqteWe0aWnCBSEDcyCKV65SL4Jz9BG5RY= X-Received: by 2002:a5d:484b:: with SMTP id n11mr1973747wrs.528.1643844179679; Wed, 02 Feb 2022 15:22:59 -0800 (PST) MIME-Version: 1.0 References: <163760375473.4258.2594227295562861974@ietfa.amsl.com> In-Reply-To: From: Kyle Rose Date: Wed, 2 Feb 2022 18:22:48 -0500 Message-ID: To: "Mr. Jaehoon Paul Jeong" Cc: tom petch , secdir , "i2nsf@ietf.org" , Last Call , Patrick Lingga , skku-iotlab-members , JungSoo Park , Yunchul Choi Content-Type: multipart/alternative; boundary="00000000000065734f05d7114c2a" Archived-At: Subject: Re: [secdir] [I2nsf] Secdir last call review of draft-ietf-i2nsf-nsf-facing-interface-dm-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2022 23:23:08 -0000 --00000000000065734f05d7114c2a Content-Type: text/plain; charset="UTF-8" Apologies for the delay in responding, Paul. This addresses most of my concerns. I note that some new redundancy has been introduced since -16, notably for source-port/destination-port, which could be further consolidated according to the DRY principle ("don't repeat yourself"). It's probably worthwhile to scrub the entire ecosystem for this kind of redundancy, but I wouldn't say it's a blocker. Thanks, Kyle On Sat, Jan 22, 2022 at 8:55 AM Mr. Jaehoon Paul Jeong < jaehoon.paul@gmail.com> wrote: > Hi Kyle and Tom, > Here is the revision of I2NSF NSF-Facing Interface YANG Data Model Draft: > > https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-facing-interface-dm-17 > > I attach a revision letter to explain how Patrick and I have addressed > your comments. > > Thanks. > > Best Regards, > Paul > > > On Tue, Nov 23, 2021 at 2:57 AM Kyle Rose via Datatracker < > noreply@ietf.org> wrote: > >> Reviewer: Kyle Rose >> 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. >> >> I don't actually have a lot to say about this document from a security >> perspective: its purpose is to describe, using YANG, a data model >> intended as >> the basis for configuration schemas developed for implementations of the >> Interface to Network Security Functions (I2NSF) framework. Security >> considerations for the most part should be addressed in documents >> describing >> system architecture or normatively detailing how implementations are to >> make >> use of the data model described here. I'm not going to relitigate any such >> issues here. >> >> The main issues I found in this document are ones that I, as someone not >> terribly familiar with YANG, found troubling from a general engineering >> perspective. These are best illustrated by example: >> >> * Why are `ipvX-prefix`, `-range`, and (the misleadingly-named) >> `-address` >> defined here? These concepts are generic enough that they should be in >> modules >> of their own to minimize variation among data models and the errors that >> will >> inevitably result from capturing the same concept in slightly different >> ways >> that are not obvious to the user. * Overall, I have to imagine that much >> of >> the `nsfintf` data model is generic enough that it should be captured >> externally. For instance, `tcp-flags`, `port-range`, `flow-label`, >> `dscp`, >> etc. are generally useful elements of an abstract transport data model >> that >> they shouldn't be defined here, but rather incorporated from an external >> data >> model that is maintained by those in (for example) the transport area. >> >> Am I just commenting on the YANG ecosystem in general? If these are >> standard >> practices, then the overall ecosystem has major latent problems. Ideally, >> a >> particular YANG module seems like it should describe only those elements >> defined at a particular layer, in this case rules and actions, and use >> reference external modules for elements that are defined at lower layers. >> >> Also some nits: >> >> * `ipvX-address` describes a subspace of the global IPvX address space, >> not a >> single address. The name is going to cause problems. * The descriptions >> given >> are often (usually?) just restatements of the entity name. Example is >> `identity priority-by-order` described as "Identity for priority by >> order". >> The description should provide some value for the user beyond simply >> restating >> the name. * The headings in section 5 should be clearly labeled with the >> word >> "example", such as "Example Security Requirement 1". * IPv6 addresses in >> text >> MUST be represented in lowercase, according to RFC 5952 section 4.3. >> >> >> _______________________________________________ >> I2nsf mailing list >> I2nsf@ietf.org >> https://www.ietf.org/mailman/listinfo/i2nsf >> > --00000000000065734f05d7114c2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apo= logies for the delay in responding, Paul. This addresses most of my concern= s. I note that some new redundancy has been introduced since -16, notably f= or source-port/destination-port, which could be further consolidated accord= ing to the DRY principle ("don't repeat yourself"). It's = probably worthwhile to scrub the entire ecosystem for this kind of redundan= cy, but I wouldn't say it's a blocker.

Thanks,
Kyle

On Sat, Jan 22, 2022 at 8:55 AM Mr. Jaehoon P= aul Jeong <jaehoon.paul@gmail.= com> wrote:
Hi Kyle and Tom,
Here is the revision of I2NSF NSF-F= acing Interface YANG Data Model Draft:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-facing-inter= face-dm-17

I attach a revision letter to explain how Patrick and= I have addressed your comments.

Thanks.

Best Regards,
Pau= l


On Tue, Nov 23, 2021 at 2:57 AM Kyle Rose via Datatracker <noreply@ietf.org> = wrote:
Reviewer:= Kyle Rose
Review result: Has Issues

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.=C2=A0 Thes= e
comments were written primarily for the benefit of the security area direct= ors.
=C2=A0Document editors and WG chairs should treat these comments just like = any other
last call comments.

This document Has Issues.

I don't actually have a lot to say about this document from a security<= br> perspective: its purpose is to describe, using YANG, a data model intended = as
the basis for configuration schemas developed for implementations of the Interface to Network Security Functions (I2NSF) framework. Security
considerations for the most part should be addressed in documents describin= g
system architecture or normatively detailing how implementations are to mak= e
use of the data model described here. I'm not going to relitigate any s= uch
issues here.

The main issues I found in this document are ones that I, as someone not terribly familiar with YANG, found troubling from a general engineering
perspective. These are best illustrated by example:

=C2=A0* Why are `ipvX-prefix`, `-range`, and (the misleadingly-named) `-add= ress`
=C2=A0defined here? These concepts are generic enough that they should be i= n modules
=C2=A0of their own to minimize variation among data models and the errors t= hat will
=C2=A0inevitably result from capturing the same concept in slightly differe= nt ways
=C2=A0that are not obvious to the user. * Overall, I have to imagine that m= uch of
=C2=A0the `nsfintf` data model is generic enough that it should be captured=
=C2=A0externally. For instance, `tcp-flags`, `port-range`, `flow-label`, `d= scp`,
=C2=A0etc. are generally useful elements of an abstract transport data mode= l that
=C2=A0they shouldn't be defined here, but rather incorporated from an e= xternal data
=C2=A0model that is maintained by those in (for example) the transport area= .

Am I just commenting on the YANG ecosystem in general? If these are standar= d
practices, then the overall ecosystem has major latent problems. Ideally, a=
particular YANG module seems like it should describe only those elements defined at a particular layer, in this case rules and actions, and use
reference external modules for elements that are defined at lower layers.
Also some nits:

=C2=A0* `ipvX-address` describes a subspace of the global IPvX address spac= e, not a
=C2=A0single address. The name is going to cause problems. * The descriptio= ns given
=C2=A0are often (usually?) just restatements of the entity name. Example is=
=C2=A0`identity priority-by-order` described as "Identity for priority= by order".
=C2=A0The description should provide some value for the user beyond simply = restating
=C2=A0the name. * The headings in section 5 should be clearly labeled with = the word
=C2=A0"example", such as "Example Security Requirement 1&quo= t;. * IPv6 addresses in text
=C2=A0MUST be represented in lowercase, according to RFC 5952 section 4.3.<= br>

_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
--00000000000065734f05d7114c2a-- From nobody Wed Feb 2 16:28: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 E450B3A0E22; Wed, 2 Feb 2022 16:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.428 X-Spam-Level: X-Spam-Status: No, score=-0.428 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, T_HK_NAME_FM_MR_MRS=0.01, URIBL_BLOCKED=0.001, URI_DOTEDU=1.659] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-DZWXg5mC-H; Wed, 2 Feb 2022 16:28:36 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0648B3A0E24; Wed, 2 Feb 2022 16:28:35 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id q22so1494673ljh.7; Wed, 02 Feb 2022 16:28:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Wm99FhsrCk7M2ZQ6zldb1q8AATPAmMLJ/RoCogU5yp0=; b=gf7s4TROISf8uIAmcaGi4mpoIMyPr+/jzY/GslF9Lr9n+6Vu9oznoSu+WqzcxMlmev E3JzJ0drt+tUrxYX7A6FLBRdqiMBI8gTiWdIS3chIA6FsiIGNYmCzCgenxSSV8zKmCnb crJAvP14qcRUpJq/mlpCtMBHeqbtiLvw7upFY8uCivxXeMO4P9E2ZMwsJuGQBdeLikCF 31opVzTCZNcOv6wQC4L4xPNsU26RQIQ2peweVlVrI+Hmy2JVpDQ3UN+oD9zz7VQWWJfj 4wsJGxvEvVcx+FhRUBRdZTYznII1uKwTzjOzPg5wA8iWWapHpXqyF90BPBxNYmwcARbS jANQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Wm99FhsrCk7M2ZQ6zldb1q8AATPAmMLJ/RoCogU5yp0=; b=DWfkHunrCzAz3G5hYO+oxdItGwsu+ZwZcMBuznbuRRCz52A8wSOx15xxaiuHfgb0wr /b9HMhd7DVHoqZikp84JIeXqzAuc/dBFjiUd/PQVLU/dE1sTreTecoBp779alx6eUdLM +ThEj4QaA1l6pMetyX6egUwRnW9/1VavN8F9W0nRF8v+ZOsZFP85dSZnV7Dq0QgdkMZm OQU5Ub6q8mNYyEAMYpBqjugpdf+M6KBQ2OmbVwGfvJCS2rT+1qQQd3B5da04/8cEy8Ok IHY3CmfTIEEkvz8fviol8sySeZ1/HkrqH+mbWBpSIfumaGpJThiO2NFzBZgz1V+40chZ /2fA== X-Gm-Message-State: AOAM531x7ZLu+OINflXcapKR4eqI15P9dFljqjA6MgIvkEMlcCg31g2W GZCGD8i6TGo2gIV3R+RpnaXEvJZWWcTBB99sqzM= X-Google-Smtp-Source: ABdhPJzGor3/BQJzBhNhDZRy6DIy8NHflfIwFdNTfNvNtKRNGPnaIR4TutUGV+TV9mmYLh1y7hvUENViAXJTxbCv91o= X-Received: by 2002:a2e:8515:: with SMTP id j21mr20738741lji.496.1643848112587; Wed, 02 Feb 2022 16:28:32 -0800 (PST) MIME-Version: 1.0 References: <163760375473.4258.2594227295562861974@ietfa.amsl.com> In-Reply-To: From: "Mr. Jaehoon Paul Jeong" Date: Thu, 3 Feb 2022 09:28:21 +0900 Message-ID: To: Kyle Rose Cc: JungSoo Park , Last Call , "Mr. Jaehoon Paul Jeong" , Patrick Lingga , Yunchul Choi , "i2nsf@ietf.org" , secdir , skku-iotlab-members , tom petch Content-Type: multipart/alternative; boundary="000000000000d0c87005d712368b" Archived-At: Subject: Re: [secdir] [I2nsf] Secdir last call review of draft-ietf-i2nsf-nsf-facing-interface-dm-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2022 00:28:41 -0000 --000000000000d0c87005d712368b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Kyle, No problem:-) I will address your comments to remove the redundancy. Thanks. Best Regards, Paul 2022=EB=85=84 2=EC=9B=94 3=EC=9D=BC (=EB=AA=A9) =EC=98=A4=EC=A0=84 8:23, Ky= le Rose =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > Apologies for the delay in responding, Paul. This addresses most of my > concerns. I note that some new redundancy has been introduced since -16, > notably for source-port/destination-port, which could be further > consolidated according to the DRY principle ("don't repeat yourself"). It= 's > probably worthwhile to scrub the entire ecosystem for this kind of > redundancy, but I wouldn't say it's a blocker. > > Thanks, > Kyle > > On Sat, Jan 22, 2022 at 8:55 AM Mr. Jaehoon Paul Jeong < > jaehoon.paul@gmail.com> wrote: > >> Hi Kyle and Tom, >> Here is the revision of I2NSF NSF-Facing Interface YANG Data Model Draft= : >> >> https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-facing-interf= ace-dm-17 >> >> I attach a revision letter to explain how Patrick and I have addressed >> your comments. >> >> Thanks. >> >> Best Regards, >> Paul >> >> >> On Tue, Nov 23, 2021 at 2:57 AM Kyle Rose via Datatracker < >> noreply@ietf.org> wrote: >> >>> Reviewer: Kyle Rose >>> 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. >>> >>> I don't actually have a lot to say about this document from a security >>> perspective: its purpose is to describe, using YANG, a data model >>> intended as >>> the basis for configuration schemas developed for implementations of th= e >>> Interface to Network Security Functions (I2NSF) framework. Security >>> considerations for the most part should be addressed in documents >>> describing >>> system architecture or normatively detailing how implementations are to >>> make >>> use of the data model described here. I'm not going to relitigate any >>> such >>> issues here. >>> >>> The main issues I found in this document are ones that I, as someone no= t >>> terribly familiar with YANG, found troubling from a general engineering >>> perspective. These are best illustrated by example: >>> >>> * Why are `ipvX-prefix`, `-range`, and (the misleadingly-named) >>> `-address` >>> defined here? These concepts are generic enough that they should be in >>> modules >>> of their own to minimize variation among data models and the errors >>> that will >>> inevitably result from capturing the same concept in slightly differen= t >>> ways >>> that are not obvious to the user. * Overall, I have to imagine that >>> much of >>> the `nsfintf` data model is generic enough that it should be captured >>> externally. For instance, `tcp-flags`, `port-range`, `flow-label`, >>> `dscp`, >>> etc. are generally useful elements of an abstract transport data model >>> that >>> they shouldn't be defined here, but rather incorporated from an >>> external data >>> model that is maintained by those in (for example) the transport area. >>> >>> Am I just commenting on the YANG ecosystem in general? If these are >>> standard >>> practices, then the overall ecosystem has major latent problems. >>> Ideally, a >>> particular YANG module seems like it should describe only those element= s >>> defined at a particular layer, in this case rules and actions, and use >>> reference external modules for elements that are defined at lower layer= s. >>> >>> Also some nits: >>> >>> * `ipvX-address` describes a subspace of the global IPvX address space= , >>> not a >>> single address. The name is going to cause problems. * The description= s >>> given >>> are often (usually?) just restatements of the entity name. Example is >>> `identity priority-by-order` described as "Identity for priority by >>> order". >>> The description should provide some value for the user beyond simply >>> restating >>> the name. * The headings in section 5 should be clearly labeled with >>> the word >>> "example", such as "Example Security Requirement 1". * IPv6 addresses >>> in text >>> MUST be represented in lowercase, according to RFC 5952 section 4.3. >>> >>> >>> _______________________________________________ >>> I2nsf mailing list >>> I2nsf@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2nsf >>> >> -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department Head Department of Computer Science and Engineering Sungkyunkwan University Office: +82-31-299-4957 Email: pauljeong@skku.edu, jaehoon.paul@gmail.com Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --000000000000d0c87005d712368b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Kyle,
No problem:-)

I will address your comments to rem= ove the redundancy.

Than= ks.

Best Regards,
<= div dir=3D"auto">Paul

2022=EB=85=84 2=EC=9B=94 3=EC=9D=BC (=EB=AA=A9) = =EC=98=A4=EC=A0=84 8:23, Kyle Rose <k= rose@krose.org>=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1:
Apologies for the delay in responding, Paul. This ad= dresses most of my concerns. I note that some new redundancy has been intro= duced since -16, notably for source-port/destination-port, which could be f= urther consolidated according to the DRY principle ("don't repeat = yourself"). It's probably worthwhile to scrub the entire ecosystem= for this kind of redundancy, but I wouldn't say it's a blocker.

Thanks,
Kyle

On Sat, Jan 22, 2022= at 8:55 AM Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> wrote:
Hi Kyle and = Tom,
Here is the revision of I2NSF NSF-Facing Interface YANG Data Model = Draft:
https://datatracker.ietf.org= /doc/html/draft-ietf-i2nsf-nsf-facing-interface-dm-17

I attach a= revision letter to explain how Patrick and I have addressed your comments.=

Thanks.

Best Regards,
Paul


On Tue, Nov 23, 2021 at= 2:57 AM Kyle Rose via Datatracker <noreply@ietf.org> wrote:
Reviewer: Kyle Rose
Review result: Has Issues

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.=C2=A0 Thes= e
comments were written primarily for the benefit of the security area direct= ors.
=C2=A0Document editors and WG chairs should treat these comments just like = any other
last call comments.

This document Has Issues.

I don't actually have a lot to say about this document from a security<= br> perspective: its purpose is to describe, using YANG, a data model intended = as
the basis for configuration schemas developed for implementations of the Interface to Network Security Functions (I2NSF) framework. Security
considerations for the most part should be addressed in documents describin= g
system architecture or normatively detailing how implementations are to mak= e
use of the data model described here. I'm not going to relitigate any s= uch
issues here.

The main issues I found in this document are ones that I, as someone not terribly familiar with YANG, found troubling from a general engineering
perspective. These are best illustrated by example:

=C2=A0* Why are `ipvX-prefix`, `-range`, and (the misleadingly-named) `-add= ress`
=C2=A0defined here? These concepts are generic enough that they should be i= n modules
=C2=A0of their own to minimize variation among data models and the errors t= hat will
=C2=A0inevitably result from capturing the same concept in slightly differe= nt ways
=C2=A0that are not obvious to the user. * Overall, I have to imagine that m= uch of
=C2=A0the `nsfintf` data model is generic enough that it should be captured=
=C2=A0externally. For instance, `tcp-flags`, `port-range`, `flow-label`, `d= scp`,
=C2=A0etc. are generally useful elements of an abstract transport data mode= l that
=C2=A0they shouldn't be defined here, but rather incorporated from an e= xternal data
=C2=A0model that is maintained by those in (for example) the transport area= .

Am I just commenting on the YANG ecosystem in general? If these are standar= d
practices, then the overall ecosystem has major latent problems. Ideally, a=
particular YANG module seems like it should describe only those elements defined at a particular layer, in this case rules and actions, and use
reference external modules for elements that are defined at lower layers.
Also some nits:

=C2=A0* `ipvX-address` describes a subspace of the global IPvX address spac= e, not a
=C2=A0single address. The name is going to cause problems. * The descriptio= ns given
=C2=A0are often (usually?) just restatements of the entity name. Example is=
=C2=A0`identity priority-by-order` described as "Identity for priority= by order".
=C2=A0The description should provide some value for the user beyond simply = restating
=C2=A0the name. * The headings in section 5 should be clearly labeled with = the word
=C2=A0"example", such as "Example Security Requirement 1&quo= t;. * IPv6 addresses in text
=C2=A0MUST be represented in lowercase, according to RFC 5952 section 4.3.<= br>

_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
--
<= div>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) J= eong, Ph.D.
Associate Professor
Department HeadDepartment of Computer Science and Engineering
Sungkyunkwan University<= br>Office: +82-31-299-4957
Email: pauljeong@skku.edu,=C2=A0<= a href=3D"mailto:jaehoon.paul@gmail.com" target=3D"_blank">jaehoon.paul@gma= il.com
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-j= eong.php
--000000000000d0c87005d712368b-- From nobody Wed Feb 2 17:59:43 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 4D1763A1332; Wed, 2 Feb 2022 17:59:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Melinda Shore via Datatracker To: Cc: draft-ietf-i2nsf-nsf-monitoring-data-model.all@ietf.org, i2nsf@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164385357525.26801.14820753791536440390@ietfa.amsl.com> Reply-To: Melinda Shore Date: Wed, 02 Feb 2022 17:59:35 -0800 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-i2nsf-nsf-monitoring-data-model-14 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, 03 Feb 2022 01:59:36 -0000 Reviewer: Melinda Shore Review result: Ready Thank you for the updated draft. This revision is written much more clearly and there are other changes, such as the one to the dampening-type, that I think reduce the likelihood of implementation errors. I still think a few words about the limitations of relying on transport security would strengthen the security considerations but I do think the document is ready to go. From nobody Thu Feb 3 11:24:54 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 384E13A1687 for ; Thu, 3 Feb 2022 11:24:53 -0800 (PST) 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.44.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <164391629234.21066.307967180546765994@ietfa.amsl.com> Date: Thu, 03 Feb 2022 11:24:53 -0800 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, 03 Feb 2022 19:24:53 -0000 Review instructions and related resources are at: https://trac.ietf.org/trac/sec/wiki/SecDirReview For telechat 2022-02-03 Reviewer LC end Draft Alan DeKok 2021-12-30 draft-ietf-sidrops-6486bis Daniel Franke 2022-01-19 draft-ietf-pim-igmp-mld-extension Steve Hanna 2022-01-24 draft-ietf-dots-telemetry For telechat 2022-02-17 Reviewer LC end Draft Catherine Meadows R2021-10-28 draft-ietf-calext-ical-relations Alexey Melnikov 2021-11-23 draft-ietf-i2nsf-nsf-facing-interface-dm Klaas Wierenga R2021-08-30 draft-ietf-alto-cdni-request-routing-alto For telechat 2022-03-03 Reviewer LC end Draft Daniel Gillmor 2022-01-28 draft-ietf-rats-yang-tpm-charra Samuel Weiler R2021-08-25 draft-ietf-alto-path-vector Brian Weis 2021-08-19 draft-ietf-dnsop-svcb-https 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 Steve Hanna 2022-01-24 draft-ietf-dots-telemetry Scott Kelly 2022-02-09 draft-ietf-ecrit-similar-location Chris Lonvick 2022-02-07 draft-ietf-quic-applicability Aanchal Malhotra 2022-02-03 draft-ietf-bfd-rfc9127-bis Aanchal Malhotra 2021-10-15 draft-ietf-kitten-tls-channel-bindings-for-tls13 Catherine Meadows R2021-10-28 draft-ietf-calext-ical-relations Alexey Melnikov 2021-11-23 draft-ietf-i2nsf-nsf-facing-interface-dm Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Kyle Rose 2022-03-02 draft-faltstrom-base45 Stefan Santesson 2021-08-11 draft-ietf-bier-te-arch Mališa Vučinić 2021-12-13 draft-ietf-anima-asa-guidelines Samuel Weiler R2021-08-25 draft-ietf-alto-path-vector Brian Weis 2021-08-19 draft-ietf-dnsop-svcb-https Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Klaas Wierenga R2021-08-30 draft-ietf-alto-cdni-request-routing-alto Liang Xia 2021-09-07 draft-ietf-bess-evpn-igmp-mld-proxy 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 Christopher Wood 2021-12-20 draft-ietf-opsawg-mud-iot-dns-considerations Next in the reviewer rotation: Daniel Migault Adam Montville Kathleen Moriarty Russ Mundy Sandra Murphy Yoav Nir Magnus Nystrom Hilarie Orman Radia Perlman Derrell Piper From nobody Thu Feb 3 19:13:24 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 088743A1943; Thu, 3 Feb 2022 19:13:14 -0800 (PST) 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 LBPh0gOayqu1; Thu, 3 Feb 2022 19:13:12 -0800 (PST) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 2A9153A1942; Thu, 3 Feb 2022 19:13:12 -0800 (PST) Received: by mail-ej1-x62a.google.com with SMTP id s5so14979225ejx.2; Thu, 03 Feb 2022 19:13:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5iSrh5wJ0p+Z1UaCMI7QglgOgiQsONJ4wMXlipkAklY=; b=npvBHUK2dmrLmNZSfwstGiwWi/bpZ3Gcf67EkhVdLHFWjAgaShjmZkcKwwmnQ87NWf TfRIRlMJ62gffzxVMqv41GmX0kzTXqJtCUVtymCf8XMiarRqOiYGNDTO4byWHcq4Epjz m4BPFIPtDAV9liN0YDsh/6Vt5ybUp+FSlDUeXd8fzoAFfkwJ8PgLQaNSfHvTIl+mVJxH Ms26HF1vz3Bp0RzbYvo4rz6lziTZlOGd8vcfDbZDDQeCWLtwevHIwlbOcLqrbvag2A+s y3YVVGCFm4L2KG0cJEP+Lk/Rhi0tOsi6JXtqg969i8kZgSklsOaByPZHQAe1y3TFHePZ dXIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5iSrh5wJ0p+Z1UaCMI7QglgOgiQsONJ4wMXlipkAklY=; b=xr6P7i8mG5gce+GQXou5ENhbHMR0VW3iVrs9U04wx6rw5DT0Y2c94W1PG8nDKl3r8E H6PK9oQYXd5M6hc6iwQa5VYPKSiJnKqQbRlSIaduaMyxmHE13H4h/ejBuMStqeKXyctp VxibsxBjONPKE6ZM0YnBy0wKylnLtMGfgTg0UtT+Cy9+6fEybZNv2qJrDRzRPK0m2KSW bb8zQ0wMhMxMHPQ2U6wltUjNcqtezlF4RC3D5MMfrkZ9bhdxrwESwl56hnw6D/lk28wa imRR0BZmH/EY2EVNy7h9OI0NMVXtgMByPcRgxAiCJXZ7NDbLzX6eOST8Ht9V07rjttTb m8mQ== X-Gm-Message-State: AOAM533rSfEoWKcGYwxtwnc5kdik2ww5HkXlln8mTfkwK2A4FwiSE9x/ xkpo1fctuZ/E0uao9T+1jVX1VyNtTdsW6Ema4eTDI2Un X-Google-Smtp-Source: ABdhPJxGLdgJqmh9eozWP4mVGYD6B6Y8KvvryhE5+2nBuMW8pYwn+7eCNlchk0Bv9Ps4qMJU8pQsZZn8xvtae+W0htU= X-Received: by 2002:a17:907:6da1:: with SMTP id sb33mr760971ejc.18.1643944386967; Thu, 03 Feb 2022 19:13:06 -0800 (PST) MIME-Version: 1.0 References: <164372951108.32553.12601779903676632717@ietfa.amsl.com> In-Reply-To: <164372951108.32553.12601779903676632717@ietfa.amsl.com> From: Allison Mankin Date: Thu, 3 Feb 2022 22:12:56 -0500 Message-ID: To: Phillip Hallam-Baker Cc: dns-privacy@ietf.org, draft-ietf-dprive-dnsoquic.all@ietf.org, last-call@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary="000000000000373a4b05d728a18e" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dprive-dnsoquic-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2022 03:13:14 -0000 --000000000000373a4b05d728a18e Content-Type: text/plain; charset="UTF-8" Hi Phillip, We appreciate the timely and thorough review. It would be helpful if you could give us some suggested texts that you would want to see. Best wishes, Allison On Tue, Feb 1, 2022 at 10:31 Phillip Hallam-Baker via Datatracker < noreply@ietf.org> wrote: > Reviewer: Phillip Hallam-Baker > Review result: Has Issues > > The draft addresses the longstanding problem of DNS using an insecure > transport > protocol in the way that it should have been addressed from the start - > encrypting the UDP packets. It is an important and overdue addition to the > network protocol stack. > > The approach to using QUIC is about as straightforward as is possible > given the > legacy infrastructure. One area that is likely to require attention that > is not > addressed is the interaction of DNS and PKI and DHCP in the context of WiFi > roaming networks. > > The principled way to address this use case would be for WiFi networks > requiring authentication and/or agreement to terms to advertise via a > standardized interaction signaled through e.g. DHCP. But there being no > such > agreed standard, public WiFi access points engage in a wide variety of > approaches to intercepting the user's attention. Many of these intercept > DNS > connections. Thus, the assumption that DNS is insecure is built into legacy > systems. > > While the incoherence of existing infrastructure is outside the remit of > this > specification. Guidance to implementers on this point might help reduce the > amount of additional incoherence generated. Just noting that this is an > issue > might spur folk to correct this situation. > > The security considerations section forwards to RFC7858. This > specification is > six years old and represents the state of knowledge before deployment of > the > specification. Further the scope of 7858 is stub-to-recursive traffic, the > new > draft discusses zone transfer which is far outside that scope. > > The document has a privacy considerations section but all of the text would > normally come under the 'confidentiality' heading in security > considerations. > The distinction is helpful in some cases but does not appear to add much in > this one. > > The section on traffic analysis states information can be gained from > observing > packet lengths. Given the sensitivity of DNS traffic to analysis, this > seems > like a significant oversight. Even if QUIC does not provide a convenient > mechanism for doing this, it could easily be added within the DPRIVE > binding. > > > --000000000000373a4b05d728a18e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Phillip,

We appreciate the timely and thorough review. It would be helpful if = you could give us some suggested texts that you would want to see.=C2=A0

Best wishes,

Allison


On Tue, Feb 1, 2022 at 10:31 Phillip Hallam-Baker via Datatracker <noreply@ietf.org> wrote:
=
Reviewer: Phillip Hallam-Baker
Review result: Has Issues

The draft addresses the longstanding problem of DNS using an insecure trans= port
protocol in the way that it should have been addressed from the start -
encrypting the UDP packets. It is an important and overdue addition to the<= br> network protocol stack.

The approach to using QUIC is about as straightforward as is possible given= the
legacy infrastructure. One area that is likely to require attention that is= not
addressed is the interaction of DNS and PKI and DHCP in the context of WiFi=
roaming networks.

The principled way to address this use case would be for WiFi networks
requiring authentication and/or agreement to terms to advertise via a
standardized interaction signaled through e.g. DHCP. But there being no suc= h
agreed standard, public WiFi access points engage in a wide variety of
approaches to intercepting the user's attention. Many of these intercep= t DNS
connections. Thus, the assumption that DNS is insecure is built into legacy=
systems.

While the incoherence of existing infrastructure is outside the remit of th= is
specification. Guidance to implementers on this point might help reduce the=
amount of additional incoherence generated. Just noting that this is an iss= ue
might spur folk to correct this situation.

The security considerations section forwards to RFC7858. This specification= is
six years old and represents the state of knowledge before deployment of th= e
specification. Further the scope of 7858 is stub-to-recursive traffic, the = new
draft discusses zone transfer which is far outside that scope.

The document has a privacy considerations section but all of the text would=
normally come under the 'confidentiality' heading in security consi= derations.
The distinction is helpful in some cases but does not appear to add much in=
this one.

The section on traffic analysis states information can be gained from obser= ving
packet lengths. Given the sensitivity of DNS traffic to analysis, this seem= s
like a significant oversight. Even if QUIC does not provide a convenient mechanism for doing this, it could easily be added within the DPRIVE bindin= g.


--000000000000373a4b05d728a18e-- From nobody Fri Feb 4 11:21:20 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 2E91A3A2059; Fri, 4 Feb 2022 11:19:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1644002357; bh=3XE7xi4SGOuk/dv2eaElIMEXTGsVVoYvSFnPMorxcGo=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=TJpMp0kGL/kTlXhu/HiAvWruEr4H17C5qFAWJuWoh1ecLF6i3TrMBqD1HmdL5iSbu Dp2B4t0xMNKlEIPq/sZ+ve/FIi0oLaYrdrlziu57XAe7SkYcilxvYJ7HFgfkfMn9zQ hflOrKKrjuGSF4rcF8VPNmcajygFcAxrrniS8jj8= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Feb 4 11:19:09 2022 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FFC3A2053; Fri, 4 Feb 2022 11:19:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1644002340; bh=3XE7xi4SGOuk/dv2eaElIMEXTGsVVoYvSFnPMorxcGo=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=W0dP7JFZOigapjx7FVSPKVuPUlvjdkcfvAEzbKlp7y73ngmuvlHGkhF6ph15R4IGH HmCwxO9JW+S1WiJaGKQEwhy8ZGJRtRzJadhZtUQb0/icYPHR7B+6h4up8vd6ySBruu 81pg5LuCHZLeNiwZH7iCbRDn1IYJBAwAWxhOG2Jo= 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 52CE53A202A for ; Fri, 4 Feb 2022 11:18:53 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <164400233331.5527.201757335390537663@ietfa.amsl.com> Date: Fri, 04 Feb 2022 11:18:53 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Reply-To: iesg@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 04 Feb 2022 11:21:18 -0800 Subject: [secdir] [new-work] WG Review: Calendaring Extensions (calext) 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, 04 Feb 2022 19:19:27 -0000 The Calendaring Extensions (calext) WG in the Applications and Real-Time Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2022-02-14. Calendaring Extensions (calext) ----------------------------------------------------------------------- Current status: Active WG Chairs: Daniel Migault Bron Gondwana Assigned Area Director: Francesca Palombini Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Mailing list: Address: calsify@ietf.org To subscribe: http://www.ietf.org/mailman/listinfo/calsify Archive: https://mailarchive.ietf.org/arch/browse/calsify/ Group page: https://datatracker.ietf.org/group/calext/ Charter: https://datatracker.ietf.org/doc/charter-ietf-calext/ The CALEXT working group is chartered to maintain and extend the specifications for formats and protocols related to calendaring and contacts within the IETF, starting from the basis of: - CalDAV (RFC 4791) - iCalendar (RFC 5545) - iTIP (RFC 5546) - iMIP (RFC 6047) - VCARD (RFC 6350) - CardDAV (RFC 6352) - JSCalendar (RFC 8984) - JSContact (draft-ietf-jmap-jscontact) and the many existing extensions and companion documents to these. This working group is envisaged to be long-running, and deal with a steady slow flow of changes. Experience has shown that these specifications are still seeing significant need for updates, as new use-cases are identified and user requirements change. This working group will do the following: - maintain existing standards and proposed standards, processing errata and refreshing them as required - evaluate and develop extensions to the existing standards to provide for new use-cases where there is demand - generate documents describing existing vendor extensions which are in common usage, and likely to be encountered in the wild. The working group will work under the following parameters: - The extensions developed are expected to be backwards-compatible with the existing standards. Incompatibilities must be identified, minimized, and justified. - Any extensions to icalendar or jscalendar must include a representation in both formats, and define a robust mapping between them. - Any extensions to vcard or jscontact must include a representation in both formats, and define a robust mapping between them. - All calendar extensions must examine their impact on the iTIP protocol (RFC 5546), and define any necessary extensions to iTIP to accommodate such impact. The working group will maintain relationships with other working groups: - HTTPBIS and HTTPAPI: when extending the CalDAV or CardDAV protocols to ensure that changes are consistent with good http practices. - JMAP: when making updates to JSCalendar and JSContact to ensure that the changes are compatible with the JMAP methods for managing data in these formats. - EXTRA, DMARC and EMAILCORE: for changes related to iTIP delivery via email. - TZDIST and SEDATE for date, time, and timezone related issues. - Other IETF working groups as appropriate, when their work interacts with ours. - Other standards organisations like CalConnect and M3AAWG that are doing work in the same fields. The following are out of scope for the working group: - Any attempt to develop non-Gregorian calendar systems/calculations. - Work which is in scope for any other ART area working group, and better suited to that group. - Work which is unrelated to anything that this group is currently maintaining. Milestones: Jan 2022 - Submit Subscription Upgrade document to IESG for publication Jan 2022 - Submit task draft to IESG Apr 2022 - Submit JSCalendar mapping document to IESG for publication Apr 2022 - Submit JSON Contact document to IESG Jun 2022 - Submit vpoll document to IESG for publication Jun 2022 - Submit Serverside Subscription draft to IESG for publication Jul 2022 - Submit calendar series document to IESG for publication _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Mon Feb 7 11:02:11 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 AC3B13A110D; Mon, 7 Feb 2022 10:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1644259534; bh=wJMH9HppVFDJdnf/GH8w//Fn5IPnv0RrpqqipoVJ2og=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=tdCBqRf8tSV4Ixrkycfa6bcMzROa69NXTm+NaEDc6AyGh85/R4VONFVUpzEYkrolJ EmuEON0ppx3tbZnoKc8/+NIWCwgLZM7o/SIlp6xL0GPy+ayk+VVQJvEoyx31m74+j3 7IapBP9FRGB4Ni6esujE5oV6lXokc4vjrSFwrGEE= X-Mailbox-Line: From new-work-bounces@ietf.org Mon Feb 7 10:45:34 2022 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D6BF23A10DD; Mon, 7 Feb 2022 10:45:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1644259533; bh=wJMH9HppVFDJdnf/GH8w//Fn5IPnv0RrpqqipoVJ2og=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=FCuWxNFR4R6a8VgKKCBAov/tTtSNtgtCFM0kzXmBA9HOuPTwA39xHCXzBWuzxowy6 qX/gU9pujEjICmS/xOsPxkUZMwfcGuvbpPvy3xS/RuAxBfsNNndKBYm8UYqHflantQ ykurkHm+Pu0L2htd43mqEPaw5Z2xhFOaY+5H7P0I= 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 0F8083A0B3E for ; Mon, 7 Feb 2022 10:45:30 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <164425953003.28802.300796683417546148@ietfa.amsl.com> Date: Mon, 07 Feb 2022 10:45:30 -0800 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: Mon, 07 Feb 2022 11:02:10 -0800 Subject: [secdir] [new-work] WG Review: Stay Home Meet Only Online (shmoo) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2022 18:45:38 -0000 VGhlIFN0YXkgSG9tZSBNZWV0IE9ubHkgT25saW5lIChzaG1vbykgV0cgaW4gdGhlIEdlbmVyYWwg QXJlYSBvZiB0aGUgSUVURiBpcwp1bmRlcmdvaW5nIHJlY2hhcnRlcmluZy4gVGhlIElFU0cgaGFz IG5vdCBtYWRlIGFueSBkZXRlcm1pbmF0aW9uIHlldC4gVGhlCmZvbGxvd2luZyBkcmFmdCBjaGFy dGVyIHdhcyBzdWJtaXR0ZWQsIGFuZCBpcyBwcm92aWRlZCBmb3IgaW5mb3JtYXRpb25hbApwdXJw b3NlcyBvbmx5LiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBJRVNHIG1haWxpbmcg bGlzdAooaWVzZ0BpZXRmLm9yZykgYnkgMjAyMi0wMi0xNy4KClN0YXkgSG9tZSBNZWV0IE9ubHkg T25saW5lIChzaG1vbykKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KQ3VycmVudCBzdGF0dXM6IEFjdGl2ZSBXRwoK Q2hhaXJzOgogIFN1cmVzaCBLcmlzaG5hbiA8c3VyZXNoLmtyaXNobmFuQGdtYWlsLmNvbT4KICBN YWxsb3J5IEtub2RlbCA8bWtub2RlbEBjZHQub3JnPgoKQXNzaWduZWQgQXJlYSBEaXJlY3RvcjoK ICBMYXJzIEVnZ2VydCA8bGFyc0BlZ2dlcnQub3JnPgoKR2VuZXJhbCBBcmVhIERpcmVjdG9yczoK ICBMYXJzIEVnZ2VydCA8bGFyc0BlZ2dlcnQub3JnPgoKTWFpbGluZyBsaXN0OgogIEFkZHJlc3M6 IG1hbnljb3VjaGVzQGlldGYub3JnCiAgVG8gc3Vic2NyaWJlOiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21hbnljb3VjaGVzCiAgQXJjaGl2ZTogaHR0cHM6Ly9tYWlsYXJj aGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9tYW55Y291Y2hlcy8KCkdyb3VwIHBhZ2U6IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZ3JvdXAvc2htb28vCgpDaGFydGVyOiBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9jaGFydGVyLWlldGYtc2htb28vCgpTdGF5IEhvbWUgTWVl dCBPY2Nhc2lvbmFsbHkgT25saW5lIChzaG1vbykKClRoZSBkaXNydXB0aW9ucyBjYXVzZWQgYnkg dGhlIENPVklELTE5IHBhbmRlbWljIG1heSBoYXZlIGJlZW4gbWl0aWdhdGVkIGJ5IHRoZQp0aW1l IHRoaXMgZ3JvdXAgY29tcGxldGVzIGl0cyB3b3JrLCBidXQgdGhlIGV4cGVyaWVuY2Ugb2YgaGFu ZGxpbmcgbWVldGluZwpwbGFubmluZyBkdXJpbmcgdGhlIHBhbmRlbWljIGhhcyBwcm92ZW4gdGhh dCBoYXZpbmcgY29tbXVuaXR5IGNvbnNlbnN1cwpndWlkYW5jZSBhdCBoYW5kIHdoZW4gZGVhbGlu ZyB3aXRoIG5vdmVsIGNvbmRpdGlvbnMgaW4gdGhlIGZ1dHVyZSBpcwpiZW5lZmljaWFsLgoKVGhl IGRpc3J1cHRpb24gb2YgdGhlIElFVEYncyB0eXBpY2FsIHNjaGVkdWxlIG9mIHRocmVlIG1vc3Rs eS1pbi1wZXJzb24KbWVldGluZ3MgcGVyIHllYXIsIGlzIGNhdXNpbmcgaXQgdG8gY29udmVydCBh IG51bWJlciBvZiBzdWNoIG1lZXRpbmdzIHRvCmZ1bGx5IG9ubGluZSBtZWV0aW5ncy4gWWV0IGRp c2N1c3Npb25zIGFib3V0IHRoZSBwb3NzaWJpbGl0eSBvZiBmdWxseSBvcgptb3N0bHkgb25saW5l IG1lZXRpbmdzIGhhZCBiZWVuIG9jY3VycmluZyBpbiB0aGUgSUVURiBjb21tdW5pdHkgZm9yIHll YXJzIGFzCmEgcmVzdWx0IG9mIGdlbmVyYWwgaW5jcmVhc2VzIGluIHJlbW90ZSBhdHRlbmRhbmNl LCBpbXByb3ZlbWVudHMgaW4gd2ViCmNvbmZlcmVuY2luZyBzZXJ2aWNlcywgY29uY2VybnMgYWJv dXQgdGhlIGVudmlyb25tZW50YWwgaW1wYWN0IG9mIHRyYXZlbCwgYW5kCm90aGVyIHJlYXNvbnMu IEl0IG1pZ2h0IHRoZXJlZm9yZSBoYXBwZW4gdGhhdCBpbi1wZXJzb24gbWVldGluZyBwYXJ0aWNp cGF0aW9uCndpbGwgYmVjb21lIGxlc3MgcG9wdWxhciBhbmQgdGhhdCBhIHNpZ25pZmljYW50IGZy YWN0aW9uIG9mICBwYXJ0aWNpcGFudHMKd2lsbCBiZSByZW1vdGUuCgpUaGUgbWVldGluZyBwbGFu bmluZyBhY3Rpdml0aWVzIHRoYXQgdGhlIElFU0cgYW5kIHRoZSBJRVRGIExMQyBlbmdhZ2UgaW4g d291bGQKYmVuZWZpdCBmcm9tIElFVEYgY29tbXVuaXR5IGNvbnNlbnN1cyBndWlkYW5jZSBjb25j ZXJuaW5nIG5vdmVsIGFzcGVjdHMgcmFpc2VkCmJ5IHRoZXNlIGRldmVsb3BtZW50cy4gVGhlIFNI TU9PIHdvcmtpbmcgZ3JvdXAgaXMgdGhlcmVmb3JlIGNoYXJ0ZXJlZCB0bwpkb2N1bWVudCBoaWdo LWxldmVsIGd1aWRhbmNlIGFuZCBwcmluY2lwbGVzIHRvIHRoZSBJRVNHIGFuZCB0aGUgSUVURiBM TEMuCgpUaGUgZ3VpZGFuY2UgYW5kIHByaW5jaXBsZXMgd2lsbCBjb25jZXJuIHRoZSBmb2xsb3dp bmc6CgotIE1lZXRpbmcgcGxhbm5pbmcgZm9yIGZ1bGx5IG9ubGluZSBtZWV0aW5ncy4gU2ltaWxh ciB0byBob3cgUkZDIDg3MTkKICBlc3RhYmxpc2hlcyBndWlkYW5jZSBmb3IgdGhlIHJlZ2lvbmFs IHJvdGF0aW9uIG9mIGluLXBlcnNvbiBtZWV0aW5ncywgdGhlCiAgSUVTRyBhbmQgdGhlIExMQyB3 b3VsZCBiZW5lZml0IGZyb20gaGF2aW5nIGNvbW11bml0eSBjb25zZW5zdXMgZ3VpZGVsaW5lcwog IGFib3V0IHRoZSB0aW1lIHpvbmUgc2VsZWN0aW9uLCBtZWV0aW5nIGxlbmd0aCBpbiBkYXlzLCBh bmQgb3RoZXIgaGlnaC1sZXZlbAogIHNjaGVkdWxpbmcgYXNwZWN0cyB3aGVuIGFuIGluLXBlcnNv biBtZWV0aW5nIG11c3QgYmUgY2FuY2VsZWQuIFRoaXMgd29yawogIGl0ZW0gaXMgZXhwZWN0ZWQg dG8gYmUgZnVsZmlsbGVkIHdpdGggdGhlIHB1YmxpY2F0aW9uIG9mIG9uZSBvciBtb3JlIEJDUHMu CgotIE1lZXRpbmcgcGxhbm5pbmcgZm9yIG1vc3RseSBvbmxpbmUsIG9yIOKAnGh5YnJpZCzigJ0g bWVldGluZ3MuIE1lZXRpbmdzIHRoYXQKaGF2ZQogIGFuIGluLXBlcnNvbiBjb21wb25lbnQgYnV0 IHdpdGggc2lnbmlmaWNhbnRseSBtb3JlIHJlbW90ZSBwYXJ0aWNpcGFudHMgdGhhbgogIGEgbW9z dGx5LWluLXBlcnNvbiBtZWV0aW5nIG5lZWQgdG8gYmUgcGxhbm5lZCB3aXRoIGNvbW11bml0eSBj b25zZW5zdXMKICBndWlkZWxpbmVzLCB0b28uIFdoaWxlIHRyYWRlLW9mZnMgaGF2ZSBvZnRlbiBi ZWVuIGFkZHJlc3NlZCBpbiBmYXZvciBvZgogIG9uc2l0ZSBhdHRlbmRlZXMsIHRoZSBJRVNHIGFu ZCBMTEMgd291bGQgYmVuZWZpdCBmcm9tIGhhdmluZyBjb21tdW5pdHkKICBjb25zZW5zdXMgb24g aGlnaC1sZXZlbCBndWlkYW5jZSBhYm91dCB0aGUgb3JnYW5pemF0aW9uIG9mIHN1Y2ggaHlicmlk CiAgbWVldGluZ3MsIHJlZ2FyZGluZyBzdWNoIHRoaW5ncyBhcyB0aGUgbWVldGluZyBzY2hlZHVs ZSwgdGhlIG1lZXRpbmcgbGVuZ3RoCiAgaW4gZGF5cywgYW5kIGFjY2VwdGFibGUgbGltaXRhdGlv bnMgb24gdGhlIG1heGltdW0gYWxsb3dlZCBvciBtaW5pbXVtCiAgZXhwZWN0ZWQgb25zaXRlIGF0 dGVuZGVlcywgd2hldGhlciBhbmQgaG93IHRvIHNjaGVkdWxlIGFuZCBwcmlvcml0aXplIGFtb25n CiAgb25zaXRlIGFjdGl2aXRpZXMgc3VjaCBhcyBzaWRlIG1lZXRpbmdzLCB0aGUgdGVybWluYWwg cm9vbSwgdGhlIGNvZGUKICBsb3VuZ2UsIGFuZCBvdGhlcnMsIGFuZCBvdGhlciBzY2hlZHVsaW5n IGFzcGVjdHMuCgotIERldGVybWluYXRpb25zIGFib3V0IHRoZSBtZWV0aW5nIGZlZSBzdHJ1Y3R1 cmUgZm9yIHJlbW90ZSBwYXJ0aWNpcGF0aW9uLgpTaW5jZQogIHJlbW90ZSBwYXJ0aWNpcGF0aW9u IGluIG1vc3RseS1pbi1wZXJzb24gbWVldGluZ3MgaGFzIGhpc3RvcmljYWxseSBiZWVuCiAgZnJl ZSwgSUVURiBMTEMgYW5kIElFU0cgZGVjaXNpb25zIGFib3V0IHRoZSBtZWV0aW5nIGZlZSBzdHJ1 Y3R1cmUgZm9yCiAgcmVtb3RlIHBhcnRpY2lwYXRpb24gbmVlZCB0byBiZSBpbmZvcm1lZCBieSBj b21tdW5pdHkgZ3VpZGVsaW5lcy4gVGhpcyB3b3JrCiAgaXRlbSBpcyBleHBlY3RlZCB0byBiZSBm dWxmaWxsZWQgd2l0aCB0aGUgcHVibGljYXRpb24gb2Ygb25lIG9yIG1vcmUgQkNQcy4KICBTdWdn ZXN0aW9ucyBmb3IgY2hhbmdpbmcgdGhlIElFVEYncyBvdmVyYWxsIGZ1bmRpbmcgbW9kZWwgYXJl IG91dCBvZiBzY29wZS4KCi0gVGhlIGNhZGVuY2Ugb2YgbWVldGluZyBzY2hlZHVsaW5nIGFuZCB0 aGUgbWl4IG9mIG1vc3RseS1pbi1wZXJzb24sIGh5YnJpZAphbmQKICBmdWxseSBvbmxpbmUgbWVl dGluZ3MgZ29pbmcgZm9yd2FyZCBhcyB3ZWxsIGFzIHRoZSBmb3JtYXQgb2YgbWVldGluZ3MsIGUu Zy4sCiAgdXNlIG9mIGludGVyaW1zIGNvbXBhcmVkIHRvIGNvbXBvbmVudHMgYW5kIGxlbmd0aCBv ZiB0aGUgcGxlbmFyeSBtZWV0aW5nCiAgKHdlZWspLiBUaGUgd29ya2luZyBncm91cCBpcyBleHBl Y3RlZCB0byBkb2N1bWVudCB0aGUgZXhwZWN0ZWQgZnV0dXJlCiAgbWVldGluZyBjYWRlbmNlIGFu ZCBmb3JtYXQgYXMgYSBCQ1AgaWYgY29uc2Vuc3VzIGVtZXJnZXMgdG8gZGVwYXJ0IGZyb20gdGhl CiAgZXhpc3RpbmcgY2FkZW5jZSBvZiB0aHJlZSBtb3N0bHktaW4tcGVyc29uIG1lZXRpbmdzIHBl ciB5ZWFyLiBOb3RhYmx5LCBhbnkKICBzdWNoIGd1aWRhbmNlIHdpbGwgbm90IGJlY29tZSBhY3Rp b25hYmxlIHVudGlsIDMtNCB5ZWFycyBhZnRlciBpdCBhY2hpZXZlcwogIGNvbnNlbnN1cywgZ2l2 ZW4gdGhlIGxlbmd0aCBvZiB0aGUgSUVURiBtZWV0aW5nIHBsYW5uaW5nIGN5Y2xlLgoKVGhlIHdv cmsgb2YgU0hNT08gaXMgZXhwZWN0ZWQgdG8gcHJvZHVjZSBoaWdoLWxldmVsIHByaW5jaXBsZXMs IG5vdCBkZXRhaWxlZApvcGVyYXRpb25hbCBwbGFucy4gVGhlIGdvYWwgaXMgdG8gcHJvZHVjZSBn dWlkZWxpbmVzIGZvciB0aGUgSUVTRyBhbmQgdGhlIElFVEYKTExDIHRvIG9wZXJhdGlvbmFsaXpl IHdoaWxlIGVuc3VyaW5nIHRoZXkgaGF2ZSBzdWJzdGFudGlhbCBmbGV4aWJpbGl0eSB0bwpjb250 aW51ZSB0byBkZWxpdmVyIGFuZCBldm9sdmUgdGhlIElFVEYgbWVldGluZyBleHBlcmllbmNlIHRv IGJlc3Qgc2VydmUgSUVURgpwYXJ0aWNpcGFudHMgYW5kIHRoZSBJbnRlcm5ldCBjb21tdW5pdHkg YXQgbGFyZ2UuIFNwZWNpZmljYXRpb25zIG9mIGRldGFpbHMKY29uY2VybmluZyBjYW5jZWxsYXRp b24gY3JpdGVyaWEsIG1lZXRpbmcgdGVjaG5vbG9naWVzLCBhbmQgb25saW5lIG1lZXRpbmcKYWdl bmRhIGZvcm1hdHMgYW5kIGNvbnRlbnQgYXJlIG91dCBvZiBzY29wZS4gQXNpZGUgZnJvbSB0aGUg Zm91cnRoIHdvcmsgaXRlbQphYm92ZSwgZGlzY3Vzc2lvbiBvZiBmaW5hbmNpYWwgYXNwZWN0cyBv ZiBJRVRGIG1lZXRpbmdzIGFuZCBjaGFuZ2VzIHRvIFJGQwo4NzEzIGFyZSBib3RoIG91dCBvZiBz Y29wZS4gU2NoZWR1bGluZyBndWlkYW5jZSBmb3IgaW50ZXJpbSBtZWV0aW5ncyBpcyBvdXQKb2Yg c2NvcGUuCgpNaWxlc3RvbmVzOgoKVEJECgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwpuZXctd29yayBtYWlsaW5nIGxpc3QKbmV3LXdvcmtAaWV0Zi5vcmcK aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXctd29yawo= From nobody Mon Feb 7 14:27:01 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 06EA43A0DFF; Mon, 7 Feb 2022 14:27:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Kyle Rose via Datatracker To: Cc: draft-faltstrom-base45.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164427281988.3952.13973206934475684325@ietfa.amsl.com> Reply-To: Kyle Rose Date: Mon, 07 Feb 2022 14:26:59 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-faltstrom-base45-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: Mon, 07 Feb 2022 22:27:00 -0000 Reviewer: Kyle Rose 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 one Issue. Technically, the described protocol is Ready primarily because it describes an existing encoding standardized in ISO/IEC 18004. That said, I can't really help but ask a few things about this encoding: * Why 45? (This is probably really a question for the people who designed QR codes.) 45^3 = 91125 >> 2^16, which means roughly 30% of strings with length divisible by 3 comprising base45 characters are invalid encodings. * Why is Space included as a character? This renders the encoding fragile in many string handling contexts. * Base64 requires padding only to comply with the spec as-written: a minor modification of the spec (let's call it base64') could lose the padding and still produce unambiguous encodings of both content and length: going from 64 to 45 doesn't have anything to do with remedying this. And, by contrast with base45, 64^4=256^3, which means all strings with length divisible by 4 comprising base64 characters would be valid base64' encodings. But the real issue I have with the document (and one that might be technically unavoidable, depending how ISO/IEC 18004 is worded) is that an actual covert channel isn't addressed at all: that of the remaining insignificant bits in encodings of odd-length strings (a problem that would similarly impact base64' from above for encodings of strings with length mod 3 !≅ 0). Taking the example from section 4.4, the final chunk ([33 0]) in the example comes from the 16-bit value 33 (= 33 + 0 * 45). But all that is needed is that 33 ≅ X mod 256 unless the decoder enforces that encodings of length not divisible by 3 have 16-bit values < 256. For example, QED8WEJ6 ultimately decodes to the string "ietf!", or to "ietf!1", or not at all, depending on the behavior of the decoder: ignore non-zero second octet in odd-length strings (quite likely), render it based on the available data (unlikely because, if not special-cased, would result in decoding "ietf!0" in the example from the document), or reject the encoding. The last option is the only valid thing to do from a security perspective. Grammar nit: "For example, it MUST the encoded data" From nobody Wed Feb 9 06:46:13 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 F01283A0A33 for ; Wed, 9 Feb 2022 06:46:07 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trammell.ch 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 hAASXjaHUdHr for ; Wed, 9 Feb 2022 06:46:03 -0800 (PST) Received: from smtp-42aa.mail.infomaniak.ch (smtp-42aa.mail.infomaniak.ch [84.16.66.170]) (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 D284A3A0A0D for ; Wed, 9 Feb 2022 06:46:01 -0800 (PST) Received: from smtp-2-0000.mail.infomaniak.ch (unknown [10.5.36.107]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4Jv2kH1fcVzMq4sY; Wed, 9 Feb 2022 15:45:59 +0100 (CET) Received: from smtpclient.apple (unknown [IPv6:2a00:79e0:42:206:f801:e1d5:3249:f154]) by smtp-2-0000.mail.infomaniak.ch (Postfix) with ESMTPA id 4Jv2kH05ydzlhSM9; Wed, 9 Feb 2022 15:45:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=trammell.ch; s=20191114; t=1644417959; bh=l/kz0Spi/jAz1WkMSEgJ4OvozzoP0cIzgsE1HhCYL08=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=OWXJJnrVIILFT3z8KVjMhoJeIQLhdcKbrA5grHTT/xCdN0CbYwwUlZDzN5X9J4DCt ngfXeJPkRqGFtvHjQ+sN7tJ8Zt/RB2fVEdRWspb9uXYs5roRU9hx+fVAY8vKAUdvX6 LFyH+MntOGLpib+VV0PUK/WpqCvaFrbENZTLhx/o= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) From: "Brian Trammell (IETF)" In-Reply-To: <164373870457.6016.43082043298646216@ietfa.amsl.com> Date: Wed, 9 Feb 2022 15:45:58 +0100 Cc: secdir@ietf.org, draft-ietf-quic-manageability.all@ietf.org, last-call@ietf.org, quic@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <164373870457.6016.43082043298646216@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.3693.60.0.1.1) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-quic-manageability-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: Wed, 09 Feb 2022 14:46:09 -0000 hi Barry, Many thanks for the review! We've incorporated the editorial changes in = https://github.com/quicwg/ops-drafts/pull/450 Cheers, Brian > On 1 Feb 2022, at 19:05, Barry Leiba via Datatracker = wrote: >=20 > Reviewer: Barry Leiba > Review result: Has Nits >=20 > Thanks for a clear, well-written document that was very easy to read. = =46rom a > security point of view, there=E2=80=99s quite a bit of explanation = about how encryption > is negotiated, the different contexts before and after handshakes, and = the > like, and how all that makes any tampering discoverable. I appreciate = having > that explanation, and it all looks solid to me. >=20 > As I went through it, I thought about whether QUIC-INVARIANTS, RFC = 8999, should > be a normative reference: it=E2=80=99s cited several times, and in = places where it > seems that the information might be critical to fully understanding = this > document. As I looked back and forth between this document and that = one, I > decided that it=E2=80=99s correctly classified as informative (the = normative > information is in QUIC-TRANSPORT), but I can see how another reviewer = might > fall on the other side of that. Just something to be aware of. >=20 > I only have a few minor editorial suggestions: >=20 > =E2=80=94 Section 2.4 =E2=80=94 >=20 > The content of Initial packets is encrypted using Initial Secrets, > which are derived from a per-version constant and the client's > destination connection ID; they are therefore observable by any on- > path device that knows the per-version constant and considered > visible in this illustration. The content of QUIC Handshake packets > are encrypted using keys established during the initial handshake > exchange, and are therefore not visible. >=20 > I found this a little hard to read, as I initially attached = =E2=80=9Cconsidered > visible=E2=80=9D to the on-path device and thought the word =E2=80=9Cis=E2= =80=9D was missing. I now > realize that it=E2=80=99s meant to connect to =E2=80=9Cthey=E2=80=9D, = but then *that* makes me realize > that =E2=80=9Cthey=E2=80=9D is wrong because it=E2=80=99s supposed to = refer to the bit that=E2=80=99s > encrypted, which is =E2=80=9Cthe content of Initial packets=E2=80=9D. = While =E2=80=9Cpackets=E2=80=9D is > plural, =E2=80=9Cthe content=E2=80=9D is singular and is used = singularly above (=E2=80=9Cis > encrypted=E2=80=9D). Whoo. >=20 > I suggest splitting it into two sentences, rather than using the = semicolon, > handling it this way, and making sure to refer to the content as = singular: >=20 > NEW > The content of Initial packets is encrypted using Initial Secrets, > which are derived from a per-version constant and the client's > destination connection ID. That content is therefore observable by > any on-path device that knows the per-version constant and is > considered visible in this illustration. The content of QUIC > Handshake packets is encrypted using keys established during the > initial handshake exchange, and is therefore not visible. > END >=20 > =E2=80=94 Section 2.6 =E2=80=94 >=20 > This > allows rebinding of a connection after one of the endpoints > experienced an address change - usually the client. >=20 > Nit, to take or leave: =E2=80=9Cusually the client=E2=80=9D is, = strictly speaking, misplaced: > =E2=80=9CThis allows rebinding of a connection after one of the = endpoints - usually the > client - has experienced an address change.=E2=80=9D >=20 > =E2=80=94 Section 3.4.1 =E2=80=94 >=20 > Further, > the client's Initial packet(s) may contain other frames, so the = first > bytes of each frame need to be checked to identify the frame type, > and if needed skipped over it. >=20 > The last phrase isn=E2=80=99t well formed grammatically. Are you = talking about > identifying frame types and skipping over frames that you=E2=80=99re = not interested in? > If so, maybe this works?: >=20 > NEW > Further, > the client's Initial packet(s) may contain other frames, so the = first > bytes of each frame need to be checked to identify the frame type = and > determine which frames can be skipped over. > END >=20 >=20 From nobody Wed Feb 9 09:18:40 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 507DA3A09C1; Wed, 9 Feb 2022 09:18:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Catherine Meadows via Datatracker To: Cc: calsify@ietf.org, draft-ietf-calext-ical-relations.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164442710515.4563.6397829591254976677@ietfa.amsl.com> Reply-To: Catherine Meadows Date: Wed, 09 Feb 2022 09:18:25 -0800 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-calext-ical-relations-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: Wed, 09 Feb 2022 17:18:26 -0000 Reviewer: Catherine Meadows Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready with nits. This draft describes an update of the iCalendar RELATED-TO property, introducing new properties LINK, CONCEPT, and REFID. In particular, RELATED-TO only allowed the value type TEXT. Depending on the property draft extends the allowed value types to include URI and UID, and REFERENCE, where REFERENCE is a URI with a pointer to a fragment of XML code. The Security Considerations Section correctly points out that the security impact of the new/expanded properties is in the new data types URI and REFERENCE they can return, and the fact that they may point to external sources which may vanish or be replaced. This is supplemented with reference to the security considerations in the appropriate RFC’s. My only concern with the previous draft was that the risks of values of type REFERENCE were not addressed. This has now been taken care of. Nits: In the definition of REFERENCE, “it's use as an anchor” should be “its use as an anchor”. From nobody Wed Feb 9 10:32:58 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 AB1683A0B6D; Wed, 9 Feb 2022 06:42:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1644417727; bh=OaAqzlN58o8oTkFLBPXPdRdxeGszParyci6dbjFgGVw=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=wiJpGkLj7B9jbysCCxG1j5XWQDhh0yEd+05e3akEVljIDhRW+vntvxuenRrnslEtl VDDi8iAia2inv0K0Zrt8EXXFbt1R7O7//hl8xUyo8IVN3J4bEJwtcFR2Ds7pTgyFUs 3/b8rj0yGMd93InK8k+E5WyRVmr2n96QK4mrcwBk= X-Mailbox-Line: From new-work-bounces@ietf.org Wed Feb 9 06:42:03 2022 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7297A3A0A71; Wed, 9 Feb 2022 06:41:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1644417718; bh=OaAqzlN58o8oTkFLBPXPdRdxeGszParyci6dbjFgGVw=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=SKYvlPHW18W38NtAqAiYqv6Olv6XqpFePod+jRCvbJ9ldNSm4+PqYS0t05P5DvpFW Q/Vzbmv8KTKdZSfK2GpEWfi1iOkMvscFE5U8LWy2ZV4xL1tOcIHiv1BKXWHc6OxEPG GwwRvyBkPnOmd6NipjfZv6gQnhUHhGizAZokZXyQ= 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 B85113A0A0A for ; Wed, 9 Feb 2022 06:41:50 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <164441771073.16388.593736281864587013@ietfa.amsl.com> Date: Wed, 09 Feb 2022 06:41:50 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Reply-To: iesg@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Wed, 09 Feb 2022 10:32:57 -0800 Subject: [secdir] [new-work] WG Review: Privacy Preserving Measurement (ppm) 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, 09 Feb 2022 14:42:14 -0000 A new IETF WG has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2022-02-16. Privacy Preserving Measurement (ppm) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Benjamin Schwartz Assigned Area Director: Roman Danyliw Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: ppm@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/ppm Archive: https://mailarchive.ietf.org/arch/browse/ppm/ Group page: https://datatracker.ietf.org/group/ppm/ Charter: https://datatracker.ietf.org/doc/charter-ietf-ppm/ There are many situations in which it is desirable to take measurements of data which people consider sensitive. For instance, a browser company might want to measure web sites that do not render properly without learning which users visit those sites, or a public health authority might want to measure exposure to some disease without learning the identities of those exposed. In these cases, the entity taking the measurement is not interested in people's individual responses but rather in aggregated data (e.g., how many users had errors on site X). Conventional methods require collecting individual measurements in plaintext and then aggregating them, thus representing a threat to user privacy and rendering many such measurements difficult and impractical. New cryptographic techniques address this gap through a variety of techniques, all of which aim to ensure that the server (or multiple, non-colluding servers) can compute the aggregated value without learning the value of individual measurements. The Privacy Preserving Measurement (PPM) work will standardize protocols for deployment of these techniques on the Internet. This will include mechanisms for: - Client submission of individual measurements, potentially along with proofs of validity - Verification of validity proofs by the server(s), if sent by client - Computation of aggregate values by the server(s) and reporting of results to the entity taking the measurement A successful PPM system assumes that clients and servers are configured with each other's identities and details of the types of measurements to be taken. This is assumed to happen out of band and will not be standardized in this WG. The WG will deliver one or more protocols which can accommodate multiple PPM algorithms. The initial deliverables will support the calculation of simple predefined statistical aggregates such as averages, as well as calculations of the values that most frequently appear in individual measurements. The PPM protocols will use cryptographic algorithms and protocols defined by the CFRG to enable privacy-preserving properties. The protocol will be designed to limit abuse by both client and server, including exposure of individual user measurements and denial of service attacks on the measurement system. The resulting document(s) shall consider deployment contexts, and clearly describe abuse cases and remaining attacks which are not prevented or mitigated by the protocol(s). The starting point for PPM WG discussions shall be draft-gpew-priv-ppm. Milestones: Dec 2023 - Submit PPM protocol to IESG for publication _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Wed Feb 9 10:33:05 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 6020E3A0BD4; Wed, 9 Feb 2022 10:28:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1644431283; bh=94n449Ej8dzGS4wh6lv4/XNgxc6JOy2QjMUSS4MUF+Q=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=zbJDubceu6RQkGnoUx1jzhM3iuacnl5jE+Q7WUWonOmJuuOaaza/6CSAFfuARLaNh wrfRSr0wjHzZuC6BaRh8puXbInJK92n6HrTop5D21Kxbg84O8ql3a53+yGbrQmAi7j kYH1gv7+RSpnPixNmrHn0CAPqg9mpn6QnSHbnNh8= X-Mailbox-Line: From new-work-bounces@ietf.org Wed Feb 9 10:28:02 2022 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 683293A0BEC; Wed, 9 Feb 2022 10:28:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1644431282; bh=94n449Ej8dzGS4wh6lv4/XNgxc6JOy2QjMUSS4MUF+Q=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=ZSVn/l2ZYzbhCSqnnWSAectdZu2HP1viys49lWsswB7T0hGYGoidwpGB6XltOuQ7Z Y5nacTrbwCfNPa9mRRNBG08PFDxDkVAdQuzGeVKbRObKEhID+3hgPf5ZKLcgs5S/tf fJfUneaaXpf06cOjhegK7q8dNCB9Xkeh5mu5/sCo= 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 DCAEA3A0BEC for ; Wed, 9 Feb 2022 10:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=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 Ycbnqy90jwZp for ; Wed, 9 Feb 2022 10:27:54 -0800 (PST) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 7DDBC3A0BEB for ; Wed, 9 Feb 2022 10:27:54 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id r14so2600872qtt.5 for ; Wed, 09 Feb 2022 10:27:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:mime-version:thread-index :content-language; bh=OJ1HpfWN+GJDqYCJw+/IsqppkGJ/1zhUhYrD+sPnYIA=; b=TRiVIWznFjXqS14zphIwarPdbi4QvHIImthtCXc+/05wNuJjMxNB0JC+FKSDqzzgpD wVlZIijbJphnP+/DZjjj8w803tdmg1Zrz51MTyqfI+v1u6ATEXsZMWge3g6l4nQZd8wQ n6A+u9FHj1NcxvCROy9bY1TCGYSk84ebACnaogYwE1aF2IfLCjorCmV+ptx3VBPk8x9f bcuWdCRka7+b6Hs0il7GbAZuigwS3LPQ9CBGwYHOQhW3LcN5s9CuhI/bW6t+B5BaJjDU oCtsRRUsDu81IJj44POQ85R/VFTPKTkACMjw9m8sYwilOFbEkvx14s6T2Hnny1x4XVVM mEgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :thread-index:content-language; bh=OJ1HpfWN+GJDqYCJw+/IsqppkGJ/1zhUhYrD+sPnYIA=; b=74tRRGA4IURs3zzZVbc3yfDnhNw9ImHYbnGBtthhZQteyEzaTQ2kHZ9RqV5pzR+q9w LaneEO+9afpNKR00VcoJgb1Gf434Gr2NQi6w5SfQIxo5Jxpe460FIF4yzpfU8detxtrg AEbA69+VsXJNwIanKJw1Zs5/2BqFvkhbtaIO7r7ac1ZhF3r6DABhqxZnW6EeQhG1tGYN oyoFT7KL8EhnrQuRVZRa5gkO1im3nhr4jNRTGXKrzAFR6Y0EJ24I3jCvaiCsui1+pG09 FJMgr8gf/9kBmGfhNB9OpuYUyKaJniHpC3jaYKxrXiC4t8uzcl2nI9lkQ53iXHqzdnlF h6fA== X-Gm-Message-State: AOAM531QCudnpI964UbwZv0+zavh78gAlics90RBSWwsK3MKST0KXXpe 1E7LR+MnL5J0dFcfvHaqVjQ= X-Google-Smtp-Source: ABdhPJxRbyNsJF/FhZ/4z3fhB1VlwiNUM2JqvLEs8lsukuDm1TGlgCQz1l/2SZcF6jYqcn1aatevnA== X-Received: by 2002:ac8:5d8c:: with SMTP id d12mr2309611qtx.4.1644431272220; Wed, 09 Feb 2022 10:27:52 -0800 (PST) Received: from DESKTOP6VF5FH7 (pool-96-249-149-147.hrbgpa.fios.verizon.net. [96.249.149.147]) by smtp.gmail.com with ESMTPSA id k13sm9438851qko.45.2022.02.09.10.27.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Feb 2022 10:27:51 -0800 (PST) From: To: Date: Wed, 9 Feb 2022 13:27:49 -0500 Message-ID: <069601d81de2$bf054e40$3d0feac0$@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: Adgd4U1PEJTADi5CT2aGpMH57oYC/A== Content-Language: en-us Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Cc: "'Stanley, Dorothy'" , Paul Nikolich Content-Type: multipart/mixed; boundary="===============7475983096685488694==" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Wed, 09 Feb 2022 10:32:57 -0800 Subject: [secdir] [new-work] IEEE 802 PARs under consideration: Mar 2022 Plenary 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, 09 Feb 2022 18:28:05 -0000 This is a multipart message in MIME format. --===============7475983096685488694== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0697_01D81DB8.D62F4640" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0697_01D81DB8.D62F4640 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, The following Project Authorization Requests (PARs) and ICAID will be considered at the IEEE 802 Mar 2022 Plenary, which will be held electronically - * 802-Rev - Standard - Overview and Architecture, PAR Revision * 802.1Qdt - Amendment: Priority-based Flow Control Enhancements, PAR and CSD * 802.1DU - Standard for Cut-Through Forwarding Bridges and Bridged Networks, PAR and CSD * 802.3dg - Amendment: Physical Layer Specifications and Management Parameters for 100Mb/s Operation and Associated Power Delivery over a Single Balanced Pair of Conductors, PAR and CSD * 802.15.12 - Standard for Enhanced Ultra Wide-Band (UWB) Physical Layers (PHYs) and Associated MAC Enhancements, PAR Withdrawal * 802.15.6a - Amendment: Dependable Human and Vehicle Body Area Networks, PAR Withdrawal and CSD * 802.15.6ma - Standard - Wireless Body Area Networks, PAR Revision and CSD The PARs and ICAID can be found at http://www.ieee802.org/PARs.shtml along with the supporting IEEE 802 Criteria for Standards Development, or CSD, (which includes the 5 criteria, i.e. the explanations of how they fit the IEEE 802 criteria for initiating new work). Any comments on a proposed PAR / ICAID should be sent to the Working Group chair identified on the respective document to be received by 09 Mar 2022, AoE. Regards, John D'Ambrosia Recording Secretary, IEEE 802 LMSC ------=_NextPart_000_0697_01D81DB8.D62F4640 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IEEE 802 PARs under consideration: Mar 2022 Plenary

All,

The = following Project Authorization Requests (PARs) and ICAID will be = considered at the IEEE 802 Mar 2022 Plenary, which will be = held electronically –  

·       802-Rev - Standard - Overview and = Architecture, PAR = Revision

·       802.1Qdt - Amendment: = Priority-based Flow Control Enhancements, PAR = and CSD

·       802.1DU - Standard for = Cut-Through Forwarding Bridges and Bridged Networks, PAR = and CSD

·       802.3dg - Amendment: Physical = Layer Specifications and Management Parameters for 100Mb/s Operation and = Associated Power Delivery over a Single Balanced Pair of = Conductors, PAR = and CSD

·       802.15.12 - Standard for Enhanced = Ultra Wide-Band (UWB) Physical Layers (PHYs) and Associated MAC = Enhancements, PAR Withdrawal

·       802.15.6a - Amendment: Dependable = Human and Vehicle Body Area Networks, = PAR Withdrawal = and CSD

·       802.15.6ma - Standard -  = Wireless Body Area Networks, = PAR Revision = and CSD

The = PARs and ICAID can be found at http://www.ieee802.org/PARs.shtml along with the = supporting IEEE 802 Criteria for Standards Development, or CSD, (which = includes the 5 criteria, i.e. the explanations of how they fit the IEEE = 802 criteria for initiating new work).

Any = comments on a proposed PAR / ICAID should be sent to the Working Group = chair identified on the respective document to be received = by = 09 Mar 2022, AoE.

Regards,

John = D’Ambrosia

Recording Secretary, IEEE 802 LMSC =

------=_NextPart_000_0697_01D81DB8.D62F4640-- --===============7475983096685488694== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============7475983096685488694==-- From nobody Thu Feb 10 13:12:04 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 576173A11BB for ; Thu, 10 Feb 2022 13:12:02 -0800 (PST) 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.44.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <164452752232.18210.10779614976389928028@ietfa.amsl.com> Date: Thu, 10 Feb 2022 13:12:02 -0800 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, 10 Feb 2022 21:12:02 -0000 Review instructions and related resources are at: https://trac.ietf.org/trac/sec/wiki/SecDirReview For telechat 2022-02-17 Reviewer LC end Draft Alexey Melnikov 2021-11-23 draft-ietf-i2nsf-nsf-facing-interface-dm Klaas Wierenga R2021-08-30 draft-ietf-alto-cdni-request-routing-alto For telechat 2022-03-03 Reviewer LC end Draft Daniel Gillmor 2022-01-28 draft-ietf-rats-yang-tpm-charra Samuel Weiler R2021-08-25 draft-ietf-alto-path-vector Brian Weis 2021-08-19 draft-ietf-dnsop-svcb-https For telechat 2022-03-10 Reviewer LC end Draft Sandra Murphy 2022-03-07 draft-rsalz-2028bis Yoav Nir 2022-03-07 draft-carpenter-rfced-iab-charter Magnus Nystrom 2022-03-07 draft-rosen-rfcefdp-update-2026 For telechat 2022-04-07 Reviewer LC end Draft Daniel Migault 2021-06-28 draft-ietf-ipwave-vehicular-networking 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 Phillip Hallam-Baker R2022-02-23 draft-ietf-dprive-dnsoquic Steve Hanna 2022-01-24 draft-ietf-dots-telemetry Scott Kelly 2022-02-09 draft-ietf-ecrit-similar-location Chris Lonvick 2022-02-07 draft-ietf-quic-applicability Aanchal Malhotra 2022-02-03 draft-ietf-bfd-rfc9127-bis Aanchal Malhotra 2021-10-15 draft-ietf-kitten-tls-channel-bindings-for-tls13 Alexey Melnikov 2021-11-23 draft-ietf-i2nsf-nsf-facing-interface-dm Daniel Migault 2021-06-28 draft-ietf-ipwave-vehicular-networking Kathleen Moriarty 2022-02-24 draft-ietf-ipsecme-ikev2-intermediate Russ Mundy None draft-iab-rfcefdp-rfced-model Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Sandra Murphy 2022-03-07 draft-rsalz-2028bis Yoav Nir 2022-03-07 draft-carpenter-rfced-iab-charter Magnus Nystrom 2022-03-07 draft-rosen-rfcefdp-update-2026 Stefan Santesson 2021-08-11 draft-ietf-bier-te-arch Mališa Vučinić 2021-12-13 draft-ietf-anima-asa-guidelines Samuel Weiler R2021-08-25 draft-ietf-alto-path-vector Brian Weis 2021-08-19 draft-ietf-dnsop-svcb-https Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Klaas Wierenga R2021-08-30 draft-ietf-alto-cdni-request-routing-alto Liang Xia 2021-09-07 draft-ietf-bess-evpn-igmp-mld-proxy 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 Christopher Wood 2021-12-20 draft-ietf-opsawg-mud-iot-dns-considerations Next in the reviewer rotation: Hilarie Orman Radia Perlman Derrell Piper Tirumaleswar Reddy.K Vincent Roca Kyle Rose Joseph Salowey Rich Salz Stefan Santesson Benjamin Schwartz From nobody Sat Feb 12 06:14:38 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 6CAF43A0BE0; Sat, 12 Feb 2022 06:14:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Chris Lonvick via Datatracker To: Cc: draft-ietf-quic-applicability.all@ietf.org, last-call@ietf.org, quic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164467524535.12323.7686713745234547668@ietfa.amsl.com> Reply-To: Chris Lonvick Date: Sat, 12 Feb 2022 06:14:05 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-quic-applicability-14 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: Sat, 12 Feb 2022 14:14:06 -0000 Reviewer: Chris Lonvick 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 summary of the review is READY. I found the document to be very readable and concise. It clearly laid out the purpose of the document and provided sufficient information for readers to understand QUIC deployment issues. Security considerations were called out throughout the document and the Security Considerations section is appropriate for the contents of the document. (Apologies for the lateness of this review - busy couple of weeks.) Regards, Chris From nobody Sat Feb 12 10:45:54 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 17DF03A0C35; Sat, 12 Feb 2022 10:45:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Scott Kelly via Datatracker To: Cc: draft-ietf-ecrit-similar-location.all@ietf.org, ecrit@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164469152903.22389.17221318381823098353@ietfa.amsl.com> Reply-To: Scott Kelly Date: Sat, 12 Feb 2022 10:45:29 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-ecrit-similar-location-17 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: Sat, 12 Feb 2022 18:45:37 -0000 Reviewer: Scott Kelly Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is ready. >From the abstract, this document introduces a new way to provide returned location information in LoST responses that is either of a completed or similar form to the original input civic location, based on whether valid or invalid civic address elements are returned within the message. The security considerations section considers that this mechanism may disclose information, and that implementers should consider the implications of this in the context of their service. If I were writing this section, I might start by saying (because this doc extends RFC 5222) that all of the security considerations of 5222 apply, but this is implicit, and I don't feel strongly about this. >From a security considerations perspective, I think this document is ready. From nobody Mon Feb 14 08:48:03 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 7B14B3A11B2; Mon, 14 Feb 2022 08:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.65 X-Spam-Level: X-Spam-Status: No, score=-6.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_HI=-5, 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 9d0tFopFxfJK; Mon, 14 Feb 2022 08:47:52 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.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 598033A11AB; Mon, 14 Feb 2022 08:47:50 -0800 (PST) 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)) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 46122549B53; Mon, 14 Feb 2022 17:47:45 +0100 (CET) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 3721D4EA659; Mon, 14 Feb 2022 17:47:45 +0100 (CET) Date: Mon, 14 Feb 2022 17:47:45 +0100 From: Toerless Eckert To: iotops@ietf.org, secdir@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Archived-At: Subject: [secdir] (Home) user question: securing web access to insecure IOT web interfaces 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, 14 Feb 2022 16:47:56 -0000 Sorry if these are not the right list to ask this (pointers to better lists welcome), but i stumbled across i think a common problem that i am now getting curious about: - Many IOT devices / systems (controllers) have terrible security profiles. Many have just a port 80 web service without authentication. At least thats the case my question here is about as a starter. - The typical answer from "the industry" is to provide remote access to them is "Use a VPN", So just for the sake of picking an example, lets assume its IKEv2/IPsec with a server side WebPKI certificate, client side user/password and filtering of all traffic except for said web server port 80. - But of course, being able to simply use a browser is a lot more convenient, and arguably less user/client error-prone - because it does not require VPN client installation. Which then gets to the question: - Are there any useful analysis defining what exactly would constitute the most simple (combination of) application layer security mechanisms that could be considered equal or better in terms of security against attacks than such an IKEv2/IPsec VPN headend ? I assume it starts with something like reverse proxy with HTTPs+HTTP-auth, but IKEv2 also seems to have some simple DoS attack prevention that needs to be replicated, and then i guess the HTTPs connection also has some higher attack surface with all the messages one could try before successful authentication, HTTP message headers for example could provide information about the server side helping the attacker, etc. pp. Thanks! Toerless From nobody Mon Feb 14 10:01:18 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 E23863A089F; Mon, 14 Feb 2022 10:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, 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=boeing.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 esiRPeTxIUnY; Mon, 14 Feb 2022 10:00:47 -0800 (PST) Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 BD7143A07B5; Mon, 14 Feb 2022 10:00:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 21EI0eig010884; Mon, 14 Feb 2022 13:00:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1644861643; bh=ivkuD14i/mM0RoEdTuH9IpXHnoHca8450A+hj/GrmVM=; h=From:To:CC:Subject:Date:From; b=upveqnVjOCAM26FoiZR5aUd4Wfom4qbxa94Gytqv71o/OFjaxVQgPtJrcR9l/u+pA EPYbseLRCFZR1jHEsWshalKUNP5Qv1EUlTfWCqskokrbZu7RXTE2ucCubsRICC4OFm mhyuFVwgWyXmTNFCjsbDgge8FAA0GJmILNIrDc4lRI74L3gPZTjKuu+NqcFPoFoJxX P+ZaNVpr6MAvwYVL1kjONWobvBTI2f4Fd3oMmNyHyQQiEtWIink0lhr/ocAzvvUWRh 0E7JFTw9eh50+KZOIW9s/Q59N+XqyWXHJ5VQmEquejeI6mSlh8NQgcHdR4PVpEemr5 0tLpc02GaW6kg== Received: from XCH16-07-10.nos.boeing.com (xch16-07-10.nos.boeing.com [144.115.66.112]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 21EI0YPv010772 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 14 Feb 2022 13:00:34 -0500 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-10.nos.boeing.com (144.115.66.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.18; Mon, 14 Feb 2022 10:00:33 -0800 Received: from XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8]) by XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8%2]) with mapi id 15.01.2375.018; Mon, 14 Feb 2022 10:00:33 -0800 From: "Templin (US), Fred L" To: =?utf-8?B?TWljaGFlbCBUw7x4ZW4=?= , "tsv-art@ietf.org" , "int-dir@ietf.org" , IETF SecDir , "ops-dir@ietf.org" , "rtg-dir@ietf.org" CC: "draft-ietf-rtgwg-atn-bgp.all@ietf.org" , "rtgwg@ietf.org" Thread-Topic: Tsvart early review of draft-ietf-rtgwg-atn-bgp-13 Thread-Index: Adghy5/WpRmMiAyBQPiv/EhXVQAz0Q== Date: Mon, 14 Feb 2022 18:00:33 +0000 Message-ID: <6de3a2c362904d8883dd719ea9f13efc@boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 2C51A66FD559329D9C1AD66410996E4892EDA1CAA05A87E42295CC96F121415E2000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [secdir] Tsvart early review of draft-ietf-rtgwg-atn-bgp-13 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, 14 Feb 2022 18:00:54 -0000 TWljaGFlbCwgSSBmZWx0IGFkZHJlc3NpbmcgeW91ciBjb21tZW50IHdhcyBpbXBvcnRhbnQgZW5v dWdoIHRvIHdhcnJhbnQgYSBuZXcNCmRyYWZ0IHVwZGF0ZToNCg0KaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydGd3Zy1hdG4tYmdwLw0KDQpJbiB0aGUgcHJvY2Vz cywgSSBhbHNvIGFkZGVkIGEgbmV3IGZpZ3VyZSBpbiB0aGUgaW50cm9kdWN0aW9uIGFzIHJlY29t bWVuZGVkDQpieSBhbm90aGVyIHJldmlld2VyIHdobyBjb3JyZWN0bHkgcG9pbnRlZCBvdXQgdGhh dCBhIGZpZ3VyZSB3b3VsZCBtYWtlIHRoZQ0KZG9jdW1lbnQgZWFzaWVyIHRvIHVuZGVyc3RhbmQu DQoNClRoYW5rcyB0byBhbGwgZm9yIHRoZSBjb21tZW50cywNCg0KRnJlZA0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHJ0Z3dnIFttYWlsdG86cnRnd2ctYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pY2hhZWwgVMO8eGVuIHZpYSBEYXRhdHJhY2tlcg0KPiBT ZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDExLCAyMDIyIDEyOjIzIFBNDQo+IFRvOiB0c3YtYXJ0QGll dGYub3JnDQo+IENjOiBkcmFmdC1pZXRmLXJ0Z3dnLWF0bi1iZ3AuYWxsQGlldGYub3JnOyBydGd3 Z0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBbRVhURVJOQUxdIFRzdmFydCBlYXJseSByZXZpZXcgb2Yg ZHJhZnQtaWV0Zi1ydGd3Zy1hdG4tYmdwLTEzDQo+IA0KPiBFWFQgZW1haWw6IGJlIG1pbmRmdWwg b2YgbGlua3MvYXR0YWNobWVudHMuDQo+IA0KPiANCj4gDQo+IFJldmlld2VyOiBNaWNoYWVsIFTD vHhlbg0KPiBSZXZpZXcgcmVzdWx0OiBSZWFkeQ0KPiANCj4gVGhlIGRvY3VtZW50IG1lbnRpb25z IHRoYXQgc29tZSBkYXRhIGxpbmtzIHVzZWQgYnkgYWlyY3JhZnRzIHRvZGF5IG9ubHkgcHJvdmlk ZQ0KPiBhIGJhbmR3aWR0aCBpbiB0aGUgb3JkZXIgb2YgMzIgS2Jwcy4gQW55IHByb3RvY29scyB1 c2luZyB0aGVzZSBsaW5rcyBzaG91bGQgYmUNCj4gcGFyYW1ldHJpc2VkIGZvciB0aGF0IGJhbmR3 aWR0aCBhbmQgcGFyYW1ldHJpc2F0aW9uIG1pZ2h0IG5vdCBiZSB0aGUgZGVmYXVsdA0KPiBvbmUg dXNlZCBpbiB0b2RheXMgbGlua3MgdXNlZCBpbiB0aGUgSW50ZXJuZXQuIEhvd2V2ZXIsIGlmIEkg dW5kZXJzdGFuZCB0aGUNCj4gZG9jdW1lbnQgY29ycmVjdGx5LCB0aGUgQkdQIGNvbW11bmljYXRp b24gZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgaXMgbm90DQo+IHVzaW5nIHRoZXNlIGxpbmtz IGFuZCB0aGVyZWZvcmUgSSBzZWUgbm8gaXNzdWVzIHdpdGggcmVzcGVjdCB0byB0cmFuc3BvcnQN Cj4gcHJvdG9jb2wgY29uc2lkZXJhdGlvbnMuDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcnRnd2cgbWFpbGluZyBsaXN0DQo+IHJ0 Z3dnQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRn d2cNCg== From nobody Mon Feb 14 13:21:21 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 E23173A1043; Mon, 14 Feb 2022 13:21:12 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKAtwrAWL4Lo; Mon, 14 Feb 2022 13:21:08 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.85]) (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 87E953A103D; Mon, 14 Feb 2022 13:21:06 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4JyHFp0ymcz3K7; Mon, 14 Feb 2022 22:21:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1644873662; bh=6pcXaNNO9bRF9NreDqGMJ40G5MFfehM9H0mV24pEptY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=czuMk1jGDPyQxHKFP4oa6mnqZeGSOewkoSd9ox5Op09cL1YyxujD3JUk6iDSS6w3q FGGbZljs8WA5thKdjKuH5alhQxgz/nenF5z6387DzdnjupA7h1ncQQocDunQWzKTJd r0JzfEXbNzM8WfDREfWLbJ66yBj/sZxohsLs7+dw= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id oY6Cpatfxynz; Mon, 14 Feb 2022 22:21:01 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 14 Feb 2022 22:21:00 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C36CD252974; Mon, 14 Feb 2022 16:20:59 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C0A8E252973; Mon, 14 Feb 2022 16:20:59 -0500 (EST) Date: Mon, 14 Feb 2022 16:20:59 -0500 (EST) From: Paul Wouters To: Toerless Eckert cc: iotops@ietf.org, secdir In-Reply-To: Message-ID: <8acb5596-1183-67f0-adc5-c4937eb7f5e@nohats.ca> References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [secdir] (Home) user question: securing web access to insecure IOT web interfaces 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, 14 Feb 2022 21:21:13 -0000 On Mon, 14 Feb 2022, Toerless Eckert wrote: > - Are there any useful analysis defining what exactly would constitute the most > simple (combination of) application layer security mechanisms that could be > considered equal or better in terms of security against attacks than > such an IKEv2/IPsec VPN headend ? (m)TLS ? > I assume it starts with something like reverse proxy with HTTPs+HTTP-auth, but > IKEv2 also seems to have some simple DoS attack prevention that needs to be > replicated, and then i guess the HTTPs connection also has some higher attack > surface with all the messages one could try before successful authentication, > HTTP message headers for example could provide information about the server side > helping the attacker, etc. pp. The message parsing is generally not the problem. It is doing things like DiffieHellman and Signature creation/validation that takes the most CPU. A reverse proxy of TLS endpoint should have enough resources to fend of an attack similar to IKEv2. Paul From nobody Mon Feb 14 14:04:15 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 09C0C3A14CD; Mon, 14 Feb 2022 14:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.812 X-Spam-Level: X-Spam-Status: No, score=-7.812 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, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_HI=-5, 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 ETW64s-W8X6V; Mon, 14 Feb 2022 14:03:50 -0800 (PST) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 9BD603A142E; Mon, 14 Feb 2022 14:03:10 -0800 (PST) Received: by mail-qt1-x82b.google.com with SMTP id s1so16741049qtw.9; Mon, 14 Feb 2022 14:03:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=FFZgcWXs40bMlGqFyek053TZUXitw0VfEoWBkfT0EfI=; b=KtoghUTaMdNRmN15br4mFNefJbNy5A9W2TRHJCawICXD3d+3pVsD6KLDtoXBKRIImZ njZUjy78kOE3HXwdGADnP6lZRZ+iEZXfiv+pm18dc0PT+6ofr33rBaWZMUwsaLgZ9i3r jN872XC3yZUQ9RYwDMfgEmDze8Mz7k9qI6Vc+pFUwK1sXWJhIftSbmw2ww4Thwn5+gd1 14l5Frva2/lopYY2ol4meXPQY6wRghILDOZkYb+8yS1i7JO3mZLVdHkFzjypvIOICh4G QheHqQuVWWh3pge4KaCAKvObveSnfLnkna318qNrEERmqRTFfTmKmF4A+dlq2dd4XgBa Fi6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=FFZgcWXs40bMlGqFyek053TZUXitw0VfEoWBkfT0EfI=; b=BygbsPqTaY2kwpz2Ln0Xhnq8Z1VyxxU/tccj6AdIX2N6CjxDqMfB7rhNfTiaMMdTiq cXoOJDYyWtOUArHp8k4/8MF9+QEfRX6IcEdoza7PEgUM6d6drVbu7yR/HhRZ08t8p7eb o1QGV/AoHYcAQmmMuqkRSMvfUrr/bWv81vENSS0cantIbt6sCdv+VeZSKiyO6MfHpyfX cyE8Frfisp2x7+XjDwie5eDCFLVG/wpIW4vWQkvAxMlDOaaq60XbBE1B6CX5cKZI2Tth hEGs3obzyGFutLq7lrH74X2JWicxPS3BV4PshxuS0YTpDRUF393IjF7dlWnl01kKeVux +cnQ== X-Gm-Message-State: AOAM533cJWMj0txQmrAJWGXibBSZ5hdW+XBU7bwpeERGTz4rzAwVrEkt VWw8TIokFll4KpH12hILX2w= X-Google-Smtp-Source: ABdhPJzH0LxXKRdULgfy1RXMUS0qockr3nKHhS2YFzNsMrhxaRnGNyUlqeaN3xICXc3sH1YEhazA0Q== X-Received: by 2002:a05:622a:24e:: with SMTP id c14mr752723qtx.305.1644876188658; Mon, 14 Feb 2022 14:03:08 -0800 (PST) Received: from [192.168.1.151] (cpe-74-70-70-237.nycap.res.rr.com. [74.70.70.237]) by smtp.googlemail.com with ESMTPSA id 22sm19219768qtw.75.2022.02.14.14.03.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Feb 2022 14:03:08 -0800 (PST) Message-ID: <2834d0d5-437b-7fe3-83b9-f7acc0b83fd8@gmail.com> Date: Mon, 14 Feb 2022 17:03:07 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Content-Language: en-US To: Catherine Meadows , secdir@ietf.org Cc: draft-ietf-calext-ical-relations.all@ietf.org, last-call@ietf.org, calsify@ietf.org References: <164442710515.4563.6397829591254976677@ietfa.amsl.com> From: Michael Douglass In-Reply-To: <164442710515.4563.6397829591254976677@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [secdir] [calsify] Secdir telechat review of draft-ietf-calext-ical-relations-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, 14 Feb 2022 22:04:01 -0000 On 2/9/22 12:18, Catherine Meadows via Datatracker wrote: > Reviewer: Catherine Meadows > Review result: Has Nits > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The summary of the review is Ready with nits. > > This draft describes an update of the iCalendar RELATED-TO property, > introducing new properties LINK, CONCEPT, and REFID. In particular, RELATED-TO > only allowed the value type TEXT. Depending on the property draft extends the > allowed value types to include URI and UID, and REFERENCE, where REFERENCE is a > URI with a pointer to a fragment of XML code. > The Security Considerations Section correctly points out that the security > impact of the new/expanded properties is in the new data types URI and > REFERENCE they can return, and the fact that they may point to external > sources which may vanish or be replaced. This is supplemented with reference > to the security considerations in the appropriate RFC’s. > > My only concern with the previous draft was that the risks of values of type > REFERENCE were not addressed. This has now been taken care of. > > Nits: In the definition of REFERENCE, “it's use as an anchor” should be “its > use as an anchor”. Thank you - fixed. > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Mon Feb 14 15:22:31 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 0C4A03A131F; Mon, 14 Feb 2022 15:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.65 X-Spam-Level: X-Spam-Status: No, score=-6.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_HI=-5, 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 0iNwDJTxAMP1; Mon, 14 Feb 2022 15:22:24 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.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 EA1C73A131C; Mon, 14 Feb 2022 15:22:23 -0800 (PST) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff: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 E04EE549B4C; Tue, 15 Feb 2022 00:22:17 +0100 (CET) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id CE6C14EA660; Tue, 15 Feb 2022 00:22:17 +0100 (CET) Date: Tue, 15 Feb 2022 00:22:17 +0100 From: Toerless Eckert To: Paul Wouters Cc: iotops@ietf.org, secdir Message-ID: References: <8acb5596-1183-67f0-adc5-c4937eb7f5e@nohats.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8acb5596-1183-67f0-adc5-c4937eb7f5e@nohats.ca> Archived-At: Subject: Re: [secdir] (Home) user question: securing web access to insecure IOT web interfaces 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, 14 Feb 2022 23:22:29 -0000 On Mon, Feb 14, 2022 at 04:20:59PM -0500, Paul Wouters wrote: > On Mon, 14 Feb 2022, Toerless Eckert wrote: > > > - Are there any useful analysis defining what exactly would constitute the most > > simple (combination of) application layer security mechanisms that could be > > considered equal or better in terms of security against attacks than > > such an IKEv2/IPsec VPN headend ? > > (m)TLS ? ? > > I assume it starts with something like reverse proxy with HTTPs+HTTP-auth, but > > IKEv2 also seems to have some simple DoS attack prevention that needs to be > > replicated, and then i guess the HTTPs connection also has some higher attack > > surface with all the messages one could try before successful authentication, > > HTTP message headers for example could provide information about the server side > > helping the attacker, etc. pp. > > The message parsing is generally not the problem. I would assume every web server software whether open source or proprietary has been analysef well enough to find any buffer overflow or similar attack vectors. And given the flexibility of HTTP compared to the much more constrained binary messages of IKEv2, i can imagine that there is much higher likelyhood of security relevant bugs. But i don't know whether people have tried to quantify and compare. > It is doing things > like DiffieHellman and Signature creation/validation that takes the > most CPU. > > A reverse proxy of TLS endpoint should have enough resources to fend of > an attack similar to IKEv2. Yes, i am not concerned abour resources, just about defining required DoS protection mechanisms. Cheers Toerless > Paul -- --- tte@cs.fau.de From nobody Tue Feb 15 07:10:21 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 6C80A3A0D43; Tue, 15 Feb 2022 07:10:18 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 laSwAeRh0U03; Tue, 15 Feb 2022 07:10:13 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id CDE503A07D8; Tue, 15 Feb 2022 07:10:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1644937811; d=isode.com; s=june2016; i=@isode.com; bh=0hxjQeGE62mhZlSJS6p3ZympA3MwNUEfftinmKNKjeI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=MA15MkZKfZohhp8L7dW89EMRy/ew8oHpfwRPcC8GpvWRJuKqLEaOVXYqyIQ+Ud+YwdL4H7 707Y+0y05wGzMErPV5icwDk/HNBgWaeLiwM7J1v41FfZJGDtFArQZ48PoJ9sQRfDT+aDg0 AHd2vfGhE6p+fFvRRd4GtDhvyTPFFOg=; Received: from [192.168.1.222] (host31-49-219-49.range31-49.btcentralplus.com [31.49.219.49]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 15 Feb 2022 15:10:11 +0000 Message-ID: <2f45c360-8016-295d-1881-add350aa3be7@isode.com> Date: Tue, 15 Feb 2022 15:10:03 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 To: "secdir@ietf.org" , draft-ietf-i2nsf-nsf-facing-interface-dm.all@ietf.org Cc: "last-call@ietf.org" From: Alexey Melnikov MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [secdir] SecDir last call review of draft-ietf-i2nsf-nsf-facing-interface-dm-21 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, 15 Feb 2022 15:10:19 -0000 Reviewer: Alexey Melnikov Review result: Has Minor 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 a YANG data model for configuring security policy rules on Network Security Functions (NSF) in the Interface to Network Security Functions (I2NSF) framework. The YANG data model in this document corresponds to the information model for NSF-Facing Interface in the I2NSF framework. Overall the document reads well and YANG specific security considerations that talk about access control for various elements look sufficient to me. However the document lacks some details important for implementations, specific cases listed below. Issues. identity transformation { base egress-action; description "Identity for transformation. The transformation action is used to transform the packet by modifying its protocol header such as HTTP-to-CoAP translation."; reference "RFC 8075: Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP) - Translation between HTTP and CoAP."; } This is not listed as a choice (in a comment) in "leaf egress-action". Should it be? If it is listed, is this enough to define algorithmic transformations? identity imaps { base application-protocol; description "The identity for Internet Message Access Protocol (IMAP) over TLS"; reference "RFC 9051: Internet Message Access Protocol (IMAP) - Version 4rev2 RFC 2595: Using TLS with IMAP, POP3 and ACAP"; } Thank you for splitting "imap" from "imaps" in -21. In regards to references: please don't reference RFC 2595 for IMAPS here. IMAPS is fully described by RFC 9051, so having a reference to RFC 2595 is misleading. typedef time { type string { pattern '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.\d+)?' + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?'; } description "The time type represents an instance of time of zero-duration that recurs every day."; } I think you should also clarify in the description that this includes timezone, for example: "The time type represents an instance of time of zero-duration in the specified timezone that recurs every day." leaf session-aging-time { type uint16; units "second"; description "This is session aging time."; } I can't figure out from the description what this means. Can you give an example? container long-connection { description "A container for long connection. A long connection is a connection that is maintained after the socket connection is established, regardless of whether it is used for data traffic or not."; leaf enable { type boolean; description "If true, the rule is enabled and enforced. If false, the rule is configured but disabled and not enforced."; } leaf duration { type uint16; units "second"; description "This is the duration of the long-connection."; Is this max connection duration or the current duration? } } container url-category { description "Condition for url category"; leaf description { type string; description "This is description for the condition of a URL's category such as SNS sites, game sites, ecommerce sites, company sites, and university sites."; } leaf-list pre-defined { type string; description "This is pre-defined-category. To specify the name of URL database."; } leaf-list user-defined { type string; description "This user-defined-category. To allow a users manual addition of URLs for URL filtering."; } } I think "user-defined" is supposed to be an URL. This needs a Normative Reference. Please use RFC 3986. leaf alert-flow-rate { type uint32; description "The alert rate of flood detection for flows per second of an IP address. If the flows per second of an IP address exceeds the alert rate threshold, an alert will be generated."; } I assume you mean the rate of flow creation requests? E.g. new TCP connection establishment. Please clarify this. container anti-virus { description "Condition for antivirus"; leaf-list profile { type string; description "The security profile for antivirus. This is used to update the security profile for improving the security. The security profile is used to scan the viruses."; } leaf-list exception-files { type string; description "The type or name of the files to be excluded by the anti-virus. This can be used to keep the known harmless files."; Is this the list of filesystem paths? Of File patterns, like "*.exe"? } } container payload { description "Condition for packet payload"; leaf description { type string; description "This is description for payload condition."; } leaf-list content { type string; description "This is a condition for packet payload content."; What does this mean? Can you give some examples? } } In "container users": leaf security-group { type string; description "security-group."; } What does this mean? How is it different from "group"? Thank you, Alexey From nobody Wed Feb 16 01:38:00 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 E52773A0CF6 for ; Wed, 16 Feb 2022 01:37:57 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=epfl.ch 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 KiuNluUBcytG for ; Wed, 16 Feb 2022 01:37:54 -0800 (PST) Received: from smtp5.epfl.ch (smtp5.epfl.ch [IPv6:2001:620:618:1e0:1:80b2:e034:1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C4D63A0CDD for ; Wed, 16 Feb 2022 01:37:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=epfl.ch; s=epfl; t=1645003868; h=From:To:CC:Subject:Date:Message-ID:Content-Type:MIME-Version; bh=PLMuWQVAljlEAXERtG6O7k/+1KUj9TNgdEuyvLwD/GY=; b=mq4C3FEgvVLUUCGxIZN3OJ1z8qX5J44SWQsCxdVO9MIAKq2WQD8BP0GlSWLOzzWSr ji2ipYIfd9S1UJX4xbRlYwQki0wdxp9fRurQSVCUizq3+r1iF1tz2B3IPTv9AYIMF EMjcAfftn43rijp3mTlAnZNx2557+z4zkWZ8EWTo0= Received: (qmail 7459 invoked by uid 107); 16 Feb 2022 09:31:08 -0000 Received: from ax-snat-224-177.epfl.ch (HELO ewa06.intranet.epfl.ch) (192.168.224.177) (TLS, ECDHE-RSA-AES256-GCM-SHA384 (X25519 curve) cipher) by mail.epfl.ch (AngelmatoPhylax SMTP proxy) with ESMTPS; Wed, 16 Feb 2022 10:31:08 +0100 X-EPFL-Auth: ChiTjig/1nrDVI4nqge2ismk1jUImHrXM36ogFxJSFIlnLHe2XM= Received: from ewa02.intranet.epfl.ch (128.178.224.159) by ewa06.intranet.epfl.ch (128.178.224.177) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.18; Wed, 16 Feb 2022 10:31:08 +0100 Received: from ewa02.intranet.epfl.ch ([fe80::ddaf:e0cc:a2d6:4aaf]) by ewa02.intranet.epfl.ch ([fe80::ddaf:e0cc:a2d6:4aaf%3]) with mapi id 15.01.2375.018; Wed, 16 Feb 2022 10:31:08 +0100 From: Mohammadpour Ehsan To: Watson Ladd CC: "secdir@ietf.org" , "detnet@ietf.org" , "draft-ietf-detnet-bounded-latency.all@ietf.org" , "last-call@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-detnet-bounded-latency-08 Thread-Index: AQHYFkH/2ASreex3aEmk3R9DC2PWFKyV8pMA Date: Wed, 16 Feb 2022 09:31:08 +0000 Message-ID: <0D2CDDB5-8BDF-484C-A154-554EDAD1C85D@epfl.ch> References: <164359256461.13046.3662935981665413488@ietfa.amsl.com> In-Reply-To: <164359256461.13046.3662935981665413488@ietfa.amsl.com> Accept-Language: en-US, fr-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.178.151.68] Content-Type: multipart/alternative; boundary="_000_0D2CDDB58BDF484CA154554EDAD1C85Depflch_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-detnet-bounded-latency-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2022 09:37:58 -0000 --_000_0D2CDDB58BDF484CA154554EDAD1C85Depflch_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBXYXRzb24sDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgY29tbWVudHMuIFdl IGhhdmUgbW9kaWZpZWQgdGhlIOKAnFNlY3VyaXR5IENvbnNpZGVyYXRpb27igJ0gc2VjdGlvbjsg c3BlY2lmaWNhbGx5LCB3ZSBhZGRlZCBwb3RlbnRpYWwgYXR0YWNrIHNjZW5hcmlvcyBvbiB0aGUg bW9kZWwgcHJlc2VudGVkIGluIHRoZSBkcmFmdC4gWW91IGNhbiBmaW5kIHRoZSBuZXcgdmVyc2lv biBvZiB0aGUgZHJhZnQgaW46DQpodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0 LWlldGYtZGV0bmV0LWJvdW5kZWQtbGF0ZW5jeS0wOS5odG1sDQoNCmFzIHdlbGwgYXMgdGhlIGRp ZmZlcmVuY2UgYmV0d2VlbiB0aGUgbmV3IHZlcnNpb24gYW5kIHRoZSBwcmV2aW91cyB2ZXJzaW9u IGluOg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtZGV0bmV0 LWJvdW5kZWQtbGF0ZW5jeS0wOQ0KDQoNCg0KQmVzdCwNCkVoc2FuDQoNCg0KDQotLQ0KRWhzYW4g TW9oYW1tYWRwb3VyDQpQaEQgY2FuZGlkYXRlIGF0IFN3aXNzIEZlZGVyYWwgSW5zdGl0dXRlIG9m IFRlY2hub2xvZ3kgKEVQRkwpDQpJQyBJSU5GQ09NLCBMQ0EyLCBJTkYgMDExLCBTdGF0aW9uIDE0 LCAxMDE1IExhdXNhbm5lLCBTd2l0emVybGFuZA0KaHR0cHM6Ly9wZW9wbGUuZXBmbC5jaC9laHNh bi5tb2hhbW1hZHBvdXINCg0KT24gMzEgSmFuIDIwMjIsIGF0IDAyOjI5LCBXYXRzb24gTGFkZCB2 aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc8bWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmc+ PiB3cm90ZToNCg0KUmV2aWV3ZXI6IFdhdHNvbiBMYWRkDQpSZXZpZXcgcmVzdWx0OiBIYXMgSXNz dWVzDQoNCkRlYXIgZmVsbG93IElFVEZlcnMsDQoNCkFsYXMgSSdtIGZvcmNlZCB0byBwdXQgZG93 biBkcmFmdC1pZXRmLWRldG5ldC1ib3VuZGVkLWxhdGVuY3kgYXMgaGF2aW5nIGlzc3Vlcy4NClRo ZSB2YXN0IG1ham9yaXR5IG9mIHRoZSBkcmFmdCBpcyBhIGRldGFpbGVkIGFuZCByZWFkYWJsZSBk ZXNjcmlwdGlvbiBvZiBob3cgdG8NCmNvbXB1dGUgdGhlIHJlc291cmNlcyByZXF1aXJlZCBmb3Ig YSBwYXJ0aWN1bGFyIFFvUy4gQnV0IHVuZm9ydHVuYXRlbHkgdGhlDQpzZWN1cml0eSBjb25jZXJu cyBzZWN0aW9uIGhhcyBhIHBhcmFncmFwaCBhYm91dCBzZWN1cmluZyB0aGUgcmVzZXJ2YXRpb25z IHdoaWNoDQpkb2Vzbid0IHJlYWxseSBzZWVtIHJlbGV2YW50OiBpdCB3b3VsZCBzZWVtIHRvIGJl IHJlbGV2YW50IHRvIHRoZSBjb250cm9sIHBsYW5lDQp0aGF0IGRvZXMgdGhlIHJlc2VydmluZy4g QXQgdGhlIHNhbWUgdGltZSBhIGRpc2N1c3Npb24gb2YgaG93IGFuIGF0dGFja2VyIG1pZ2h0DQpi ZSBhYmxlIHRvIGFidXNlIHRoZSBtb2RlbHMgcHJlc2VudGVkIGluIHRoZSBkb2N1bWVudCBpcyBs YWNraW5nLg0KDQpUaGlzIGlzIHBhcnRpY3VsYXJseSBpbXBvcnRhbnQgZ2l2ZW4gdGhhdCB0aGVy ZSBjYW4gYmUgdmVyeSB1bmludHVpdGl2ZSBnbG9iYWwNCmVmZmVjdHMgZnJvbSBjaGFuZ2VzIG1h ZGUgdG8gY2FwYWNpdHkgb24gb25lIG5vZGUgb3IgbGluayBpbiBhIG5ldHdvcmsuDQpTaW5jZXJl bHksIFdhdHNvbg0KDQoNCg0K --_000_0D2CDDB58BDF484CA154554EDAD1C85Depflch_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkRlYXIgV2F0c29uLA0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmsgeW91IHZlcnkgbXVjaCBm b3IgeW91ciBjb21tZW50cy4gV2UgaGF2ZSBtb2RpZmllZCB0aGUg4oCcU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbuKAnSBzZWN0aW9uOyBzcGVjaWZpY2FsbHksIHdlIGFkZGVkIHBvdGVudGlhbCBhdHRh Y2sgc2NlbmFyaW9zIG9uIHRoZSBtb2RlbCBwcmVzZW50ZWQgaW4gdGhlIGRyYWZ0LiBZb3UgY2Fu IGZpbmQgdGhlIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBpbjo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1pZXRmLWRl dG5ldC1ib3VuZGVkLWxhdGVuY3ktMDkuaHRtbCIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvYXJjaGl2ZS9pZC9kcmFmdC1pZXRmLWRldG5ldC1ib3VuZGVkLWxhdGVuY3ktMDkuaHRtbDwv YT4gJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5hcyB3ZWxsIGFzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIG5ldyB2ZXJz aW9uIGFuZCB0aGUgcHJldmlvdXMgdmVyc2lvbiBpbjo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtZGV0bmV0 LWJvdW5kZWQtbGF0ZW5jeS0wOSIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWlldGYtZGV0bmV0LWJvdW5kZWQtbGF0ZW5jeS0wOTwvYT4mbmJzcDs8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBkaXI9ImF1dG8iIGNsYXNzPSIiIHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFr LXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUt c3BhY2U7Ij4NCjxkaXYgZGlyPSJhdXRvIiBjbGFzcz0iIiBzdHlsZT0id29yZC13cmFwOiBicmVh ay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRl LXNwYWNlOyI+DQpCZXN0LDxiciBjbGFzcz0iIj4NCkVoc2FuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9ImF1dG8iIHN0eWxlPSJjYXJldC1j b2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgd29yZC13cmFw OiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFmdGVy LXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0iYXV0byIgc3R5bGU9ImNhcmV0LWNv bG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB3b3JkLXdyYXA6 IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXIt d2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KLS08YnIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXNpemU6IDExcHg7IiBjbGFzcz0iIj5FaHNhbiBNb2hhbW1hZHBvdXI8 YnIgY2xhc3M9IiI+DQpQaEQgY2FuZGlkYXRlIGF0IFN3aXNzIEZlZGVyYWwgSW5zdGl0dXRlJm5i c3A7b2YgVGVjaG5vbG9neSAoRVBGTCk8YnIgY2xhc3M9IiI+DQpJQyBJSU5GQ09NLCBMQ0EyLCBJ TkYgMDExLCBTdGF0aW9uIDE0LCZuYnNwOzEwMTUgTGF1c2FubmUsIFN3aXR6ZXJsYW5kPGJyIGNs YXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly9wZW9wbGUuZXBmbC5jaC9laHNhbi5tb2hhbW1hZHBv dXIiIGNsYXNzPSIiPmh0dHBzOi8vcGVvcGxlLmVwZmwuY2gvZWhzYW4ubW9oYW1tYWRwb3VyPC9h Pjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDMx IEphbiAyMDIyLCBhdCAwMjoyOSwgV2F0c29uIExhZGQgdmlhIERhdGF0cmFja2VyICZsdDs8YSBo cmVmPSJtYWlsdG86bm9yZXBseUBpZXRmLm9yZyIgY2xhc3M9IiI+bm9yZXBseUBpZXRmLm9yZzwv YT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5l Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPlJldmlld2VyOiBXYXRzb24gTGFkZDxi ciBjbGFzcz0iIj4NClJldmlldyByZXN1bHQ6IEhhcyBJc3N1ZXM8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpEZWFyIGZlbGxvdyBJRVRGZXJzLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCkFsYXMgSSdtIGZvcmNlZCB0byBwdXQgZG93biBkcmFmdC1pZXRmLWRldG5ldC1ib3VuZGVk LWxhdGVuY3kgYXMgaGF2aW5nIGlzc3Vlcy48YnIgY2xhc3M9IiI+DQpUaGUgdmFzdCBtYWpvcml0 eSBvZiB0aGUgZHJhZnQgaXMgYSBkZXRhaWxlZCBhbmQgcmVhZGFibGUgZGVzY3JpcHRpb24gb2Yg aG93IHRvPGJyIGNsYXNzPSIiPg0KY29tcHV0ZSB0aGUgcmVzb3VyY2VzIHJlcXVpcmVkIGZvciBh IHBhcnRpY3VsYXIgUW9TLiBCdXQgdW5mb3J0dW5hdGVseSB0aGU8YnIgY2xhc3M9IiI+DQpzZWN1 cml0eSBjb25jZXJucyBzZWN0aW9uIGhhcyBhIHBhcmFncmFwaCBhYm91dCBzZWN1cmluZyB0aGUg cmVzZXJ2YXRpb25zIHdoaWNoPGJyIGNsYXNzPSIiPg0KZG9lc24ndCByZWFsbHkgc2VlbSByZWxl dmFudDogaXQgd291bGQgc2VlbSB0byBiZSByZWxldmFudCB0byB0aGUgY29udHJvbCBwbGFuZTxi ciBjbGFzcz0iIj4NCnRoYXQgZG9lcyB0aGUgcmVzZXJ2aW5nLiBBdCB0aGUgc2FtZSB0aW1lIGEg ZGlzY3Vzc2lvbiBvZiBob3cgYW4gYXR0YWNrZXIgbWlnaHQ8YnIgY2xhc3M9IiI+DQpiZSBhYmxl IHRvIGFidXNlIHRoZSBtb2RlbHMgcHJlc2VudGVkIGluIHRoZSBkb2N1bWVudCBpcyBsYWNraW5n LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoaXMgaXMgcGFydGljdWxhcmx5IGltcG9y dGFudCBnaXZlbiB0aGF0IHRoZXJlIGNhbiBiZSB2ZXJ5IHVuaW50dWl0aXZlIGdsb2JhbDxiciBj bGFzcz0iIj4NCmVmZmVjdHMgZnJvbSBjaGFuZ2VzIG1hZGUgdG8gY2FwYWNpdHkgb24gb25lIG5v ZGUgb3IgbGluayBpbiBhIG5ldHdvcmsuPGJyIGNsYXNzPSIiPg0KU2luY2VyZWx5LCBXYXRzb248 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_0D2CDDB58BDF484CA154554EDAD1C85Depflch_-- From nobody Wed Feb 16 13:14:23 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 767893A1687; Wed, 16 Feb 2022 13:14:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoav Nir via Datatracker To: Cc: draft-carpenter-rfced-iab-charter.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164504605737.5780.6077978787283129045@ietfa.amsl.com> Reply-To: Yoav Nir Date: Wed, 16 Feb 2022 13:14:17 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-carpenter-rfced-iab-charter-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: Wed, 16 Feb 2022 21:14:18 -0000 Reviewer: Yoav Nir Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document is ready. It's concise and does just what it's supposed to, nothing more. That's always good for security. The security considerations section reads, "This document should not affect the security of the Internet." I'd go even further and state that it in fact does not affect the security of the Internet. Documents published by the RFC editor's new model might, although they might affect it for the better as well as for the worse. From nobody Wed Feb 16 14:01:15 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 936373A16F1; Wed, 16 Feb 2022 14:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.813 X-Spam-Level: X-Spam-Status: No, score=-2.813 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, NICE_REPLY_A=-0.714, 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 MS6Mf5U1ZzjD; Wed, 16 Feb 2022 14:01:10 -0800 (PST) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 226923A165E; Wed, 16 Feb 2022 14:01:10 -0800 (PST) Received: by mail-pj1-x1034.google.com with SMTP id k60-20020a17090a4cc200b001b932781f3eso5025727pjh.0; Wed, 16 Feb 2022 14:01:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=gNeukKn7ZNP5yvaCvz0Bpd9Y2mjWFYeDfoQ5HmTvU0g=; b=K0uCK7DIEdgOcmQFKVcz3LTWno2N3EZXUap/FIVNLzvxFn5c341/AqhzvRLuKAu14E 8Y3qel2OfG5Xunkw+nhatc9MH0H6Z00rCDA2zkIBFaJ6UQcljo8mOWiEda3Gb+AK2n4H 31NAy/CyqWzQ70zWB9/Ai59KILyyl215Xdz3uN7m4pkHN4tNR0GoXyppL2n/lzALCY5W p6MMzgSAO9r0OSmI9vfoGAR/au5vbH+OQxW2HGkAjrusxHuN3dsLvT7tGAdh2OE44/YE BVwKvJ2cByIY1RzRV2Ni3z8pWXrmMsCGNLnTHtEjtbosm8JszaVAdRQwIpLYHSOGWulv AQhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=gNeukKn7ZNP5yvaCvz0Bpd9Y2mjWFYeDfoQ5HmTvU0g=; b=v8a/XUHwppVOAoeiczfioRV4w5SyRPnIF8QMTChbpzgrHWH6rdWAqrAhZpS7nVc5nH Kzp5xPePYiYUw/G8LDqbXGo/zvEwQ+C3yHHymqIRx3SXXc8kW/ynhow0yRPwM//I6WDe PK2guhizQOA+xHVV8X9eOi7R+l8y2xJ9bsmDzTAXTH2CGJbih/QApsJ2xzA9gD8S7p1l DlYFeN7LOsmDqUO89JoWbDNFFJ/oQeOCT+SY7ox2GnWkgFysts/Bsf35fsT16081g9sV K33ibghdh6WtewDe+YH+gjqqpFwryDfyKB8KycpPXMkwGlCi0+WcJO0w9Vhco7ubIFFW qamg== X-Gm-Message-State: AOAM532ioO5ugKEgQLxUE9drcCuOTRDrW3Q3YzFn7kVXyitf8hyKssjh vND3Z29CpxGlwp6kXBsTcwewvyzolTIuyQ== X-Google-Smtp-Source: ABdhPJznVBbl3CAy5HZ//whpo7S3ASn1DshTuCTR9Q5zdob4A8mBs29BrIBcxy+Ur9E8QEh3Z8SwoQ== X-Received: by 2002:a17:90b:1a92:b0:1b9:8094:446b with SMTP id ng18-20020a17090b1a9200b001b98094446bmr3975720pjb.93.1645048868667; Wed, 16 Feb 2022 14:01:08 -0800 (PST) Received: from ?IPv6:2406:e003:1005:b501:80b2:5c79:2266:e431? ([2406:e003:1005:b501:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id p4sm6167722pgh.53.2022.02.16.14.01.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Feb 2022 14:01:08 -0800 (PST) To: Yoav Nir , secdir@ietf.org Cc: draft-carpenter-rfced-iab-charter.all@ietf.org, last-call@ietf.org References: <164504605737.5780.6077978787283129045@ietfa.amsl.com> From: Brian E Carpenter Message-ID: <766a9539-004c-bc25-1e23-ad1c960acacb@gmail.com> Date: Thu, 17 Feb 2022 11:01:03 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <164504605737.5780.6077978787283129045@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] Secdir last call review of draft-carpenter-rfced-iab-charter-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2022 22:01:13 -0000 Hi Yoav, Thanks for the review. I have no strong feelings about the security wording, so I'll wait for advice from the AD. Regards Brian Carpenter On 17-Feb-22 10:14, Yoav Nir via Datatracker wrote: > Reviewer: Yoav Nir > Review result: Ready > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area directors. > Document editors and WG chairs should treat these comments just like any other > last call comments. > > The document is ready. It's concise and does just what it's supposed to, > nothing more. That's always good for security. > > The security considerations section reads, "This document should not affect the > security of the Internet." I'd go even further and state that it in fact does > not affect the security of the Internet. Documents published by the RFC > editor's new model might, although they might affect it for the better as well > as for the worse. > > > From nobody Wed Feb 16 22:47:47 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 94C403A132D; Wed, 16 Feb 2022 22:47:43 -0800 (PST) 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 puyhmSaZhGZL; Wed, 16 Feb 2022 22:47:41 -0800 (PST) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 430EF3A1339; Wed, 16 Feb 2022 22:47:13 -0800 (PST) Received: by mail-il1-x130.google.com with SMTP id d7so1582240ilf.8; Wed, 16 Feb 2022 22:47:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=G3UblzcJ2E0Q5rT9yTB5YrTXE6UWL+sEXvXozapwrMM=; b=KDufDehIijGYvsfFz4Jt48U+JNFHBfbqG8ADK4zTdm3XUPdCCrUp2QKUSAkdW9v+vj AD2U8aO28Eci/cKeRB7NdJi7Yv15mamHZvGHIQOmkecn4FZM15bnEee55dshbAnisQD3 Sdjef+4tTYkm9WHrCEuqOxob6jFHuQd6T412W8Jkf7xBl0LdfuswXqC8aCmMe8/fC/h+ pnHENflxCukCutpQPKBAK4mcWzvfABCkDT0dpnq4MPDf2ygkGiTMNVQ3o+MVOdTEzwTk l0BwjsOo6Lf57xVig/Mx2qODlEzyQtXkD8aKpHm3d6AGdGEpu6ng7mHq1s7RK/W4S9b+ qOGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=G3UblzcJ2E0Q5rT9yTB5YrTXE6UWL+sEXvXozapwrMM=; b=7u6jdtyZdX6LYzoZOuylxixYn3vqZAXMywOoRew8IlYQDOCbcHEie5rBMWpXAP4RTC V0z1+m69NMpPAcFtCYx7KukirFGArvncg5WlrX6Pn8GZdWdQroorGoumlZPlmhj1bgRK saBZDGdASXLwzsddXsvpgq8ZuvRWohBlDClaf3ZwPEQAB+xecfvlVDVLzreOqOv3hgGo dX5SREpK4OgbM9ieFub7Eqt/ySDPBk2a5GSp0wGJ8EkAbQjEb56TeKUqY/fIJarGUDl5 HH+tjoENeBbDZmzzCBRkKa3//MQr0wI5TIM5MMVoI+4x6/RMDzwXBa6Ty3ZpON98QAdA MUWA== X-Gm-Message-State: AOAM530zr+9H1X58qX6Eur4o9HgZUzY9vS0WH/wQk8KeSaR1MTg4c2Oj mwytBVhFzQOd498k7qtdAJj1E2WUi6ZJK1pBG9oK7s/a X-Google-Smtp-Source: ABdhPJws7RUyVt4qD7R0aS4JhwUq2sNsrjy1dxw38iTEmSpZCU3L2KU3ofwkSwIv9i1UdL3Slkn7TIkvzRJWTDm58O4= X-Received: by 2002:a05:6e02:214a:b0:2bf:a442:cbff with SMTP id d10-20020a056e02214a00b002bfa442cbffmr1169622ilv.107.1645080431783; Wed, 16 Feb 2022 22:47:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Date: Wed, 16 Feb 2022 22:47:01 -0800 Message-ID: To: secdir@ietf.org, draft-rosen-rfcefdp-update-2026@ietf.org Content-Type: multipart/alternative; boundary="000000000000c373fa05d83122c5" Archived-At: Subject: [secdir] Secdir review of draft-rosen-rfcefdp-update-2026 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, 17 Feb 2022 06:47:44 -0000 --000000000000c373fa05d83122c5 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 memo simply documents a process change - the new ownership for RFC issuance. As such, there are no security considerations. Thanks, -- Magnus --000000000000c373fa05d83122c5 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 memo simply documents a process change - the new o= wnership for RFC issuance. As such, there are no security considerations.

Thanks,
-- Magnus
--000000000000c373fa05d83122c5-- From nobody Thu Feb 17 05:21:58 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 B49EF3A00DF for ; Thu, 17 Feb 2022 05:21:56 -0800 (PST) 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.45.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <164510411671.5422.16710542595847835643@ietfa.amsl.com> Date: Thu, 17 Feb 2022 05:21:56 -0800 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, 17 Feb 2022 13:21:57 -0000 Review instructions and related resources are at: https://trac.ietf.org/trac/sec/wiki/SecDirReview For telechat 2022-02-17 Reviewer LC end Draft Klaas Wierenga R2021-08-30 draft-ietf-alto-cdni-request-routing-alto For telechat 2022-03-03 Reviewer LC end Draft Aanchal Malhotra 2021-10-15 draft-ietf-kitten-tls-channel-bindings-for-tls13 Samuel Weiler R2021-08-25 draft-ietf-alto-path-vector Brian Weis 2021-08-19 draft-ietf-dnsop-svcb-https For telechat 2022-03-10 Reviewer LC end Draft Daniel Gillmor 2022-01-28 draft-ietf-rats-yang-tpm-charra Sandra Murphy 2022-03-07 draft-rsalz-2028bis For telechat 2022-04-07 Reviewer LC end Draft Daniel Migault 2021-06-28 draft-ietf-ipwave-vehicular-networking 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 Phillip Hallam-Baker R2022-02-23 draft-ietf-dprive-dnsoquic Steve Hanna 2022-01-24 draft-ietf-dots-telemetry 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 2021-06-28 draft-ietf-ipwave-vehicular-networking Kathleen Moriarty 2022-02-24 draft-ietf-ipsecme-ikev2-intermediate Russ Mundy None draft-iab-rfcefdp-rfced-model Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Sandra Murphy 2022-03-07 draft-rsalz-2028bis Hilarie Orman 2022-03-02 draft-ietf-tcpm-yang-tcp Radia Perlman 2022-02-28 draft-ietf-ace-aif Stefan Santesson 2021-08-11 draft-ietf-bier-te-arch Samuel Weiler R2021-08-25 draft-ietf-alto-path-vector Brian Weis 2021-08-19 draft-ietf-dnsop-svcb-https Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Klaas Wierenga R2021-08-30 draft-ietf-alto-cdni-request-routing-alto Liang Xia 2021-09-07 draft-ietf-bess-evpn-igmp-mld-proxy 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 Christopher Wood 2021-12-20 draft-ietf-opsawg-mud-iot-dns-considerations Next in the reviewer rotation: Derrell Piper Tirumaleswar Reddy.K Vincent Roca Kyle Rose Joseph Salowey Rich Salz Stefan Santesson Benjamin Schwartz Yaron Sheffer Rifaat Shekh-Yusef From nobody Sun Feb 20 20:15:32 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 9AEE23A0D37; Sun, 20 Feb 2022 20:13:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1645416809; bh=bvFLKMZx7jVgcfn4xxS1AuU7BD3aJGKH+vROd9pJIjA=; h=Date:To:From:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=V71oByap6E6UIAuCD3YVRxIzQL6I0UBbXjazpAtPmHC+BKINpp9l/h0F2UaOy+8Ig zwHcz4jIqMeBaMcFIno1/uKlTrZQ+kz4DokzL0qlZXNiRuosp+bbQ/7AxsJ8524Q9H iYbvOS3iEssZJ243+X8sGssmc+ahvl1ZZ4+s7XwM= X-Mailbox-Line: From new-work-bounces@ietf.org Sun Feb 20 20:13:28 2022 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E4A3A0D29; Sun, 20 Feb 2022 20:13:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1645416808; bh=bvFLKMZx7jVgcfn4xxS1AuU7BD3aJGKH+vROd9pJIjA=; h=Date:To:From:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=UeLkmwRBusr2qc45BM9Ym+LGwq8PTk5SOrZ7D15v5A4vVbKkKS02T2VMjoWJbYsZp 6iz8nCJj0RWrHNoGZuq8TVn+6P2r4FAlWg1rsNg7oOlPho+C1unc77tBcsj/508eUe yp1XfovbVX176eWyU6glX7nKHTX6hhAjPCZ+Uq6Y= 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 9840E3A0D29 for ; Sun, 20 Feb 2022 20:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.121 X-Spam-Level: X-Spam-Status: No, score=-0.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.781, 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 EAvDLazAtR4B for ; Sun, 20 Feb 2022 20:13:23 -0800 (PST) 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 CEC9A3A09E3 for ; Sun, 20 Feb 2022 20:13:23 -0800 (PST) Received: from moon.w3.org ([128.30.55.110] helo=[10.87.51.8]) by raoul.w3.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nM04e-0000AY-0T for new-work@ietf.org; Mon, 21 Feb 2022 04:13:20 +0000 Message-ID: <6fb3515c-0655-2c15-295c-55b888076657@w3.org> Date: Mon, 21 Feb 2022 12:13:16 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:91.0) Gecko/20100101 Thunderbird/91.5.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: Sun, 20 Feb 2022 20:15:30 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Audio Working Group (until 2022-03-21/22) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2022 04:13:33 -0000 SGVsbG8sCgpUb2RheSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcyByZWNl aXZlZCBhIFByb3Bvc2FsCnRvIHJldmlldyBhIGRyYWZ0IGNoYXJ0ZXIgZm9yIHRoZSBBdWRpbyBX b3JraW5nIEdyb3VwOgogwqAgaHR0cHM6Ly93d3cudzMub3JnLzIwMjIvMDIvYXVkaW8tMjAyMi1h Yy5odG1sCgpBcyBwYXJ0IG9mIGVuc3VyaW5nIHRoYXQgdGhlIGNvbW11bml0eSBpcyBhd2FyZSBv ZiBwcm9wb3NlZCB3b3JrCmF0IFczQywgdGhpcyBkcmFmdCBjaGFydGVyIGlzIHB1YmxpYyBkdXJp bmcgdGhlIEFkdmlzb3J5CkNvbW1pdHRlZSByZXZpZXcgcGVyaW9kLgoKVzNDIGludml0ZXMgcHVi bGljIGNvbW1lbnRzIHRocm91Z2ggMDM6NTkgVVRDIG9uIDIwMjItMDMtMjIKKDIzOjU5LCBCb3N0 b24gdGltZSBvbiAyMDIyLTAzLTIxKSBvbiB0aGUgcHJvcG9zZWQgY2hhcnRlci4KUGxlYXNlIHNl bmQgY29tbWVudHMgdG8gcHVibGljLW5ldy13b3JrQHczLm9yZywKd2hpY2ggaGFzIGEgcHVibGlj IGFyY2hpdmU6CiDCoCBodHRwczovL2xpc3RzLnczLm9yZy9BcmNoaXZlcy9QdWJsaWMvcHVibGlj LW5ldy13b3JrLwoKT3RoZXIgdGhhbiBjb21tZW50cyBzZW50IGluIGZvcm1hbCByZXNwb25zZXMg YnkgVzNDIEFkdmlzb3J5CkNvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMsIFczQyBjYW5ub3QgZ3Vh cmFudGVlIGEgcmVzcG9uc2UgdG8KY29tbWVudHMuIElmIHlvdSB3b3JrIGZvciBhIFczQyBNZW1i ZXIgWzFdLCBwbGVhc2UgY29vcmRpbmF0ZQp5b3VyIGNvbW1lbnRzIHdpdGggeW91ciBBZHZpc29y eSBDb21taXR0ZWUgUmVwcmVzZW50YXRpdmUuIEZvcgpleGFtcGxlLCB5b3UgbWF5IHdpc2ggdG8g bWFrZSBwdWJsaWMgY29tbWVudHMgdmlhIHRoaXMgbGlzdCBhbmQKaGF2ZSB5b3VyIEFkdmlzb3J5 IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZSByZWZlciB0byBpdCBmcm9tIGhpcwpvciBoZXIgZm9y bWFsIHJldmlldyBjb21tZW50cy4KCklmIHlvdSBzaG91bGQgaGF2ZSBhbnkgcXVlc3Rpb25zIG9y IG5lZWQgZnVydGhlciBpbmZvcm1hdGlvbiwgcGxlYXNlCmNvbnRhY3QgQ2hyaXMgTGlsbGV5LCBB dWRpbyBXRyBUZWFtIENvbnRhY3QsIGF0IDxjaHJpc0B3My5vcmc+LgoKVGhhbmsgeW91LAoKWHVl eXVhbiBKaWEswqAgVzNDIE1hcmtldGluZyAmIENvbW11bmljYXRpb25zCgpbMV0gaHR0cHM6Ly93 d3cudzMub3JnL0NvbnNvcnRpdW0vTWVtYmVyL0xpc3QKCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCm5ldy13b3JrIG1haWxpbmcgbGlzdApuZXctd29ya0Bp ZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldy13b3JrCg== From nobody Tue Feb 22 21:30:22 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 F38A33A0BFC; Tue, 22 Feb 2022 01:53:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1645523620; bh=/xMMPM8sjF24umjwZWV7xlFrFSLXnOVU8xSA7epPBiE=; h=Date:To:From:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=Fu2gNOprFhgsqYD7HT3EnDKZncILGDtSYMJoh0GKn96eMSun6Zjqd32xjE1IGsQaP VQJwRUVQ8fPFE721jz6mg0J3+A1KniK4fmT7sIeRYzZrWSNZ5Zsx+nRRyBQQ5eWudj jWy5XQ6Sh7UuVEchrAyiNrTJf4r6yVxI1MU1evh0= X-Mailbox-Line: From new-work-bounces@ietf.org Tue Feb 22 01:53:39 2022 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A75B3A0B11; Tue, 22 Feb 2022 01:53:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1645523619; bh=/xMMPM8sjF24umjwZWV7xlFrFSLXnOVU8xSA7epPBiE=; h=Date:To:From:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=Uxankk897JnwcOzOpxPsRJKwugS2TyqYReylygk/eMyt3/S40qtaFNhlJ/Z8rwmNI hVgRqUpSMLGp6d/xR3r4ijA8AZ96H6VllnLY9VNms/4bp97vqKwfd56qMMLyaba7/K bkqeB5kpQiP0J5Ti3N1+voFR1SVSa7SZluHTHvZY= 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 3D91C3A0B11 for ; Tue, 22 Feb 2022 01:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.12 X-Spam-Level: X-Spam-Status: No, score=-0.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.781, 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 46jD8GTen0Lg for ; Tue, 22 Feb 2022 01:53:33 -0800 (PST) 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 9E4953A094B for ; Tue, 22 Feb 2022 01:53:33 -0800 (PST) Received: from [221.212.226.202] (helo=[192.168.0.103]) by raoul.w3.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nMRrO-0001Jv-8w for new-work@ietf.org; Tue, 22 Feb 2022 09:53:30 +0000 Message-ID: Date: Tue, 22 Feb 2022 17:53:27 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:91.0) Gecko/20100101 Thunderbird/91.5.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: Tue, 22 Feb 2022 21:30:19 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Timed Text Working Group (until 2022-03-23/24) 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, 22 Feb 2022 09:53:43 -0000 SGVsbG8sCgpUb2RheSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcyByZWNl aXZlZCBhIFByb3Bvc2FsCnRvIHJldmlldyBhIGRyYWZ0IGNoYXJ0ZXIgZm9yIHRoZSBUaW1lZCBU ZXh0IFdvcmtpbmcgR3JvdXA6CiDCoCBodHRwczovL3d3dy53My5vcmcvMjAyMi8wMi9wcm9wb3Nl ZC10aW1lZC10ZXh0LXdnLWNoYXJ0ZXIuaHRtbAoKQXMgcGFydCBvZiBlbnN1cmluZyB0aGF0IHRo ZSBjb21tdW5pdHkgaXMgYXdhcmUgb2YgcHJvcG9zZWQgd29yawphdCBXM0MsIHRoaXMgZHJhZnQg Y2hhcnRlciBpcyBwdWJsaWMgZHVyaW5nIHRoZSBBZHZpc29yeQpDb21taXR0ZWUgcmV2aWV3IHBl cmlvZC4KClczQyBpbnZpdGVzIHB1YmxpYyBjb21tZW50cyB0aHJvdWdoIDAzOjU5IFVUQyBvbiAy MDIyLTAzLTI0CigyMzo1OSwgQm9zdG9uIHRpbWUgb24gMjAyMi0wMy0yMykgb24gdGhlIHByb3Bv c2VkIGNoYXJ0ZXIuClBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvIHB1YmxpYy1uZXctd29ya0B3My5v cmcsCndoaWNoIGhhcyBhIHB1YmxpYyBhcmNoaXZlOgogwqAgaHR0cHM6Ly9saXN0cy53My5vcmcv QXJjaGl2ZXMvUHVibGljL3B1YmxpYy1uZXctd29yay8KCk90aGVyIHRoYW4gY29tbWVudHMgc2Vu dCBpbiBmb3JtYWwgcmVzcG9uc2VzIGJ5IFczQyBBZHZpc29yeQpDb21taXR0ZWUgUmVwcmVzZW50 YXRpdmVzLCBXM0MgY2Fubm90IGd1YXJhbnRlZSBhIHJlc3BvbnNlIHRvCmNvbW1lbnRzLiBJZiB5 b3Ugd29yayBmb3IgYSBXM0MgTWVtYmVyIFsxXSwgcGxlYXNlIGNvb3JkaW5hdGUKeW91ciBjb21t ZW50cyB3aXRoIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlLiBGb3IKZXhh bXBsZSwgeW91IG1heSB3aXNoIHRvIG1ha2UgcHVibGljIGNvbW1lbnRzIHZpYSB0aGlzIGxpc3Qg YW5kCmhhdmUgeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRpdmUgcmVmZXIgdG8g aXQgZnJvbSBoaXMKb3IgaGVyIGZvcm1hbCByZXZpZXcgY29tbWVudHMuCgpJZiB5b3Ugc2hvdWxk IGhhdmUgYW55IHF1ZXN0aW9ucyBvciBuZWVkIGZ1cnRoZXIgaW5mb3JtYXRpb24sIHBsZWFzZQpj b250YWN0IEF0c3VzaGkgU2hpbW9ubywgVGltZWQgVGV4dCBXRyBUZWFtIENvbnRhY3QsIGF0IDxh dHN1c2hpQHczLm9yZz4uCgpUaGFuayB5b3UsCgpYdWV5dWFuIEppYSzCoCBXM0MgTWFya2V0aW5n ICYgQ29tbXVuaWNhdGlvbnMKClsxXSBodHRwczovL3d3dy53My5vcmcvQ29uc29ydGl1bS9NZW1i ZXIvTGlzdAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cm5ldy13b3JrIG1haWxpbmcgbGlzdApuZXctd29ya0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldy13b3JrCg== From nobody Wed Feb 23 01:47:58 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 CDFAC3A0840; Wed, 23 Feb 2022 01:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.596 X-Spam-Level: X-Spam-Status: No, score=-9.596 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_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=D4PGyjgo; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=aURxi10I 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 VdL-P1hCVOKI; Wed, 23 Feb 2022 01:47:51 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E336F3A0124; Wed, 23 Feb 2022 01:47:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2484; q=dns/txt; s=iport; t=1645609670; x=1646819270; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1nE4PEznGN4iYFsZTIBPXxslfYVF7JUqw0xxCYCwjhk=; b=D4PGyjgorB6W74m8WOL+tDUd3DFzb38b8jLG53z1Ldy1VFn3HrJR8jwj Ebtv0uJxPJBvoy9MZ31xqph6hmOF6YIx2mP6IvwYjb7OTCd/X9+Rr//p1 mrvob5d9sXlPBAsbAGUAeRsNC9IVyHykISrDug1GWtRyRD2h/PqeRg26T 0=; IronPort-PHdr: =?us-ascii?q?A9a23=3Ab8k3MBbinmJiCinOMdBc+dD/LTAphN3EVzX9o?= =?us-ascii?q?rIriLNLJ6Kk+ZmqfEnS/u5kg1KBW4LHo+lFhOzbv+GFOyQA7J+NvWpEfMlKU?= =?us-ascii?q?BkI2skTlhYrVciCD0CzJfX2bis8ScJFUlIt/3yyPUVPXsjkYFiHqXyp5jlUE?= =?us-ascii?q?RL6ZmJI?= IronPort-Data: =?us-ascii?q?A9a23=3A7hBt8KsDyS2Jl2Ze//KBC92jEOfnVIBcMUV32?= =?us-ascii?q?f8akzHdYApBsoF/qtZmKT3TMqmOYWvweI8nYN7i9B9QsZOHnIdkTlNlqHw3Q?= =?us-ascii?q?SpBgMeUXt7xwmUckM+xwmwvdK/shiknQoGowPscEzmM9n9BDpC79SMmjfvQH?= =?us-ascii?q?+KlYAL5EnkZqTFMGX9JZS1Lw4bVsqYw6TSIK1vlVeHa+qUzC3f9s9JACV/43?= =?us-ascii?q?orYwP9ZUFsejxtD1rA2TagjUFYzDBD5BrpHTU26ByOQroW5goeHq+j/ILGRp?= =?us-ascii?q?gs1/j83Ad+j1738aEBPH/jZPBOFjTxdXK3Kbhpq/3NplP1kcqtHLx4K1V1ln?= =?us-ascii?q?PgpoDlJnZGuWAEiPaDkk+UGWB4eGCZ7VUFD0OafeSDi6pDPnxSun3zEhq8G4?= =?us-ascii?q?FsNFZYV8ep2G0lP+OAWbjcXYXiri/i/zq7+S+RwiIEvNNPqIo5atnd7yijED?= =?us-ascii?q?P0OQJ3fTePN/9Aw9Ds2nYVWB/fAbsEIQTticBqGZAdAUmr7orpWcPyAnHLzd?= =?us-ascii?q?XhTr0iY4Pdx6GnIxws327/oWOc5s+eiHa199nt0bEqfl4ghPiwnCQ=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3ASUmXl66HmlfVWPeMeQPXwZKCI+orL9Y04l?= =?us-ascii?q?Q7vn2ZFiY1TiXIra6TdaoguiMc0AxhJ03Jmbi7Sc69qeu1z+813WBjB8bdYO?= =?us-ascii?q?CAghrpEGgC1/qt/9SEIU3DH4FmpNxdmsRFebjN5B1B/LrHCWqDYpUdKbu8gd?= =?us-ascii?q?qVbI7lph8HJ2wHGsIQjTuRSDzrb3GeLzM2Y6bRYaDsnvav0ADQAEj/AP7LYk?= =?us-ascii?q?UtbqzmnZnmhZjmaRkJC1oM8w+Vlw6l77b8Dlyxwgoeeykn+8ZhzUH11yjCoo?= =?us-ascii?q?mzufCyzRHRk0XJ6Y5NpdfnwtxfQOSRl8kuLCn2gArAXvUlZ1TChkFwnAic0i?= =?us-ascii?q?dtrDD+mWZ4Ay210QKIQoiBm2qr5+An6kd015at8y7DvZKpm72JeNtzMbswuW?= =?us-ascii?q?seSGqF16Ll1+sMj56iGAmixsZq5Fr77VbAD5KjbWAYqmOk5XUliuIdlHpZTM?= =?us-ascii?q?8Xb6JQt5UW+AdPHI4HBz+S0vFrLABCNrCW2B9tSyLRU5kZhBgY/PW8GnAoWh?= =?us-ascii?q?uWSEkLvcKYlzBQgXBi1kMdgMgShG0J+p4xQ4RNo72sCNUmqJheCssNKa5tDu?= =?us-ascii?q?YIRsW6TmTLXBLXKWqXZVDqDrsONX7Bo4P+pL81+OapcpoVy4ZaouWMbHpI8W?= =?us-ascii?q?opP07+A8yH25NGthjLXWWmRDzojtpT4pBo04eMDIYD8RfzAWzGv/HQ18n3WP?= =?us-ascii?q?erLspbEKgmdMPeEQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A7BgATH/lh/5xdJa1aHgEBCxIMQIF?= =?us-ascii?q?PC4FSVgd3WjcxhEmDRwOFOYUOgwIDmySBLhSBEQNUCwEBAQ0BASoNCgQBAYU?= =?us-ascii?q?FAheDSAIlNAkOAQIEAQEBEgEBBQEBAQIBBgSBCROFaA2GQgEBAQEDAQEQERE?= =?us-ascii?q?MAQEsCwELBAIBCBEDAQIDAiYCAgIlCxUICAIEAQ0FIoJiAYJlAy4BDqItAYE?= =?us-ascii?q?6AoofeoExgQGCCAEBBgQEgTYBE0GDAhiCNwMGgRAqgw6EHocHJxyBSUSBPAw?= =?us-ascii?q?Qgmc+gmMBAQOBKAELBgIBgzg3gi6RNnJjBFMgAi0JAz1qERmSP4NbjU5CnBE?= =?us-ascii?q?Kg0aLAZRcBS6Dcowcl3mWSiCMb5kzAgQCBAUCDgEBBoFhPGlwcBU7KgGCCgE?= =?us-ascii?q?BMlEZD44gg3GFFIVKdDgCBgEKAQEDCYsGgWldAQE?= X-IronPort-AV: E=Sophos;i="5.88,333,1635206400"; d="scan'208";a="1000534481" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Feb 2022 09:47:48 +0000 Received: from mail.cisco.com (xbe-rcd-001.cisco.com [173.37.102.16]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 21N9lmVr013397 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 23 Feb 2022 09:47:48 GMT Received: from xfe-rcd-004.cisco.com (173.37.227.252) by xbe-rcd-001.cisco.com (173.37.102.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Wed, 23 Feb 2022 03:47:48 -0600 Received: from xfe-aln-004.cisco.com (173.37.135.124) by xfe-rcd-004.cisco.com (173.37.227.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Wed, 23 Feb 2022 03:47:48 -0600 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Wed, 23 Feb 2022 03:47:48 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VbKblT/1naRCfkeUVfgWlBEhjE+t9CfL8B9oQ9OvF/QgIPxpbPergNrUo3mrHoOHndnEreyIdHZxt7134xQx4uxaxkSeye2c66VWbvoopX1IRh5AjaQqmIPh8ofsPZE99eahtDeoMGmElVRAQfuQI8BKwt7GYUzHHpxK3HGksG8uyJm4meFoTJBKS8VRdOtb1FzdIQTYZuLSyV4G8HkbRuc3Qub7trIJEbP5hjs++m1eVGG7lrFnHsLQaPLBsfpGVnoUM1ISC+H2xCtV9ll/qQhphwYci3YmORx1hJ0O0y/FAv7bm7QXI/36+1Rmou9FRpzapR6KmvhKy/PNr+jqRQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1nE4PEznGN4iYFsZTIBPXxslfYVF7JUqw0xxCYCwjhk=; b=Sd9VDdFTKemmDuD5R6Ke7td60dkSwYYD6bxznM55owJygEGmC8DAIX1iYShmXLlGV/OC2EvG8PdVJkTrW++9E6x1NXqFobVCX8tKLwBw6QV8NVxx540EkHwbvrSjQUWejWKH8pNlnoYaNgGu1NPP5We+LPAma3oTMWCpZ5Kg/xAIxPAfRZ4niRIRx6AS/RCQGtynBTbRAZSIF0R+BEhQLFh0HZttiaFB18bIGyLYYyNTiv5zsOzXnbfVU+rpBSTzzkGFATa8e9awQu/mfp9l1qI+bhidKdR8yPwzWMaGMFWXXBXPwDtfX8dc7BkvWB7McaH0kF2hW29gdYvwdP7gsQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1nE4PEznGN4iYFsZTIBPXxslfYVF7JUqw0xxCYCwjhk=; b=aURxi10IppFLk4V9WbIpX19Pa19aTB3Em2tjpqsYwVffuc9Jk87Cj0JVYwO8B/Mz3y6Zm2qFwW7jpnUWwzakdfowt1NtJdXY/2GrBz/5aT5X/O3hhR2ijVsSZ7gFB2iTF80/D6VMXiqlIt/OWjTL19qqgFL/BqhD9Y7izuzeFkA= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by SN6PR11MB2639.namprd11.prod.outlook.com (2603:10b6:805:59::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.17; Wed, 23 Feb 2022 09:47:46 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::1929:3b1b:99a3:312]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::1929:3b1b:99a3:312%9]) with mapi id 15.20.5017.023; Wed, 23 Feb 2022 09:47:46 +0000 From: "Eric Vyncke (evyncke)" To: "dns-privacy@ietf.org" , "draft-ietf-dprive-dnsoquic@ietf.org" CC: "secdir@ietf.org" Thread-Topic: [dns-privacy] Last Call Expired: Thread-Index: AQHYKJFo3hxOBTaNuESNokgmcF5Mqayg9HIA Date: Wed, 23 Feb 2022 09:47:46 +0000 Message-ID: References: <164560577744.20656.12177163965188019338@ietfa.amsl.com> In-Reply-To: <164560577744.20656.12177163965188019338@ietfa.amsl.com> Accept-Language: fr-BE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.58.22021501 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1ff3722c-29f9-452c-3494-08d9f6b18c0c x-ms-traffictypediagnostic: SN6PR11MB2639:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yOUxM7CpqhJpRTzENfcSOV0aTmpHra6V+ZUVWcQ9gB0AyqqZphZRhEomzW7HhlSi3518XBGFucrtspa5mZU69i+bb7751e7BypMlDqGXyvYYk5O93ZE4z3iCkATt1INCGgYZc1/6hrcBXXvSTVH7JcX2KsgyOpVZvwOCekdJt71Cf0ZNeXiy17oRkFmdzyUiiDVmyk5xJCljAuFvZpdoh8HI5gWxHzyPc4GyVHy9KoBttjJYz//mrDgsOa/1wNWXiQtWuQDnI1xUKJXy+2ZvmRxPSNiKkylFLyaXNmvka2tKMBWooxOZPgBZRCnINniHYrRM9qe+LaJrSNUSz2U5a5YOGINBilfe7xz4JVqXeXkJI8za48qJjbscsLVi2RgLTc2DJmJGHU5KZu0+86D9B4CrNBgHN1NXOikhnUEcaChb0s08dixHhJkYkXaM+JuAft0X2fXdSHMg1faEsg0C8JId+nxa3JndLCTTnFY4dK+hdrOp5whiTvSWXudNbltE2eOTZ/CDLWX/rL9dCvLaug+d06hga+xUYXxdLmvRZ3jnCBqhSlx6QTHSFA2FyYpUNeiWoGYH+UCKVea7xTxDk/AO0x6IRQeI27g77gB+c1WliNoq7+UJyfte4NF1LOk8mpF2xa0lhCFI8taDK5fHhEcUX3oGZ0S+2Va+HOMssLGKpp+9rIFadFg8tAWrnz1I6EVHh7YYNXE15EnwCtNdsEGAg9GcCmUORC50IvPfBwkbSSdGZEwWwaiTg8UiWu2zSAiTjD0QLaksZHuTMXe9wp+S3UoixDDya7CzKTu1Nz25nG5AvegBPpcz/VIGmhANTLQCdT87NfHFyarKRJPw7mwe6gH/THdFDtUmegrPfaI= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(66556008)(83380400001)(38100700002)(71200400001)(186003)(2906002)(8936002)(86362001)(122000001)(36756003)(38070700005)(110136005)(33656002)(64756008)(6486002)(316002)(508600001)(2616005)(5660300002)(53546011)(6506007)(66446008)(6512007)(8676002)(91956017)(4326008)(966005)(76116006)(66946007)(450100002)(66476007)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?L0VwT0xXYU0xSGRma0ZrWHR6U1B3dnZXSW9SWTZhQmZsakRrNUExdzZNTkNn?= =?utf-8?B?bUM1QVM4NzJlYk5LVWZUcjNnR1BvQStxclc5U1g4K2VHN0p5VlhGWE12OHQ5?= =?utf-8?B?VU5nNm81VUVwSGFqWmFvN1pEcVp2dTg3YnEyK1F2Zm9HaXNYWVpNN2Nuc05s?= =?utf-8?B?a3g5a3ZwOElhcmxFN2lFWHY4bW1LbVpEWis3ZW50eVdscUdhM3lNK0lvNTRX?= =?utf-8?B?bjQvelVLN0pQWDJGQ2FjUFo0YjkvMjVtSmdFVEZlWEk0VGlwYStjOWYwMEZm?= =?utf-8?B?cFo2Z3BCc3dPRGxDNk1ZMzlPejNPQjJ0ZmxMMUFyZW1Jb2JCcU1jaUFzS1NQ?= =?utf-8?B?ZUl3VEZWZWNUb3Fnd3M0MFQyT3hWYmJVTEVBMFNVOFlmeXVNbFd2SnU1cEZB?= =?utf-8?B?R3BXb1RQc0pvbFdqMWZZNUt6Y2VpSG1PMGZHdGNUbW9GRjlGRC90UmcrNlQ5?= =?utf-8?B?ZTI1Rlp1bHg5dUordVNjQ2N1RnJ4MFZjRGJnbWJuSWRmNVordHR6c2xKWjVn?= =?utf-8?B?a2xaNU1VbDRmcDF5cllvTldlWDhHdjAwVU5YYmRlUTQrbWZpaFBmM0ZQUXh6?= =?utf-8?B?RWRIVTFFcWdVWnV3clB3aWFRVExndVZ1cVlONjRCQjdYN0hIZTNNYXVKRzk1?= =?utf-8?B?UUVQT0x2MTNaNEYwR2dCL3paRUVzK0U5UjNadWtyVXZ5NHFUVCtwUnFLa2pZ?= =?utf-8?B?WDNZTjdNL2JOMmZDQ1dJdWdNajVNVVFrdW9mSHlGcEV5eE41L2hNTnVPSlFX?= =?utf-8?B?U3VHaEZYZEk0Z3N1WXhrTlFHZVNuMVN4endkRStwUlVQaStLZDZoTjJyV2ZP?= =?utf-8?B?bEd3YmZ6aVBDeU9QcVZCL1NrKzRkc1Z6YTcxMktiWTNXSTBEYVNhd29qdnJE?= =?utf-8?B?cHJraWZYbkhjOHp5ak5SWGlYYW5GeEt5VVlySEQrcktlaUNnVG42aWEwK2V5?= =?utf-8?B?ZkM5UmpvOUxRNjhjYjRRNHFGOGxlMkZWWlh0cklET0IxaVFhWWVrYVZPRHFT?= =?utf-8?B?b2tmZTNFUDFvYTB0aW1SMHI5RUtWQmZrWm1FR1RScWp0ZUNydWlkWExaS0Zu?= =?utf-8?B?OEp2L2k5T1ZPWEJ0UVl3cllCNFQrK2kvYjY2VTRwdlpGUmd2WkpkZU1rOHJa?= =?utf-8?B?QjFBY2NVdlpHQ3c0OTlCZGJTa2lSVzRWUlhtbEpCaFlFMEtucWtUcTJLWU5X?= =?utf-8?B?UjVkeWdBWjhLMWtDeUhqZUlXZkp1VG1jWVNFTGwvdlJpYnluVTlrTUVwSFJ1?= =?utf-8?B?dTRDOVl2c0ZlTGRuQi9rQWx0QmRKVXo3MmFEWU5Bbkp1NEE4cXhTc0J1ZGJ5?= =?utf-8?B?NFZkMVJSWUJXQkpPamJoa2FzKzNHUEhWaTYxL0lPa3hLV3F0bnRwQUdWVzAy?= =?utf-8?B?MUkzSVl0cUYvMll1eG91R3ZKUHJ4bUJwdldpR1luZHQ2N01BbWZ0M2VJNzhT?= =?utf-8?B?cXo2OGZHOVZBTTVVbWZYeUM5OFUremJOOWdubFp0Wko4ellkU0swRnBieGM0?= =?utf-8?B?Z2FTaXdWYk1BQWt6SGs3M1Mxb1I5eTl2U0lVVHEzWUxVWUFtNEw1YlduVVBR?= =?utf-8?B?RnIvOG9ubi9xYVRtMTYrQml2UzdOVFNWQ1J5bzBHYzZCcVRjR3I0cVdlVWdB?= =?utf-8?B?ZS9WbkFvOWhjUGhoajZkdm9tQzhqeEwwM2VqbUpickJYZy9DOHJ5UUpBYzQy?= =?utf-8?B?M1JJZjIzbkc3bjhwaGdzWk5qVFY5UUprdGdIQ09yYjJpQ2JnRW4wUklHQU1K?= =?utf-8?B?NjNqQmUwQzdLUmJ0aEZldk9HRGkwc0FTdnd2V3VacGxZWmJpTVRsTGxiZERo?= =?utf-8?B?cTF3SUxSU1UyNnNOVzlVSVluajQ0YkgzVkx4VTZ0MUtzU1F4Zkd2MTB0KzdV?= =?utf-8?B?dEZrRXV3Q2t6UWZkQWk5Nk9Gak1JMEFwOEVoM0tZYmJXR2JTaFVDNjRpMkw1?= =?utf-8?B?WndLTmJQN3orY3JRQlJqeVozVjJBcU9EbjVlQXZSY1hvMjBlNjFTa3RkbXIv?= =?utf-8?B?VFo3eGdac3dLQ2V2MncxWE1UN1FmZjlMNmdVVUloZXQ0dUxKVWxzMmFaZzl6?= =?utf-8?B?RUc1VkdoV3JPV0lxMm5hd3M1c1FXNnhsLzhVdTA3QzhWankvZyszRVhmQ1Np?= =?utf-8?B?UUpZQ0Q4Z1JGQmsxR0ZhdHpNMSt0UUtqQXNITkFSLzI1UWVKTHdDQ2ZxcklC?= =?utf-8?B?b0lveS8vQ3NIZk1CQVhaQlVLL3diQk5ZK1NRbitzM1o0Yzd3dXd4QnQ3WEpl?= =?utf-8?Q?kCV0SUxHX96f3e+/aXcZ4FR25LZTPheF5NWzWP77Z8=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1ff3722c-29f9-452c-3494-08d9f6b18c0c X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2022 09:47:46.7783 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NxKEDdlQCJ56bRo3/vQgvayRscn37u+I2OYtZtDbskPTgHlEAf3Wg3lnWVIkXqe/M1jsdona9PAkHpvXdEwYrQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2639 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xbe-rcd-001.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [secdir] [dns-privacy] Last Call Expired: X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2022 09:47:56 -0000 VGhlIElFVEYtd2lkZSBsYXN0IGNhbGwgaGFzIGV4cGlyZWQgYW5kIEFGQUlLIHRoZXJlIHdhcyBv bmx5IG9uZSBkZXRhaWxlZCByZXZpZXcgYnkgUGhpbGxpcCBIYWxsYW0tQmFrZXIgZm9yIHRoZSBz ZWN1cml0eSBkaXJlY3RvcmF0ZSAoYWRkZWQgaW4gY2MpOg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5p ZXRmLm9yZy9hcmNoL21zZy9sYXN0LWNhbGwvTDIzYldPeFA1NE5aUVBIVDdEZlJCeFpBT0N3Lw0K DQpXaGF0IGlzIHRoZSBhdXRob3JzL1dHIHBsYW4gdG8gYWRkcmVzcyB0aGUgImhhcyBpc3N1ZXMi IG9mIHRoaXMgcmV2aWV3ID8gWW91IHByb2JhYmx5IGtub3cgdGhhdCB0aGUgY3V0LW9mZiBkYXRl IGlzIE1vbmRheSA3dGggb2YgTWFyY2guDQoNCkFzIGEgcGxhaW4gZW5naW5lZXIgKGFuZCB3aXRo b3V0IGFueSBoYXQpLCBpdCBhcHBlYXJzIHRvIG1lIHRoYXQgdGhlIFdpLUZpIGhvdHNwb3QgaXNz dWUgaXMgbm90IGxpbWl0ZWQgdG8gRG9RIGJ1dCBpcyBhbHNvIHJlbGV2YW50IHRvIERvSC4gQW5k IHRoZSB0cmFmZmljIGFuYWx5c2lzIHBhcnQgaXMgcHJvYmFibHkgYWRkcmVzc2VkIGFscmVhZHkg d2l0aCB0aGUgcGFkZGluZy4gDQoNCldpdGggbXkgQUQgaGF0LCB0aGUgcG9pbnRzIGFib3V0ICdv dXRkYXRlZCcgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYW5kIHByaXZhY3kgdnMuIGNvbmZpZGVu dGlhbGl0eSBzaG91bGQgYmUgYWRkcmVzc2VkIGluIHRoZSBkb2N1bWVudCAoaGFwcHkgdG8gYmUg Y29ycmVjdGVkIG9mIGNvdXJzZSkuIEFueXdheSwgaXQgd291bGQgYmUgbmljZSB0byBhbnN3ZXIg dG8gUEhCLg0KDQpSZWdhcmRzDQoNCi3DqXJpYw0KDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBkbnMtcHJpdmFjeSA8ZG5zLXByaXZhY3ktYm91bmNlc0BpZXRmLm9yZz4g b24gYmVoYWxmIG9mIERyYWZ0VHJhY2tlciBNYWlsIFN5c3RlbSA8aWVzZy1zZWNyZXRhcnlAaWV0 Zi5vcmc+DQpEYXRlOiBXZWRuZXNkYXksIDIzIEZlYnJ1YXJ5IDIwMjIgYXQgMDk6NDMNClRvOiAi YnJpYW5AaW5ub3ZhdGlvbnNsYWIubmV0IiA8YnJpYW5AaW5ub3ZhdGlvbnNsYWIubmV0PiwgImRu cy1wcml2YWN5QGlldGYub3JnIiA8ZG5zLXByaXZhY3lAaWV0Zi5vcmc+LCAiZHJhZnQtaWV0Zi1k cHJpdmUtZG5zb3F1aWNAaWV0Zi5vcmciIDxkcmFmdC1pZXRmLWRwcml2ZS1kbnNvcXVpY0BpZXRm Lm9yZz4sIEVyaWMgVnluY2tlIDxldnluY2tlQGNpc2NvLmNvbT4NCkNjOiAiaWVzZy1zZWNyZXRh cnlAaWV0Zi5vcmciIDxpZXNnLXNlY3JldGFyeUBpZXRmLm9yZz4NClN1YmplY3Q6IFtkbnMtcHJp dmFjeV0gTGFzdCBDYWxsIEV4cGlyZWQ6IDxkcmFmdC1pZXRmLWRwcml2ZS1kbnNvcXVpYy0wOS50 eHQ+DQoNCg0KICAgIFBsZWFzZSBETyBOT1QgcmVwbHkgdG8gdGhpcyBlbWFpbC4NCg0KICAgIEkt RDogPGRyYWZ0LWlldGYtZHByaXZlLWRuc29xdWljLTA5LnR4dD4NCiAgICBEYXRhdHJhY2tlciBV Ukw6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZHByaXZlLWRu c29xdWljLw0KDQogICAgSUVURiBMYXN0IENhbGwgaGFzIGVuZGVkLCBhbmQgdGhlIHN0YXRlIGhh cyBiZWVuIGNoYW5nZWQgdG8NCiAgICBXYWl0aW5nIGZvciBBRCBHby1BaGVhZC4NCg0KDQogICAg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBkbnMt cHJpdmFjeSBtYWlsaW5nIGxpc3QNCiAgICBkbnMtcHJpdmFjeUBpZXRmLm9yZw0KICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zLXByaXZhY3kNCg0K From nobody Wed Feb 23 02:17:52 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 CC2023A09AC; Wed, 23 Feb 2022 02:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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=sinodun.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 26Ly8dqn14Ef; Wed, 23 Feb 2022 02:17:28 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ED583A0938; Wed, 23 Feb 2022 02:17:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sinodun.com ; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=0xMOTftQdFn7ZukaAyqW+oCE1ci31HE8ZfhS3+nXZv8=; b=bCkFKOv1xhvCFVZUQeo8qcsLg3 mMo6G3CxYhDnZ02uFnbGRiDWkAUTDvBKyy58Rf6T9KD0cPVSsBC9iuuQMWmo2iax4lyPxqY9HT0ky 5Ydwx/hs0nr8rCvVwq3aNwZ6PPgvi0YqpjxwaFnbZX33J0X24t4JdsaTiCzH4NuX5YDQLtFu90dg1 iwUfxYHqYnhgTH5ndy6wSPxfDNmvOF9w7h+5hO6n02VxTaWMJU5HPd6Ym3CtzKiDBRQpCt4eN8HNs je78Vdhh9P8xv2Vu5N8xYYsq76CfhraEAYpeK9PKtACMv6HA6vv70kqDCLKIBt44meyC9j3yuaxZE oeFyppGw==; Received: from [82.68.3.134] (port=10787 helo=smtpclient.apple) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1nMoi5-0003Ai-LF; Wed, 23 Feb 2022 10:17:26 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Sara Dickinson In-Reply-To: Date: Wed, 23 Feb 2022 10:17:16 +0000 Cc: "dns-privacy@ietf.org" , "draft-ietf-dprive-dnsoquic@ietf.org" , "secdir@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <164560577744.20656.12177163965188019338@ietfa.amsl.com> To: "Eric Vyncke (evyncke)" X-Mailer: Apple Mail (2.3654.120.0.1.13) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [secdir] [dns-privacy] Last Call Expired: X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2022 10:17:36 -0000 Hi Eric,=20 The authors did ask Phillip directly if he had specific text changes he = would like to see following his review during the first IETF Last Call: = https://mailarchive.ietf.org/arch/msg/dns-privacy/Iu7lg5AvF9Mx4Tu-gflASArO= F8A/ However we did not get a reply and so we attempted to address that = review in the -09 update (published on 9th February) based on a github = issue with discussion points and a PR referenced in this email: = https://mailarchive.ietf.org/arch/msg/dns-privacy/oRHkyjhupzQj0HApzLprvE4V= 7_s/ Since we didn=E2=80=99t get any further feedback on this review during = the second IETF LC, I=E2=80=99m hoping those updates addressed the = points raised. FYI - we have a pending PR to fix the minor issue noted in the latest = IANA review, which was the only comment we got during the second IETF = LC. So we=E2=80=99ll publish the -10 update with this correction = shortly. Regards Sara.=20 > On 23 Feb 2022, at 09:47, Eric Vyncke (evyncke) = wrote: >=20 > The IETF-wide last call has expired and AFAIK there was only one = detailed review by Phillip Hallam-Baker for the security directorate = (added in cc): > = https://mailarchive.ietf.org/arch/msg/last-call/L23bWOxP54NZQPHT7DfRBxZAOC= w/ >=20 > What is the authors/WG plan to address the "has issues" of this review = ? You probably know that the cut-off date is Monday 7th of March. >=20 > As a plain engineer (and without any hat), it appears to me that the = Wi-Fi hotspot issue is not limited to DoQ but is also relevant to DoH. = And the traffic analysis part is probably addressed already with the = padding.=20 >=20 > With my AD hat, the points about 'outdated' security considerations = and privacy vs. confidentiality should be addressed in the document = (happy to be corrected of course). Anyway, it would be nice to answer to = PHB. >=20 > Regards >=20 > -=C3=A9ric >=20 >=20 > =EF=BB=BF-----Original Message----- > From: dns-privacy on behalf of = DraftTracker Mail System > Date: Wednesday, 23 February 2022 at 09:43 > To: "brian@innovationslab.net" , = "dns-privacy@ietf.org" , = "draft-ietf-dprive-dnsoquic@ietf.org" = , Eric Vyncke > Cc: "iesg-secretary@ietf.org" > Subject: [dns-privacy] Last Call Expired: = >=20 >=20 > Please DO NOT reply to this email. >=20 > I-D: > Datatracker URL: = https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/ >=20 > IETF Last Call has ended, and the state has been changed to > Waiting for AD Go-Ahead. >=20 >=20 > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy >=20 From nobody Wed Feb 23 04:05:38 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 11C393A0C46; Wed, 23 Feb 2022 04:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.596 X-Spam-Level: X-Spam-Status: No, score=-9.596 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_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=DiUBayW+; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=zPdwajRa 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 PNK7CQnUyf01; Wed, 23 Feb 2022 04:05:30 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA3593A0C45; Wed, 23 Feb 2022 04:05:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5018; q=dns/txt; s=iport; t=1645617929; x=1646827529; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=VB2C4jvPe5aeHLpgQa7xeV2dSXNFGLm3tNAOUSYZBTU=; b=DiUBayW+SNHBAxuMQoa9i8UEzWtIk2i69PIWM70+qu8yjMQBeipFe1i8 vuQpb+DXvc6P8/YvVYZv1OZEmC/RGGE1c47zPhwlk5KCMaR4/DnPV98sO Ak0jX+QMkmNQNVwYWmKIFgZsd9mBjsldTrCgwSQeSrbkqPJXe8W4Ezd6e M=; IronPort-PHdr: =?us-ascii?q?A9a23=3AEm810BR4GNibqd55pq9E+FBQj9pso7vLVj580?= =?us-ascii?q?XJvo75Nc6H2+ZPkMQSf4Ph2l1bGUM3d7O4MkOvZta3sGAliqZaMuXwPatpAA?= =?us-ascii?q?hkCj8hFkwkpGsXQD0r9IbbjZDA7G8IXUlhj8jm7PEFZFdy4aUfVpyi57CUZH?= =?us-ascii?q?VP0Mg8mTtk=3D?= IronPort-Data: =?us-ascii?q?A9a23=3AixresKyi0OrgOIye8gJ6t+fWxCrEfRIJ4+Muj?= =?us-ascii?q?C+fZmUNrF6WrkUCyDdLXzuAO/nZZTbzeNonaIW/8BgCupSEx942QAs9pFhgH?= =?us-ascii?q?ilAwSbn6Xt1DatR0xt/paQvdWo/hyklQoSGfJBcokP0/E/3aOC79SAkjMlke?= =?us-ascii?q?5KlYAL6EnEpLeNbYH9JZSJLw4bVs6Yw6TSLK1rlVeDa+6UzDGSYNwtcaQr43?= =?us-ascii?q?U4sRCRH55wesBtA1rA3iGsiUFX2zxH5B7pHTU29wueRf2VaIgK6b76rILCR5?= =?us-ascii?q?GjV+VImDcmo1+i9eUwRSbmUNg+L4pZUc/H92V4Z+WpjieBiaaV0hUR/011lm?= =?us-ascii?q?/h81sRLvp+9YQwoJabL3u8aVnG0FgkhZ/wZpuOcfyTXXcu7iheun2HX6+5jB?= =?us-ascii?q?003J6UZ9/p5R2ZU+pQwJCoEYAzGhu+qzve3UvNtmMlmIM/wO5oCu3pIzDzFA?= =?us-ascii?q?7AhW5+ra6nM/ppAxjYuj8tfNffTe8RfbiBgBDzbagdGEkwWDpUygeHujX76G?= =?us-ascii?q?wC0Anr9SbEf+WPfykl616LgdYSTcd2RTsITlUGdzl8qNl/RWnkyXOFzAxLem?= =?us-ascii?q?p50utLyoA=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3ARi30C6xTaS1W0l9HSPNsKrPxdugkLtp133?= =?us-ascii?q?Aq2lEZdPULSK2lfpGV8sjziyWatN9IYgBepTiBUJPwJk81bfZOkMgs1MSZLX?= =?us-ascii?q?fbUQyTXcFfBOrZsnPd8kjFltK1up0QCJSWZOeAaGSSyPyKnDVQcOxQg+Vvkp?= =?us-ascii?q?rY/9s2pk0FJWoBBs0QjHYaNu/YKDwKeOAsP+teKHPo3Ls+m9PWQwVvUi3UPA?= =?us-ascii?q?hgY8Hz4/nw0L72ax8PABAqrCOUiymz1bL8Gx+Emj8DTjJm294ZgCr4uj28wp?= =?us-ascii?q?/mn+Cwyxfa2WOWxY9RgsHdxtxKA9HJotQJKw/rlh2jaO1aKvi/VXEO0aWSAW?= =?us-ascii?q?QR4Z/xSiQbTp1OArTqDzmISC7Wqk7dOfAVmiTfIBGj8CHeSIfCNUMH4oJ69P?= =?us-ascii?q?Jkm13imhcdVBUW6tMV44pf3KAnUS8o1R6NleQhHXtR5zmJiGtnnugJg3NFV4?= =?us-ascii?q?wCLLdXsIwE5UtQVIwNBSTg9ekcYaRT5eznlb1rmGmhHjrkV6hUsaqRd2V2Gg?= =?us-ascii?q?3DTlkJu8ST3TQTlHdlz1EAzMhamnsb7poyR5RN+uyBa81T5f5zZ95Tabg4CP?= =?us-ascii?q?YKQMOxBGCISRXQMHiKKVCiEK0cIXrCp5P+/b1w7uC3f54Dyoc0hf36IR9lnH?= =?us-ascii?q?93f1irBdyF3ZVN/ByISGKhXS71wsUb/JR9sq2UfsuiDcRCciFmryKNmYRqPi?= =?us-ascii?q?SAYYfHBHt/OY6VEVfT?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BKAAAZHvlh/51dJa1aHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUYHAQELAYFRVgd3WjcxhEmDRwOEWWCFDoMCA5skgS4UgRE?= =?us-ascii?q?DVAsBAQENAQEqDQoEAQGFBQIXg0gCJTQJDgECBAEBARIBAQUBAQECAQYEgQk?= =?us-ascii?q?ThWgNhkIBAQEBAgEBARAREQwBASwLAQsEAgEIEQMBAgECAiYCAgIlCxUICAI?= =?us-ascii?q?EDgUigmIBgmUDDSEBDqIpAYE6AoofeoExgQGCCAEBBgQEgTYBE0GDAhiCNwM?= =?us-ascii?q?GgRAqAYMNhB6HByccgUlEgRUnHIJnPoJjAQEDgSgBCwYCASCDGDeCLpE2cmM?= =?us-ascii?q?EUyACLQkDPTQ2ERmSP4NbjU5CnBEKg0aLAZRcBS6DcowchlqRH5ZKgkeKSJk?= =?us-ascii?q?zAgQCBAUCDgEBBoFhPGlwcBU7KgGCCgEBMlEZD44gDBaDT4UUhUp0OAIGAQo?= =?us-ascii?q?BAQMJiwaBaV0BAQ?= X-IronPort-AV: E=Sophos;i="5.88,333,1635206400"; d="scan'208";a="729764364" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Feb 2022 12:05:27 +0000 Received: from mail.cisco.com (xbe-aln-003.cisco.com [173.36.7.18]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 21NC5R6I021705 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 23 Feb 2022 12:05:27 GMT Received: from xfe-aln-002.cisco.com (173.37.135.122) by xbe-aln-003.cisco.com (173.36.7.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Wed, 23 Feb 2022 06:05:27 -0600 Received: from xfe-rcd-005.cisco.com (173.37.227.253) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Wed, 23 Feb 2022 06:05:27 -0600 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-005.cisco.com (173.37.227.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Wed, 23 Feb 2022 06:05:26 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z8pzxiIJZ3CfF4sQmTnkIlBbVS/Q0bqJNqgA6L/V5YdoXF7MkSTa+hy++5iGxsaM4QVs6ZoAztIjqLbJ7wXLCZYR9bqsCYG4dOIgfcCavcz1Aqt9d/dsdaNh8O1QrFmsteA5+z8tRRtz6hNdk+dmw0CHCQHiNflzMaD1zPk+gKLNzgV7rZbrkgATuYOZ8UCjWwWqxYqtMP4PfUEpe6LftC8S4GL9S6JwgzHnIU61Zfn4g82Ruu+Zeb99GkzTMjxFp2CWhUxPnIMP799T6NXypUSt7eqCPr3bRNqE2nczd6AvVchI0Jae55a+nCaYaJC6WDzsuTXmoz/7DoA+tbu2ng== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=VB2C4jvPe5aeHLpgQa7xeV2dSXNFGLm3tNAOUSYZBTU=; b=BP5zpt54Xp9mxJSlbi2prmaeIx7BAF0RV2up1QaFatlbX3FlV8G7UAqNObZ7dnSJsnaeOsiMwBAbYNu1Zz4XJrDk27SY8aeJDm3vf6wG/310Njsnfz1E0YFrrP5Mh+lZlc5SeykgOXmoKPq8GvzjbLS9+4cikIqcpN0Iaw+umbupVaM5YKZhob/20DKupmMK7jVP/sPvZqKZjFLccZqRhYUuA9S5DwEmXI9ViWMtEeNKbIcuLXJeHkwcZ8dIL54534u0S9b8W/bwyVhKlTBaNBlYyHX0te6YXSAXxEuymps2LrT4OrkzSEk/CHd6kJ4Be/q/KoGf4U25pX7+r5eY9Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VB2C4jvPe5aeHLpgQa7xeV2dSXNFGLm3tNAOUSYZBTU=; b=zPdwajRaQzOtu6C0S9Ap6umWfvkND86QNIrxxWTaorGZe4HVyI26LJOiIEiIRoKflYJp0giiag1NooEQGE/bF9h8UsDBwEzY0wIh7uDuwYEBYbHsz27o5Saf5F3b066drPcgtAfkVT3ZXUDTqZdHZIHfoVNU1vssz3nC504pYBk= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by BN6PR11MB1460.namprd11.prod.outlook.com (2603:10b6:405:b::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.21; Wed, 23 Feb 2022 12:05:20 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::1929:3b1b:99a3:312]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::1929:3b1b:99a3:312%9]) with mapi id 15.20.5017.023; Wed, 23 Feb 2022 12:05:20 +0000 From: "Eric Vyncke (evyncke)" To: Sara Dickinson CC: "dns-privacy@ietf.org" , "draft-ietf-dprive-dnsoquic@ietf.org" , "secdir@ietf.org" Thread-Topic: [dns-privacy] Last Call Expired: Thread-Index: AQHYKJFo3hxOBTaNuESNokgmcF5Mqayg9HIA///3ewCAAC70gA== Date: Wed, 23 Feb 2022 12:05:20 +0000 Message-ID: <79DEFB57-15C3-40A7-AA11-E31B752B8ACC@cisco.com> References: <164560577744.20656.12177163965188019338@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.58.22021501 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6e9ecce1-7e67-4577-7b83-08d9f6c4c38c x-ms-traffictypediagnostic: BN6PR11MB1460:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9IcMbUQX963ahGeHwpaf4xrH0vjnzb2igmjo6lWgLQ2F9IvOes5M8VCizaW2PckV/1iIky+zY4KGM15LiuFWZxPxMejYloLwMpwZZwPSifbo+z30B/6lGN7aqMXJcaP2fq3UcPvgFoLlNd7D1cAEkO3eiBEmM34l9ZPRkCCABNvAhDg56IlwvBL+Nq6RQJMyHXQVos2XsIIwqsNIaKIgpPt24RYqQsQnFiKRZa6dh5RdzGq3VpeQQtsntCi2mHLiZiLZ7Twm2UWN6v26mPKKsQKk3C+3AMa8N/aKFq/vX/8cLYC7iF2O/KNWsCQGbioz0n7BhUdzuEcb41rkEswMjQgvX7npdBuD0WTebmrhGblv8i3aPoT/vKhdZeWeB7yMbGQ4jO3BkKAH4KQqS1jo/iNntS+wuJlDlHyrSC2VrAvVeCCMVScCt9W7JRQTC+ZNsTaQC3zQmDxucm4FpVy10dJVzioq2sQZDGiERZGdDNJrO8gXMhdusLtAj1thyiGDSBlV4VZh4dghts6a0jhnATRW6vpocAOg9atQdPh+yYDk2u6lw9YR/t6hgL2WWW+RBtHENwQr/s9OQlGCYSkDbbTD7S+pp+ngFxfMGXlBkVvg/AhXntHAnyX0R2Z2LO+SiflCdQ8rU8FYX/o0BNAT17I+IhIm47tD2Ulf1KzcPLJJbrWHSQqF8az9yLrbYnxAyCSZxF4cVL7zalGCfxQ2S6MR3bf0lOVevgpTi0rAAz9l7t8r1rqozAox2+hD93s0sRbsPInz8k3yU//W9RFgmU9kGBsJ4xBwR9xIf6xtyt2A0Na3CBBktvASdcTPEiW5ot1nzFnj7ei6NH1YQLHI4wC/HXgWxha758rQDHAmBKE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(76116006)(33656002)(2616005)(91956017)(54906003)(4326008)(8676002)(66946007)(64756008)(66446008)(66476007)(66556008)(38070700005)(71200400001)(186003)(6512007)(6506007)(83380400001)(2906002)(53546011)(508600001)(966005)(6486002)(38100700002)(86362001)(316002)(6916009)(8936002)(122000001)(36756003)(5660300002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Sy9ETG9LWHNaL1BGSkNYVjRpN0k1ZjVRVjlheVVVQjBHUTEvQ0p6b1d5OUJo?= =?utf-8?B?MWhOVkRxTjFobFQ2NTdJMkw3UDJWQnR1d2RTZWgvSittYSt1WHNOY3QyR1lI?= =?utf-8?B?eDhXN0tGVzUvSWVuYkw3N05sV2hoSnM3RnpKQk5kcUhsUWhxYmowaTlJVmww?= =?utf-8?B?YkJWcjYrY0VwRUxmbWdoYVlIa0MvQmpnc3NveERHSUNINEJ4RWU0dVpoQzNO?= =?utf-8?B?QXdFeCsyWUl0c2hoWnpYMlVvUkFNcWJVME1OUTFDd2RrTEc3TVltOHpySXln?= =?utf-8?B?dGUwYk1vUzZ3OEVySEN3cWZSZGRTc3NKK1NMcis1ZEZYYjBEemdxVlovY1dq?= =?utf-8?B?akVYVnphQm16UXBPQ3pmQUZxYUtmSzlSOUlPY2pML3g5Mmw5LzhqaXk5WkpO?= =?utf-8?B?cTNGL1ppek5tcjZKUEluVk1MV21LTUhlYmRDditIQlgxS1VZQUNXOXZ2RVVG?= =?utf-8?B?dGNJUG5SNCt5OU5GTVJ3WWxzL3hrbkVuaVNMUjJxY1ViVUtTZlo0WS9sQzVx?= =?utf-8?B?ZmJrWTh6dlFXWDBlcUNUT0ovVTQrTjk3MHJCbVBsclJhNkpPcEdiM09SOXMx?= =?utf-8?B?d3QyN3FPY3A5YjBjOHlSakpXT2NwYnlvN3V0UmNJdVhiMFNGTmFyRDM4cEM4?= =?utf-8?B?Q3dTS0IzKytzSGo4TWoveld5QkZ1dUswNjUrWFhneGZhL0J1RGdFNUgxeXM4?= =?utf-8?B?aWd6Rll5TitzQytaUVovakl2WThYVXE3MXdiSjNCbUZLK3Q2RHJ6ZEs1Z1Ur?= =?utf-8?B?dXBCRzE2bjJmUXZEU0J5cEZTeHpCaDJGeklPVHpXUzFqREtoQmdMb3U3dVpF?= =?utf-8?B?T2RzNXowbThTUHF3emgrRnBwL0hEWXBvZjY1Um5aWGUzaU4wWWdFcU9yVzFM?= =?utf-8?B?cmhSVTBYa1dzSXhjOFIxTVV6YXYrMXBzYTRHNk1ENjVGK1llYzRuU1FpdFN1?= =?utf-8?B?cVZVSHZlTTJQdmEwVXh4VGp5TGV6UDJOQmhYUmFBLzJQRmdiOEpmYnY4b3k2?= =?utf-8?B?RmxjVlVGeWxlak1xaTNGNlQ5WnRqRmhZRk9ZTUh6eHlSNVc1Skhvc0V1YmlQ?= =?utf-8?B?RXVBSlBlUVdmaHhPOE5jbkhDQVR4RzhyaXNSUlpiZUd6b1ZDcmZML0Q1WUlr?= =?utf-8?B?NEZCRHNnOGo1S2VQSWMrZFNNeWVwckhJaHhEbHZER0FuVUFrR2YxL2sxQi9O?= =?utf-8?B?T2cxU092RXlUV29ZUFFHdFM1ekt3WHdENC9TSTM4Z0wzVWxKMDYrRW01dmlR?= =?utf-8?B?NW5CRzlkM2NtMmFjUWJYUHNKcGo1UHRQdFN6TnVONitwdElja1dtRDdNQXJE?= =?utf-8?B?d0k5Wk4wenZLcXdmNEF6OFkwaWhsdmpUUUdDTGdvbmdSRlc2cXIvbWQ5Mmty?= =?utf-8?B?N1BMY2FKaDBLWE9Pa0VYay9RWm9CSVVnNm1velJJdkhhYmVIbnVSdVBVY0pF?= =?utf-8?B?OFpnV1VneDAyNHRZK1NjRFhEVnI1ZEtkcnpPWUlIUTRZZEt2UWQ1eUNSWWdE?= =?utf-8?B?Z1NXZDk4WHB4Uno3VlVLa0pYM1JjbFFUN082RExOYVRrTHYzaHlCS09HbjVh?= =?utf-8?B?NExENjFialVqMW1mb2c0ODRjOGhSdUFEVU9EVENaT3lGMGpIUFhaYXZpdEV3?= =?utf-8?B?anpmbmY5NjVKZ2lRVXFCUTFKbW1PcnlGY01EKzFkRnNkWHZGbHVNMlZIMy9D?= =?utf-8?B?dEtHSXlKOENVT2QwOW1UOGRRQWpNYWxwNDc0amJYYzEyUUhvV1o3MjE3QlMr?= =?utf-8?B?MzVTZ1N2M1lndjEvaWwzRHkvcXAzMGZKZEQ1QTBZNy9VYWdqdzZGdEFPR2ZE?= =?utf-8?B?MHIwM1liZU16OVNPZWttcWdXNmpySzRBWFpmNEwxS09XMzBBUW9yRmNKZEVN?= =?utf-8?B?M0w2UFBtVVJxK2NVK1V5UFdBZG9FSGNZZnFGSW4va3dBb2ZJRGV6MGZVT2dV?= =?utf-8?B?Y1R5RExxVTVBTmFCNlJRRWorQVJoTUd2NE1NSnRZQ2JYQnVMVWtDZFhMRTdk?= =?utf-8?B?MWphMndpdS9FdXd0UGhTOFBSa3ArQXdYbG9wZk1nVE9uSkxlbnplUCsyVHlM?= =?utf-8?B?QmNxdkc5LzJOMnhmOGFjaHA4Q3FObWlaWFcvN08vS09FVmQ3VWowQXVVUXQ2?= =?utf-8?B?T3B1Y21ndmpnZDhkWk5hV0xyNWN1YlpFOXNacmpTQ0dMN0M3ZGxSb1RVdmx2?= =?utf-8?B?NGJNd1NrZTVIZWdtSEEwT0pTZmw1b1ZEU3ZpTTRNeHZaS29VSzliSW82ZWY0?= =?utf-8?Q?XzKsrx6aaxZZsGoGJfBVs0wfruu9YN4bYASPO79t5o=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <8CD83A55FE5C6C43A534F7CF79C66C0C@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6e9ecce1-7e67-4577-7b83-08d9f6c4c38c X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2022 12:05:20.2847 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 08KH3MJzluQTX4XNwmF/ipcccbTD74OufaypaI93NpCrEdMnKkuZAJJUIB7CPavN1bro0knNzCf6xwYYMIRKZQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1460 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xbe-aln-003.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [secdir] [dns-privacy] Last Call Expired: X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2022 12:05:36 -0000 U2FyYSwNCg0KVGhhbmsgeW91IGZvciB5b3VyIHJlcGx5LiBUaGlzIHNvdW5kcyByZWFzb25hYmxl IGFuZCBJIGhhdmUgYWxzbyByZWFkIENocmlzdGlhbidzIHJlcGx5IGFib3V0IElBTkEuDQoNCkFz IHNvb24gYXMgdGhlIC0xMCBpcyBwdWJsaXNoZWQsIEkgd2lsbCBwcm9jZWVkIHdpdGggdGhlIElF U0cgZXZhbHVhdGlvbi4NCg0KUmVnYXJkcw0KDQotw6lyaWMNCg0KDQrvu78tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogU2FyYSBEaWNraW5zb24gPHNhcmFAc2lub2R1bi5jb20+DQpE YXRlOiBXZWRuZXNkYXksIDIzIEZlYnJ1YXJ5IDIwMjIgYXQgMTE6MTcNClRvOiBFcmljIFZ5bmNr ZSA8ZXZ5bmNrZUBjaXNjby5jb20+DQpDYzogImRucy1wcml2YWN5QGlldGYub3JnIiA8ZG5zLXBy aXZhY3lAaWV0Zi5vcmc+LCAiZHJhZnQtaWV0Zi1kcHJpdmUtZG5zb3F1aWNAaWV0Zi5vcmciIDxk cmFmdC1pZXRmLWRwcml2ZS1kbnNvcXVpY0BpZXRmLm9yZz4sICJzZWNkaXJAaWV0Zi5vcmciIDxz ZWNkaXJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2Rucy1wcml2YWN5XSBMYXN0IENhbGwgRXhw aXJlZDogPGRyYWZ0LWlldGYtZHByaXZlLWRuc29xdWljLTA5LnR4dD4NCg0KICAgIEhpIEVyaWMs IA0KDQogICAgVGhlIGF1dGhvcnMgZGlkIGFzayBQaGlsbGlwIGRpcmVjdGx5IGlmIGhlIGhhZCBz cGVjaWZpYyB0ZXh0IGNoYW5nZXMgaGUgd291bGQgbGlrZSB0byBzZWUgZm9sbG93aW5nIGhpcyBy ZXZpZXcgZHVyaW5nIHRoZSBmaXJzdCBJRVRGIExhc3QgQ2FsbDoNCiAgICBodHRwczovL21haWxh cmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2Rucy1wcml2YWN5L0l1N2xnNUF2RjlNeDRUdS1nZmxB U0FyT0Y4QS8NCg0KICAgIEhvd2V2ZXIgd2UgZGlkIG5vdCBnZXQgYSByZXBseSBhbmQgc28gd2Ug YXR0ZW1wdGVkIHRvIGFkZHJlc3MgdGhhdCByZXZpZXcgaW4gdGhlIC0wOSB1cGRhdGUgKHB1Ymxp c2hlZCBvbiA5dGggRmVicnVhcnkpIGJhc2VkIG9uIGEgZ2l0aHViIGlzc3VlIHdpdGggZGlzY3Vz c2lvbiBwb2ludHMgYW5kIGEgUFIgcmVmZXJlbmNlZCBpbiB0aGlzIGVtYWlsOg0KICAgIGh0dHBz Oi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvZG5zLXByaXZhY3kvb1JIa3lqaHVwelFq MEhBcHpMcHJ2RTRWN19zLw0KDQogICAgU2luY2Ugd2UgZGlkbuKAmXQgZ2V0IGFueSBmdXJ0aGVy IGZlZWRiYWNrIG9uIHRoaXMgcmV2aWV3IGR1cmluZyB0aGUgc2Vjb25kIElFVEYgTEMsIEnigJlt IGhvcGluZyB0aG9zZSB1cGRhdGVzIGFkZHJlc3NlZCB0aGUgcG9pbnRzIHJhaXNlZC4NCg0KICAg IEZZSSAtIHdlIGhhdmUgYSBwZW5kaW5nIFBSIHRvIGZpeCB0aGUgbWlub3IgaXNzdWUgbm90ZWQg aW4gdGhlIGxhdGVzdCBJQU5BIHJldmlldywgd2hpY2ggd2FzIHRoZSBvbmx5IGNvbW1lbnQgd2Ug Z290IGR1cmluZyB0aGUgc2Vjb25kIElFVEYgTEMuIFNvIHdl4oCZbGwgcHVibGlzaCB0aGUgLTEw IHVwZGF0ZSB3aXRoIHRoaXMgY29ycmVjdGlvbiBzaG9ydGx5Lg0KDQogICAgUmVnYXJkcw0KDQog ICAgU2FyYS4gDQoNCiAgICA+IE9uIDIzIEZlYiAyMDIyLCBhdCAwOTo0NywgRXJpYyBWeW5ja2Ug KGV2eW5ja2UpIDxldnluY2tlQGNpc2NvLmNvbT4gd3JvdGU6DQogICAgPiANCiAgICA+IFRoZSBJ RVRGLXdpZGUgbGFzdCBjYWxsIGhhcyBleHBpcmVkIGFuZCBBRkFJSyB0aGVyZSB3YXMgb25seSBv bmUgZGV0YWlsZWQgcmV2aWV3IGJ5IFBoaWxsaXAgSGFsbGFtLUJha2VyIGZvciB0aGUgc2VjdXJp dHkgZGlyZWN0b3JhdGUgKGFkZGVkIGluIGNjKToNCiAgICA+IGh0dHBzOi8vbWFpbGFyY2hpdmUu aWV0Zi5vcmcvYXJjaC9tc2cvbGFzdC1jYWxsL0wyM2JXT3hQNTROWlFQSFQ3RGZSQnhaQU9Ddy8N CiAgICA+IA0KICAgID4gV2hhdCBpcyB0aGUgYXV0aG9ycy9XRyBwbGFuIHRvIGFkZHJlc3MgdGhl ICJoYXMgaXNzdWVzIiBvZiB0aGlzIHJldmlldyA/IFlvdSBwcm9iYWJseSBrbm93IHRoYXQgdGhl IGN1dC1vZmYgZGF0ZSBpcyBNb25kYXkgN3RoIG9mIE1hcmNoLg0KICAgID4gDQogICAgPiBBcyBh IHBsYWluIGVuZ2luZWVyIChhbmQgd2l0aG91dCBhbnkgaGF0KSwgaXQgYXBwZWFycyB0byBtZSB0 aGF0IHRoZSBXaS1GaSBob3RzcG90IGlzc3VlIGlzIG5vdCBsaW1pdGVkIHRvIERvUSBidXQgaXMg YWxzbyByZWxldmFudCB0byBEb0guIEFuZCB0aGUgdHJhZmZpYyBhbmFseXNpcyBwYXJ0IGlzIHBy b2JhYmx5IGFkZHJlc3NlZCBhbHJlYWR5IHdpdGggdGhlIHBhZGRpbmcuIA0KICAgID4gDQogICAg PiBXaXRoIG15IEFEIGhhdCwgdGhlIHBvaW50cyBhYm91dCAnb3V0ZGF0ZWQnIHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zIGFuZCBwcml2YWN5IHZzLiBjb25maWRlbnRpYWxpdHkgc2hvdWxkIGJlIGFk ZHJlc3NlZCBpbiB0aGUgZG9jdW1lbnQgKGhhcHB5IHRvIGJlIGNvcnJlY3RlZCBvZiBjb3Vyc2Up LiBBbnl3YXksIGl0IHdvdWxkIGJlIG5pY2UgdG8gYW5zd2VyIHRvIFBIQi4NCiAgICA+IA0KICAg ID4gUmVnYXJkcw0KICAgID4gDQogICAgPiAtw6lyaWMNCiAgICA+IA0KICAgID4gDQogICAgPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgID4gRnJvbTogZG5zLXByaXZhY3kgPGRucy1w cml2YWN5LWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBEcmFmdFRyYWNrZXIgTWFpbCBT eXN0ZW0gPGllc2ctc2VjcmV0YXJ5QGlldGYub3JnPg0KICAgID4gRGF0ZTogV2VkbmVzZGF5LCAy MyBGZWJydWFyeSAyMDIyIGF0IDA5OjQzDQogICAgPiBUbzogImJyaWFuQGlubm92YXRpb25zbGFi Lm5ldCIgPGJyaWFuQGlubm92YXRpb25zbGFiLm5ldD4sICJkbnMtcHJpdmFjeUBpZXRmLm9yZyIg PGRucy1wcml2YWN5QGlldGYub3JnPiwgImRyYWZ0LWlldGYtZHByaXZlLWRuc29xdWljQGlldGYu b3JnIiA8ZHJhZnQtaWV0Zi1kcHJpdmUtZG5zb3F1aWNAaWV0Zi5vcmc+LCBFcmljIFZ5bmNrZSA8 ZXZ5bmNrZUBjaXNjby5jb20+DQogICAgPiBDYzogImllc2ctc2VjcmV0YXJ5QGlldGYub3JnIiA8 aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmc+DQogICAgPiBTdWJqZWN0OiBbZG5zLXByaXZhY3ldIExh c3QgQ2FsbCBFeHBpcmVkOiA8ZHJhZnQtaWV0Zi1kcHJpdmUtZG5zb3F1aWMtMDkudHh0Pg0KICAg ID4gDQogICAgPiANCiAgICA+ICAgIFBsZWFzZSBETyBOT1QgcmVwbHkgdG8gdGhpcyBlbWFpbC4N CiAgICA+IA0KICAgID4gICAgSS1EOiA8ZHJhZnQtaWV0Zi1kcHJpdmUtZG5zb3F1aWMtMDkudHh0 Pg0KICAgID4gICAgRGF0YXRyYWNrZXIgVVJMOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLWRwcml2ZS1kbnNvcXVpYy8NCiAgICA+IA0KICAgID4gICAgSUVURiBM YXN0IENhbGwgaGFzIGVuZGVkLCBhbmQgdGhlIHN0YXRlIGhhcyBiZWVuIGNoYW5nZWQgdG8NCiAg ICA+ICAgIFdhaXRpbmcgZm9yIEFEIEdvLUFoZWFkLg0KICAgID4gDQogICAgPiANCiAgICA+ICAg IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiAg ICBkbnMtcHJpdmFjeSBtYWlsaW5nIGxpc3QNCiAgICA+ICAgIGRucy1wcml2YWN5QGlldGYub3Jn DQogICAgPiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rucy1wcml2 YWN5DQogICAgPiANCg0KDQo= From nobody Wed Feb 23 14:51:49 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 2DB5D3A106C; Wed, 23 Feb 2022 14:51:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Mundy via Datatracker To: Cc: draft-iab-rfcefdp-rfced-model.all@ietf.org, iab@iab.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164565670705.28507.12262976632263611001@ietfa.amsl.com> Reply-To: Russ Mundy Date: Wed, 23 Feb 2022 14:51:47 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-iab-rfcefdp-rfced-model-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: Wed, 23 Feb 2022 22:51:47 -0000 Reviewer: Russ Mundy Review result: Ready Reviewer: Russ Mundy Review result: Ready with nits I have (re)reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is: Ready with nits The document is well written, understandable and provides sound definition of a new version of the RFC Editor Model. The only nits that I identified in the document are in the Security Considerations section where the wording infers that "the RFC Editor" is a single entity (or person). I recognize that the wording in the section came mostly from earlier RFC Editor Model versions but since this Model Version clearly states that the activities are performed by a collection of multiple entities, the wording of section 10 seems inconsistent with other parts of the document. Without trying to make this section unduly long or complex, I suggest making something like the following changes to section 10: First paragraph, third sentence current wording: "Since the RFC Editor maintains the index of publications, sufficient security must be in place to ...." Suggest changing to: "Since multiple entities described in this document participate in maintenance of the index of publications, sufficient security must be in place and followed by each entity to ..." Second paragraph current wording: "The IETF LLC should take ..." Suggest changing to: "The IETF LLC or any other contracting activity(s), e.g., subcontracts, should take ..." Again, thanks for the excellent quality draft - hopefully, the suggested changes make section 10 clearer. Russ Mundy From nobody Wed Feb 23 16:01:15 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 2C16C3A0125; Wed, 23 Feb 2022 16:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.792 X-Spam-Level: X-Spam-Status: No, score=-2.792 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.714, RCVD_IN_DNSWL_BLOCKED=0.001, 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 jaP1rQ3QRGI8; Wed, 23 Feb 2022 16:00:49 -0800 (PST) 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 931783A0A67; Wed, 23 Feb 2022 16:00:49 -0800 (PST) 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 21O00atM097615 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 23 Feb 2022 18:00:39 -0600 (CST) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1645660845; bh=4ByXXb/4gFBivZYIqgw31e1qxtaNbvvvnTjYYk+mfNU=; h=Date:To:Cc:References:From:Subject:In-Reply-To; b=VE3egzGytnumwhzctMTzMro4BE2X39bxKcTEG7TyVXWd/rLqqnWf0B5OKWrh1dJGg O+j6u5X+0KYBEgdcdRoUZMaNk7uXXxLj1CVDgRntoNwZkdedMRuFoaxH8VZzh8kfA5 rxCkSufdUD8TEjoqj7JXaFZUhTeOoaXvxcQ8KsxU= X-Authentication-Warning: raven.nostrum.com: Host [47.186.48.51] claimed to be [192.168.1.114] Message-ID: <24a65b26-b578-da36-6d94-b7cbbb8de89e@nostrum.com> Date: Wed, 23 Feb 2022 18:00:31 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Content-Language: en-US To: Kyle Rose , secdir@ietf.org Cc: draft-faltstrom-base45.all@ietf.org, last-call@ietf.org References: <164427281988.3952.13973206934475684325@ietfa.amsl.com> From: Robert Sparks In-Reply-To: <164427281988.3952.13973206934475684325@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-faltstrom-base45-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, 24 Feb 2022 00:00:55 -0000 Hi Kyle - I read this while working on my Genart review. Some thoughts inline. On 2/7/22 4:26 PM, Kyle Rose via Datatracker wrote: > Reviewer: Kyle Rose > 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 one Issue. Technically, the described protocol is Ready > primarily because it describes an existing encoding standardized in ISO/IEC > 18004. That said, I can't really help but ask a few things about this encoding: > > * Why 45? (This is probably really a question for the people who designed QR > codes.) 45^3 = 91125 >> 2^16, which means roughly 30% of strings with length > divisible by 3 comprising base45 characters are invalid encodings. If you didn't see the exchange between Carsten et.al. on this point, it is compelling. See https://mailarchive.ietf.org/arch/search/?q=draft-faltstrom-base45 > * Why is > Space included as a character? This renders the encoding fragile in many string > handling contexts. Well, it also requires encoding of buffers that contain nulls, so fragility abounds. > * Base64 requires padding only to comply with the spec > as-written: a minor modification of the spec (let's call it base64') could lose > the padding and still produce unambiguous encodings of both content and length: > going from 64 to 45 doesn't have anything to do with remedying this. And, by > contrast with base45, 64^4=256^3, which means all strings with length divisible > by 4 comprising base64 characters would be valid base64' encodings. > > But the real issue I have with the document (and one that might be technically > unavoidable, depending how ISO/IEC 18004 is worded) is that an actual covert > channel isn't addressed at all: that of the remaining insignificant bits in > encodings of odd-length strings (a problem that would similarly impact base64' > from above for encodings of strings with length mod 3 !≅ 0). Taking the example > from section 4.4, the final chunk ([33 0]) in the example comes from the 16-bit > value 33 (= 33 + 0 * 45). But all that is needed is that 33 ≅ X mod 256 unless > the decoder enforces that encodings of length not divisible by 3 have 16-bit > values < 256. For example, QED8WEJ6 ultimately decodes to the string "ietf!", > or to "ietf!1", or not at all, depending on the behavior of the decoder: ignore > non-zero second octet in odd-length strings (quite likely), render it based on > the available data (unlikely because, if not special-cased, would result in > decoding "ietf!0" in the example from the document), or reject the encoding. > The last option is the only valid thing to do from a security perspective. Show your math (or at least reading of the logic in the draft) a bit more? It seems dead obvious to me from the draft that any base 45 [c d] such that a = c + 45*d > 255 is an invalid encoding. In other words, the draft requires the last option. What am I missing? > > Grammar nit: "For example, it MUST the encoded data" > > > From nobody Wed Feb 23 16:15:28 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 B11673A11D5; Wed, 23 Feb 2022 16:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 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.714, 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=pdU375zW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mNDGRRxh 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 Tk893yBVde1A; Wed, 23 Feb 2022 16:14:35 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 277063A11D7; Wed, 23 Feb 2022 16:14:32 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 586CC5C021C; Wed, 23 Feb 2022 19:14:31 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 23 Feb 2022 19:14:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; bh=axL3npaUpa2ew1 d65JkPbmS4FECyl8tjrh4RZUeezk0=; b=pdU375zWFMfF9E6D7HYn9Bwd3mdUTq y4d8QekNYx7W3adSiMBJlw5AgMKmTgIevuL68EdHFzHjDja2rC4kDEWKL+bweOyR ZnKrOeMLkyGFx3BXy4bMFbWbIFNOEJAAUApNIggIfEwY0zPPGPob8txg0km+Ocgw qzB4GoaczbtoFuJgQZ8CxQIP+VIbgTsuP4oB1I/UGKsiajo9I0ABLRo0sa2fhJjB as0WVkUS7KaWU6tsJlMQqrrTxVMOYkPXRlxC9z6zYLsXKoYdT/KCIkdcbrK0ViWL C6JYNtfhaccp1IC9d7NCwE91sxE1oYdbOfvssvuvlJ3Ill/1YmE/Qx5Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=axL3npaUpa2ew1d65JkPbmS4FECyl8tjrh4RZUeez k0=; b=mNDGRRxhYQusP5r5AXqhRHom3O61OrgvDY5EY9W91g/023T8Dwnz9r+I9 uSGIrLGhWtoedG+xpq9oJoJV91qDOqvSdGnIB64+dJJ4qtEn9lpFxbHqWHly1r7S 74bi+CiwWxi/P7M9NQ6GtH3P1VP6dBeYoZIC2AnHU8OjDsLvvz66a0HoMa6bAl3e 8/A1kYenC+iU88A02syL1b+QeobRNwAKsgX1ZqlYHHkvsNJd2W34f0vgsjZt4qck 0tB+JL+tYdW00ZiVfhgOKeivMxNpdc22X7L7MqJyPHrl9gui88vmBk1LkrEWduF4 fZ5CdUkaHK5NDj4C195mR0S2Af4ug== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrledugddulecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfvfhfhufgjtgfgsehtjeertddtfeejnecuhfhrohhmpefrvghtvghr ucfurghinhhtqdetnhgurhgvuceoshhtphgvthgvrhesshhtphgvthgvrhdrihhmqeenuc ggtffrrghtthgvrhhnpefgleekveevlefgheejuefhheeuhfekfedtfffggefhgeetvdeg iefgvdekledtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehsthhpvghtvghrsehsthhpvghtvghrrdhimh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 23 Feb 2022 19:14:30 -0500 (EST) Message-ID: Date: Wed, 23 Feb 2022 17:14:25 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Content-Language: en-US To: Russ Mundy Cc: draft-iab-rfcefdp-rfced-model.all@ietf.org, iab@iab.org, last-call@ietf.org, "rfced-future@iab.org" , "secdir@ietf.org" References: <164565670705.28507.12262976632263611001@ietfa.amsl.com> From: Peter Saint-Andre In-Reply-To: <164565670705.28507.12262976632263611001@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-iab-rfcefdp-rfced-model-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: Thu, 24 Feb 2022 00:14:38 -0000 Hi Russ, thanks for your review. Comments inline. On 2/23/22 3:51 PM, Russ Mundy via Datatracker wrote: > Reviewer: Russ Mundy > Review result: Ready > > Reviewer: Russ Mundy > Review result: Ready with nits > > I have (re)reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments. > > The summary of the review is: Ready with nits > > The document is well written, understandable and provides sound definition of a > new version of the RFC Editor Model. > > The only nits that I identified in the document are in the Security > Considerations section where the wording infers that "the RFC Editor" is a > single entity (or person). I recognize that the wording in the section came > mostly from earlier RFC Editor Model versions but since this Model Version > clearly states that the activities are performed by a collection of multiple > entities, the wording of section 10 seems inconsistent with other parts of the > document. Good catch. We copied the Security Considerations from RFC 6635/8728 and didn't properly update it to reflect version 3 of the model. > Without trying to make this section unduly long or complex, I suggest making > something like the following changes to section 10: > > First paragraph, third sentence current wording: > > "Since the RFC Editor maintains the index of publications, sufficient security > must be in place to ...." > > Suggest changing to: > > "Since multiple entities described in this document participate in maintenance > of the index of publications, sufficient security must be in place and followed > by each entity to ..." Something like that would make sense, although we might want to mention the RFC Production Center because Section 4.3 specifies that they have responsibility for publication, archiving, etc. > Second paragraph current wording: > > "The IETF LLC should take ..." > > Suggest changing to: > > "The IETF LLC or any other contracting activity(s), e.g., subcontracts, should > take ..." That seems reasonable. > Again, thanks for the excellent quality draft - hopefully, the suggested > changes make section 10 clearer. They do, thanks! Peter From nobody Thu Feb 24 07:13:00 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 941BC3A08C9; Thu, 24 Feb 2022 07:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 scKf9r-3qdZU; Thu, 24 Feb 2022 07:12:46 -0800 (PST) Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.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 907C63A08C7; Thu, 24 Feb 2022 07:12:35 -0800 (PST) Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id 1B1867C45D; Thu, 24 Feb 2022 10:12:34 -0500 (EST) Received: from [10.0.1.2] (pfs.iad.rg.net [198.180.150.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id 00EE57E502; Thu, 24 Feb 2022 10:12:33 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) From: Russ Housley In-Reply-To: <24a65b26-b578-da36-6d94-b7cbbb8de89e@nostrum.com> Date: Thu, 24 Feb 2022 10:12:33 -0500 Cc: IETF SecDir , draft-faltstrom-base45.all@ietf.org, Last Call Content-Transfer-Encoding: quoted-printable Message-Id: <0B8AEC8E-CC3C-4955-B242-1A12BE4DC507@vigilsec.com> References: <164427281988.3952.13973206934475684325@ietfa.amsl.com> <24a65b26-b578-da36-6d94-b7cbbb8de89e@nostrum.com> To: Robert Sparks , Kyle Rose X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-faltstrom-base45-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, 24 Feb 2022 15:12:52 -0000 > On Feb 23, 2022, at 7:00 PM, Robert Sparks = wrote: >=20 > Hi Kyle - I read this while working on my Genart review. Some thoughts = inline. >=20 > On 2/7/22 4:26 PM, Kyle Rose via Datatracker wrote: >> Reviewer: Kyle Rose >> Review result: Has Issues >>=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 >> This document has one Issue. Technically, the described protocol is = Ready >> primarily because it describes an existing encoding standardized in = ISO/IEC >> 18004. That said, I can't really help but ask a few things about this = encoding: >>=20 >> * Why 45? (This is probably really a question for the people who = designed QR >> codes.) 45^3 =3D 91125 >> 2^16, which means roughly 30% of strings = with length >> divisible by 3 comprising base45 characters are invalid encodings. >=20 > If you didn't see the exchange between Carsten et.al. on this point, = it is compelling. >=20 > See https://mailarchive.ietf.org/arch/search/?q=3Ddraft-faltstrom-base45= >=20 >> * Why is >> Space included as a character? This renders the encoding fragile in = many string >> handling contexts. > Well, it also requires encoding of buffers that contain nulls, so = fragility abounds. >> * Base64 requires padding only to comply with the spec >> as-written: a minor modification of the spec (let's call it base64') = could lose >> the padding and still produce unambiguous encodings of both content = and length: >> going from 64 to 45 doesn't have anything to do with remedying this. = And, by >> contrast with base45, 64^4=3D256^3, which means all strings with = length divisible >> by 4 comprising base64 characters would be valid base64' encodings. >>=20 >> But the real issue I have with the document (and one that might be = technically >> unavoidable, depending how ISO/IEC 18004 is worded) is that an actual = covert >> channel isn't addressed at all: that of the remaining insignificant = bits in >> encodings of odd-length strings (a problem that would similarly = impact base64' >> from above for encodings of strings with length mod 3 !=E2=89=85 0). = Taking the example >> from section 4.4, the final chunk ([33 0]) in the example comes from = the 16-bit >> value 33 (=3D 33 + 0 * 45). But all that is needed is that 33 =E2=89=85= X mod 256 unless >> the decoder enforces that encodings of length not divisible by 3 have = 16-bit >> values < 256. For example, QED8WEJ6 ultimately decodes to the string = "ietf!", >> or to "ietf!1", or not at all, depending on the behavior of the = decoder: ignore >> non-zero second octet in odd-length strings (quite likely), render it = based on >> the available data (unlikely because, if not special-cased, would = result in >> decoding "ietf!0" in the example from the document), or reject the = encoding. >> The last option is the only valid thing to do from a security = perspective. > Show your math (or at least reading of the logic in the draft) a bit = more? It seems dead obvious to me from the draft that any base 45 [c d] = such that a =3D c + 45*d > 255 is an invalid encoding. In other words, = the draft requires the last option. What am I missing? My code throws an error when presented with this example. Russ From nobody Thu Feb 24 08:34:52 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 6287A3A0C50; Thu, 24 Feb 2022 08:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 qbKUbQNclb8L; Thu, 24 Feb 2022 08:34:25 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 B651A3A0C82; Thu, 24 Feb 2022 08:34:24 -0800 (PST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 21OGYLXj022491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 24 Feb 2022 17:34:21 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id 21OGYK4h017915; Thu, 24 Feb 2022 17:34:21 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id C678FC5A20; Thu, 24 Feb 2022 17:34:20 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id fE9adHXqgCfT; Thu, 24 Feb 2022 17:34:18 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 9C0CDC5A1B; Thu, 24 Feb 2022 17:34:18 +0100 (CET) Date: Thu, 24 Feb 2022 17:34:18 +0100 Message-ID: <871qzs1awl.wl-jch@irif.fr> From: Juliusz Chroboczek To: Tero Kivinen Cc: , babel@ietf.org, draft-ietf-babel-v4viav6.all@ietf.org, last-call@ietf.org In-Reply-To: <164376046073.3024.11843958658714304588@ietfa.amsl.com> References: <164376046073.3024.11843958658714304588@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 24 Feb 2022 17:34:21 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 24 Feb 2022 17:34:21 +0100 (CET) X-Miltered: at korolev with ID 6217B38D.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 6217B38C.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 6217B38D.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 6217B38C.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 6217B38D.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 6217B38C.002 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-babel-v4viav6-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 16:34:40 -0000 > Reviewer: Tero Kivinen > Review result: Ready Thanks for your review, Tero. -- Juliusz From nobody Thu Feb 24 09:02:34 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 45F383A0C47 for ; Thu, 24 Feb 2022 09:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.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 V_x06sWkOo89 for ; Thu, 24 Feb 2022 09:02:22 -0800 (PST) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 7DBF43A0C4B for ; Thu, 24 Feb 2022 09:02:22 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id s13so647127wrb.6 for ; Thu, 24 Feb 2022 09:02:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+BvFVoNuwT+6RkeuwczvEiSW6h0Rjo47U61xhWp5c7c=; b=K4mBHK9f3idmR9fS9bu4vYg0lkE1u1GhbOZCI5NVF62+kyj3hX22KAr5WDytOUq3J6 zMjR0mnOhcUSBjjYNVlz1x4mgWmDsYb1uBCvr2C4j9K7RxnbCtdSzRQek0rKAfco4nrs MHjnTflck7KIPyhxhLbBtVugoZYtJvcAAYfe8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+BvFVoNuwT+6RkeuwczvEiSW6h0Rjo47U61xhWp5c7c=; b=VRCb3//vNkEgLOSOyu+1ZuLgnhD5wJdouvPYCwo7QQ3hxX+bh6iv4Zi8gMQFoKlcAB sXi24zbgE0YDAoNwVpy1E6evHm/z9oiW7HdpjwmuuN10HbC16OuQebIFGkzy78B1wvBU /lg8UNeFNSii5/FHKjHVZc5VS5nccw1n7Qr7FKj3nWKAIbLuVLM81Zpgx1pqbCFjrZJF qgE17qwAz43KXimbQQfH5aUlwJiMom8/tg+BIjMBDuGVEavytpPzJsvUbNxfUmeTAFyH KpPWsyNdhsdmzCSGeV+aKorJsHtW9Z6sJECWdtyCKyT6Mt0CNsN4BznBTWcPwizJqgTv pE4Q== X-Gm-Message-State: AOAM532jXVEiUa4Q822o90UsvqDCrdcsE3dKe7nBCHbIIh626tRAz7Wu K8E5XZ00fpzvYBW7xdc4fV+CxJKmWlzXCjRnAZnoLPzj5XC5FQ== X-Google-Smtp-Source: ABdhPJxRscue0dNMtrW/D4cDs5PshHz9UcLWNX8F5SBg8+8g++XFDKMerY5Ey8YsIlOG7RbxR1lWDiOn7cLcQQaIDU0= X-Received: by 2002:adf:dccc:0:b0:1e4:a588:4cb9 with SMTP id x12-20020adfdccc000000b001e4a5884cb9mr3003784wrm.461.1645722138358; Thu, 24 Feb 2022 09:02:18 -0800 (PST) MIME-Version: 1.0 References: <164427281988.3952.13973206934475684325@ietfa.amsl.com> <24a65b26-b578-da36-6d94-b7cbbb8de89e@nostrum.com> In-Reply-To: <24a65b26-b578-da36-6d94-b7cbbb8de89e@nostrum.com> From: Kyle Rose Date: Thu, 24 Feb 2022 12:02:07 -0500 Message-ID: To: Robert Sparks Cc: secdir@ietf.org, draft-faltstrom-base45.all@ietf.org, last-call@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-faltstrom-base45-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, 24 Feb 2022 17:02:28 -0000 On Wed, Feb 23, 2022 at 7:00 PM Robert Sparks wrote: > If you didn't see the exchange between Carsten et.al. on this point, it > is compelling. > > See https://mailarchive.ietf.org/arch/search/?q=3Ddraft-faltstrom-base45 Good thread. Given that this encoding is a fait accompli, discussion of the merits is somewhat moot; that said, it's perhaps useful as a warning about the questionable level of care put into the design. > > * Why is > > Space included as a character? This renders the encoding fragile in man= y string > > handling contexts. > Well, it also requires encoding of buffers that contain nulls, so > fragility abounds. "Everything is b0rken, so =C2=AF\_(=E3=83=84)_/=C2=AF" is not really a good= response, but my point from above also applies here: there's no point in arguing about it any further. That ship has sailed, the train has left the station, the horse has left the barn, etc. > Show your math (or at least reading of the logic in the draft) a bit > more? Good catch. Let me show you where I went wrong: "QED8WEJ6" [26 14 13 8 32 14 19 6] [[26 14 13] [8 32 14] [19 6]] Base45: [ 26981, 29798, 289 ] where: 26981 =3D 26+14*45+13*45*45 29798 =3D 8 + 32*45 + 14*45*45 289 =3D 19 + 6*45 Bytes: [[105 101] [116 102] [1 33]]** where: 105 =3D floor(26981 / 256); 101 =3D 26981 % 256 116 =3D floor(29798 / 256); 102 =3D 29798 % 256 1 =3D floor(289 / 256); 33 =3D 289 % 256 **Note [1 33] rather than [33 1] for the last pair. Which of course makes this not start with "ietf!", no matter how the decoder behaves. Apologies for the confusion. That said, there is still the potential for a limited covert channel here for some strings. Assume the octet stream you're trying to encode is of odd length and ends in '\x01' or [1]. The proper encoding of this is: Bytes: [1] Base45: [1] [[1 0]] where 1 =3D 1 + 45*0 [1 0] "10" What if instead you send "W5"? There's no way to get this string via proper encoding, but if you decode naively, you get: "W5" [32 5] [[32 5]] Base45: [ 257 ] where: 257 =3D 32 + 5*45 Bytes: [[1 1]] where: 1 =3D floor(257/256); 1 =3D 257 % 256 which is '\x01\x01' if the decoder outputs both bytes, '\x01' if it outputs only one byte, or results in failure if you do the 257 < 256 check. My point before screwing up the example in my original review was mainly that simply saying "For decoding a Base45 encoded string the inverse operations are performed" doesn't, in my judgment, sufficiently cover this case. FWIW, the decoder I am using properly rejects "W5", but the issue is not the behavior of any particular decoding implementation, but rather of making it clear in the specification that any proper decoder MUST reject such input. I think the document would be improved by a section explicitly describing decoding, of which such a check would be a natural part. Kyle From nobody Fri Feb 25 04:36:58 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 5A1E23A0AAA for ; Fri, 25 Feb 2022 04:36:33 -0800 (PST) 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: <164579259334.24498.1807930857332990708@ietfa.amsl.com> Date: Fri, 25 Feb 2022 04:36:33 -0800 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: Fri, 25 Feb 2022 12:36:34 -0000 Review instructions and related resources are at: https://trac.ietf.org/trac/sec/wiki/SecDirReview For telechat 2022-03-03 Reviewer LC end Draft Aanchal Malhotra 2021-10-15 draft-ietf-kitten-tls-channel-bindings-for-tls13 Daniel Migault 2021-06-28 draft-ietf-ipwave-vehicular-networking Kathleen Moriarty 2022-02-24 draft-ietf-ipsecme-ikev2-intermediate Samuel Weiler R2021-08-25 draft-ietf-alto-path-vector Brian Weis 2021-08-19 draft-ietf-dnsop-svcb-https For telechat 2022-03-10 Reviewer LC end Draft Daniel Gillmor 2022-01-28 draft-ietf-rats-yang-tpm-charra Sandra Murphy 2022-03-07 draft-rsalz-2028bis 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 Phillip Hallam-Baker R2022-02-23 draft-ietf-dprive-dnsoquic Steve Hanna 2022-01-24 draft-ietf-dots-telemetry 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 2021-06-28 draft-ietf-ipwave-vehicular-networking Kathleen Moriarty 2022-02-24 draft-ietf-ipsecme-ikev2-intermediate Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Sandra Murphy 2022-03-07 draft-rsalz-2028bis Hilarie Orman 2022-03-02 draft-ietf-tcpm-yang-tcp Radia Perlman 2022-02-28 draft-ietf-ace-aif Derrell Piper 2022-03-03 draft-ietf-ace-mqtt-tls-profile Stefan Santesson 2021-08-11 draft-ietf-bier-te-arch Samuel Weiler R2021-08-25 draft-ietf-alto-path-vector Brian Weis 2021-08-19 draft-ietf-dnsop-svcb-https Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Liang Xia 2021-09-07 draft-ietf-bess-evpn-igmp-mld-proxy 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 Christopher Wood 2021-12-20 draft-ietf-opsawg-mud-iot-dns-considerations Next in the reviewer rotation: Tirumaleswar Reddy.K Vincent Roca Kyle Rose Joseph Salowey Rich Salz Stefan Santesson Benjamin Schwartz Yaron Sheffer Rifaat Shekh-Yusef Melinda Shore From nobody Fri Feb 25 13:39:15 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 DE4713A0A52; Fri, 25 Feb 2022 13:38:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Samuel Weiler via Datatracker To: Cc: alto@ietf.org, draft-ietf-alto-path-vector.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: <164582513375.24683.540286870035746289@ietfa.amsl.com> Reply-To: Samuel Weiler Date: Fri, 25 Feb 2022 13:38:53 -0800 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-alto-path-vector-22 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, 25 Feb 2022 21:38:54 -0000 Reviewer: Samuel Weiler Review result: Not Ready The security considerations text in this document has changed markedly - and multiple times - from when I reviewed it at version -19. I'm flagging this as "Not Ready" mostly because I think it deserves another set of eyes (e.g. the ADs'). An intermediate version (-20) required the use of Digital Right Management (DRM). In -22, that's toned down to a recommendation. What other non-DRM technical solutions might help? It feels weird to have the the server being instructed do out-of-band things, e.g.: The ALTO server MUST carefully verify that the deployment scenario satisfies the security assumptions of these methods before applying them to protect Path Vector services with sensitive network information. This sounds like a requirement for the operator of the server, which the server is in no position to enforce - and we're providing no technical measure for enforcing.