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 -- [email protected] To unsubscribe send an email to [email protected]
