Hi Brian,
Thanks for taking care of the comments. The changes look good to me.
One comment about the updated CDDL, you may consider better presentation of the
record content as a function of the message. For example (but you will be more
inspired :-)):
$admin-record /= [0xFFFF, acme-record]
; A record can be in a Challenge or a Response
acme-record = (
challenge-record / response-record
)
..
And one nit in Section 1.5 : s/internet protocol/IP.
I will clear my DISCUSS once the new version is published.
Cheers,
Med
De : Brian Sipos <[email protected]>
Envoyé : mercredi 4 juin 2025 04:40
À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; Richard Barnes
<[email protected]>
Cc : The IESG <[email protected]>; [email protected];
[email protected]; [email protected]
Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-acme-dtnnodeid-17: (with
DISCUSS and COMMENT)
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
<[email protected]<mailto:[email protected]>> 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/
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
Acme mailing list -- [email protected]
To unsubscribe send an email to [email protected]
