Hi Gorry, Thank you for your comments. I put the reaction inline marked with [stf]. @mcr, thank you for pushing the email out.
We will incorporate the changes as indicated below in the next version. The intermediate version is available on https://github.com/anima-wg/anima-brski-prm. We will incorporate the changes into this version likely tomorrow. Diff with version 18: https://author-tools.ietf.org/diff?doc_1=draft-ietf-anima-brski-prm&url_2=https://raw.githubusercontent.com/anima-wg/anima-brski-prm/refs/heads/main/draft-ietf-anima-brski-prm.txt. Best regards Steffen > -----Original Message----- > From: Michael Richardson <mcr+i...@sandelman.ca> > Sent: Tuesday, April 15, 2025 5:23 PM > To: Gorry Fairhurst <go...@erg.abdn.ac.uk>; The IESG <i...@ietf.org>; draft- > ietf-anima-brski-...@ietf.org; anima-cha...@ietf.org; anima@ietf.org; > i...@kovatsch.net; t...@cs.fau.de > Subject: discuss comments from Gorry > > > https://datatracker.ietf.org/doc/draft-ietf-anima-brski-prm/ballot/ > The comments from Gorry did not get to the mailing list and are not in the > archives. > We were confused by this, until we saw that it says "Not sent" in the upper > corner. > I didn't know that was an option, or a thing, and I'm guessing maybe > Gorry didn't either. I wondered perhaps if the plumbing failed, but I guess > intentional. > > Here they are for the purposes "of the tape" (archive) his comments: > > ---- > > Thank you for preparing this document. I have the following four questions > where > I'd appreciate more clarity in the text: > > 1. The text says: “SHOULD NOT provide information beneficial to an attacker”. > > I don’t understand the RFC 2119 SHOULD recommendation. To me, the current > text does not say what actually has to be done, or what ought not to be done > (e.g. > citing some suitable RFCs to help clarify what is needed). Also I do wonder > whether this be a “MUST”? (i.e., under what conditions is it considered good > to > provide information to benefit an attacker?). Could this just be wisdom - > e.g.”needs to avoid”, rather than a protocol requirement? [stf] correct finding, the normative language is wrong here. Proposal to replace OLD SHOULD NOT provide information beneficial to an attacker NEW should not provide information beneficial to an attacker > 2. “TLS 1.2 MAY be used”, please could you explain why this is only "MAY" > rather than being stronger, noting draft-ietf-uta-require-tls13 and RFC 9325, > which > asserts that TLS 1.3 is in widespread use. [stf] Discussion to that already started on UTA and ANIMA WG list. Main motivation in BRSKI-PRM as extension to BRSKI, is to keep backward compatibility and provide the same requirements as the RFC 8995 and also the availability of TLS 1.3 in existing frameworks. > 3. I could not understand the protocol action of the “MUST” requirement below > (i.e. > what does “available” mean for a RFC2119 requirement?: > > “if the certificate chain > is not included in the x5c Header Parameter, it MUST be available > at the domain registrar for verification” > Please consider changing this text, for instance text like the following > could be > helpful: > “if the certificate chain is available at the domain registrar for > verification, it MAY be omitted from the x5c Header Parameter“. [stf] okay, understood. The intention was to underline that if the information is not available in the response, it must be available at the registrar to enable validation of the response. > 4. Please update the text to explain/clarify: > “The registrar MAY consider ignoring any but the newest PER > artifact from the same pledge in case the registrar has at any point > in time more than one pending PER from the pledge?" > I don't understand the requirement from the text, please explain: For > example, could this perhaps be a RFC2119 requirememnt: "MAY ignore" .. and > then add text to describe when this is allowed (or not). [stf] agreed, will be updated accordingly > Comment (2025-04-10) Not sent > 1. There appears to be some slight format problem with the bullets I saw > listed in > my rendering: > > “such as: * Avoid > logging personally identifiable information unless unavoidable. * Anonymize or > pseudonymize data where possible.” [stf] agreed, will be repaired > 2. I did not understand the list of three security considerations at the > start of > section 12. At least, it would be very helpful to explain these in sufficient > detail to > understand each, and also helpful to understand the implications for users of > each. > Some words to clarify would be very helpful. [stf] It was intended as an intro to the following subsections. Proposal to update from OLD Further security aspects are considered here related to: NEW Further security aspects considered in the following subsections related to: > 3. Please could you add text to explain “no transport layer security between > Registrar-Agent and pledge..” e.g., please explain: Is this something that > users > ought to add to a design? how? why? is it a desirable property? Why? > ... or is this intended to be explained more in the next subsections? > ... Especially since 7.1 speaks of optional use of TLS. [stf] We tried to explain the optional usage of TLS in section 7.1 and section 11 to underline that it is recommended to be used if there are privacy requirements to be addressed. The utilized self-contained objects are integrity protected but still readable. If there is sensitive information included (user names, etc.) confidentiality is likely desired and can be provided using TLS. > 4. Please update the text to clarify what is intended by: “Pledges MAY support > both initiator and responder mode.” Is this MAY intended to permit > *both* of the modes, or *either* of the modes, or something else? [stf] good point, this is more a pledge capability question and not intended as normative may. Proposal to change from OLD Pledges MAY support both initiator and responder mode. NEW Pledges may support both initiator and responder mode. > 5. Please consider updating the text: > “503 Service Unavailable: if a simple retry of the Registrar-Agent > request might lead to a successful response; this error response > SHOULD include the Retry-After response header field with an > appropriate value” > > - Why is this not a MUST, if there is a reason, please explain the > alternative and when this is a suitable response. [stf] Good point. Proposal to change to MUST. > > -- > Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > _______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
