Reviewers, I have drafted a set of changes intended to address IANA expert feedback and remaining IESG feedback. A non-datatracker difference can be reviewed [2] from the source repository. If these seem acceptable I can update the datatracker revision ahead of the next IESG telechat. Thanks for further feedback, Brian S.
[2] https://author-tools.ietf.org/diff?doc_1=draft-ietf-acme-dtnnodeid&url_2=https://briansipos.github.io/acme-dtnnodeid/draft-ietf-acme-dtnnodeid.txt&raw=1 On Wed, May 28, 2025 at 4:06 AM Mohamed Boucadair via Datatracker < nore...@ietf.org> wrote: > Mohamed Boucadair has entered the following ballot position for > draft-ietf-acme-dtnnodeid-17: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Hi Brian, > > Thank you for the effort put into this well-written the document. It is a > great > read. > > Thanks to Linda Dunbar for OPSDIR (-07/-10) back in 2022. I think the > points > raised by Linda are addressed in the latest version, especially the point > highlighted by Brian at [1] on the subtleties between the various > identifiers. > Section 1.4 is crystal clear to me. > > Key operational considerations are fairly covered in the specification > (e.g., > deployment and topology dependency assumptions, interoperability > considerations > and call out of mandatory to support algos, a good discussion on > configurable > knobs, some default and recommended values) let alone the clear statement > on > policies/configurations matters that are out of scope (Section 1.1). Of > course, > this does not need to be exhaustive given the intended Experimental > status. A > goal of the experiment may be to tune the recommended values, identify > missing > knobs, etc. > > # Meta comment > > It seems the document was WGLCed 4 years ago (2021). It seems also that the > document was blocked because it depends on draft-sipos-dtn-bpv7-admin-iana, > which was published since then as RFC9171 (2023). Some more context and > explanation in the writeup to explain why/how it took us a long cycle get > here > would be helpful. > > # DISCUSS > > ## Experiment scope > > We do say in Section 1: > > | The emergent properties of DTN naming and BP security are still > | being developed and explored, especially between different > | organizational and administrative domains, so the > | "experimental" status of this document is related more to the > | practical utility of this kind of Node ID validation ** than to > | the validation method itself **. > > But then in Section 3.5: > > | ** Part of the experimental nature of this validation method **, > and > | the bundle protocol more generally, is understanding its > | vulnerability to different kinds of on-path attacks. Some > | attacks could be based on the topology of the BP overlay > | network, while others could be based on the underlying > | (internet protocol) network topology. Because not all of the > | attack surfaces of this validation method are known or fully > | understood the usefulness of the technique described in this > | section is also not assured. The point of these requirements > | is so that both the ACME client and server have consistent > | logic for handling this technique. > > and the following in Section 4: > > | The usefulness of the integrity gateway to this validation > | method is experimental because it is not a settled matter how > | naming authority in a DTN is either allocated, delegated, or > | enforced. It is also not defined how the organization running > | the CA (and its ACME server) can delegate some level of trust > | to a different organization running a connected DTN with a > | security gateway. The organization running the integrity > | gateway would need to apply some minimal amount of policy to > | nodes running behind it, such as patterns to their Node IDs, > | which would behave conceptually similar to delegation of sub- > | domains in the domain name system (DNS) but without the online > | interaction of DNS. > > The candidate experimental aspects are scattered in several places of the > document (with an apparent conflict (?) between the two points). The > description of the experiment is thus not clear to me. Can we please > consider > having a single section which describes the experiment and the set of > criteria > to use declare failure/success? > > ## RFC9174 is normative > > This is currently listed as informative, but it is used in a normative > way. For > example; > > CURRENT: > * The Response Bundle Source Node ID is identical to the Node ID > being validated. The comparison of Node IDs SHALL use the > comparison logic of the NODE-ID from Section 4.4.1 of [RFC9174]. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Please find below some few comments: > > # Cite authoritative refs > > CURRENT: > This document describes the ACME messages, BPv7 payloads, and BPSec > > # Code extract frozen in an RFC > > CURRENT: > The entire CDDL structure > can be extracted from the XML version of this document using the > XPath expression: > > '//sourcecode[@type="cddl"]' > > Do we need this to be frozen in an RFC? > > # network policies > > CURRENT: > The specific use case of [RFC9174] allows, and for some > network policies requires, that a certificate authenticate both the > DNS name of an entity as well as the Node ID of the entity. > > Can we elaborate on these policies? > > # NOTE to the RFC Editor > > CURRENT: > [NOTE to the RFC Editor: For [RFC5050] compatibility the AR-TBD value > needs to be no larger than 15, but such compatibility is not needed. > > What is the purpose of this note, especially if you say “compatibility is > not > needed”? These matters are not the territory of the RFC editor, BTW. > > # RFC7942 should be cited as informative. Anyway, that RFC will be removed > from > final RFC. > > Cheers, > Med > > [1] > https://mailarchive.ietf.org/arch/msg/last-call/nujBgHd6ZKHY6fG58ZWBKzFGVWs/ > > > >
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
