Hello Wes, Thank you for your review. We will address the your comments in the next version of the document. I made some inline comments to the points your raised and also provided suggestions to be taken over in the next version to address your comments. > -----Original Message----- > From: Wes Hardaker <wjhns1@xxxxxxxxxxxxx> > Sent: Monday, February 3, 2025 8:17 PM > To: draft-ietf-anima-brski-prm.all@xxxxxxxx; secdir@xxxxxxxx; last-call@xxxxxxxx > Subject: secdir review of draft-ietf-anima-brski-prm-15 > > > Up top: So I'm in Tero's summary assignment list as being assigned to this > document, but when I finished the review and went to look at the datatracker I see > that Charlie Kaufman is actually assigned to it as well (as a re-review). So > apparently you may get two reviews from the secdir instead? I'm confused here... > > > 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. > > A note about my background: I'm very familiar with the DNS and how the > registry/registar system works, but not familiar with the work of anima or the work > of the BRSKI framework specifically. > > Again, apologies for the delay in this review as January turned out to be a very > long with both hardware failures and a very nasty human virus (and now yesterday > an all-day power-outage). > > The summary of the review is: ready with a few minor comments/nits > > Version reviewed: -15 > > Overall: the document is, of course, very lengthy but generally well organized and > each of the protocol description sections are easy to follow. I'll note that the > excellent timing diagram in the top of section 7 would have been highly helpful to > have seen earlier in the document in order to help the reader come to terms with > the larger goal of the protocol. There are wording issues in various places, it > would be good for the authors to make one last read top-to-bottom for clarity > purposes. [based on looking at -17 while typing this up, it looks like this may have > already been done] [stf] Yes, we tried to further ensure correct terminology usage and provided further updates. Meanwhile we also addressed further comments and have an intermediate version in the ANIMA git > > More specific comments: > > 1. EST should be expanded on its first use (introduction) [stf] Thanks, incorporated as suggested > > 2. The terminology specifically section could use some stronger definitions. For > example "CA: Certification Authority, issues certificates." is rather short and > although everyone that understands what a CA is will already understand it, new > readers will not benefit much from such a short definition. [stf] Included some further information like maintenance of revocation information for the CA. In general, we expected the reader to be familiar with most of the terms as they are already used in base or related specifications like RFC 8995. > > 3. Section 4 starts with "...the following requirements..." but the bullets themselves > aren't really written as "requirements". [stf] Yes, true, proposal to rename to "... the following boundary conditions ..." > > 4. Section 5.3: "which may result in undesirable communications pattern". It would > be helpful to have this negative communication pattern better defined for the > reader. [stf] Okay, understood. The intention was to outline that there may be increased communication during the onboarding in BRSKI depending on the number of pledges onboarding simultaneously OLD: In [RFC8995], pledges instead need to continuously request enrollment from a domain registrar, which may result in undesirable communications pattern and possible overload of a domain registrar. NEW: In [RFC8995], pledges instead need to continuously interact with the domain registrar during onboarding, through discovery, voucher exchange, and enrollment. This may increase the load on the domain registrar, specifically, if a larger number of pledges onboards simultaneously. > > 5. Similarly, in 6.1 "it is RECOMMENDED to use short lived Registrar-Agent EE > certificates", but no where does it discuss why. Without a background behind > statements like this, you risk that the reader will ignore the recommendation if they > can't see the security reasoning behind it. [stf] Proposal to Include "This is to address the assumed nature of stand-alone Registrar-Agents as nomadic devices (see section 5.2) and to avoid potential misuse as outlined in in Section 12.3." This provides some reasoning upfront and points to the security consideration section handling that case. > > 6. The document talks about security (potentially many) devices of various types > as they begin operation, but no where does it enumerate the issues with devices > that have been on the shelf for a long time before power-on and discuss the > ramifications of trust anchors within them that may be stale. [stf] BRSKI-PRM (s BRSKI) build upon IDevIDs (including the trust anchors) provided during manufacturing. The expectation on IDevID certificates is that they typically have a validity period in the area of the lifetime of the product. They are only used to bootstrap operational certificates (LDevID certificates) with a much shorter lifetime. But yes, if they are taken out of operation and reapplied without proper re-onboarding, they may fail. I propose to provide a statement in Section 9, Operational considerations (was introduced in version 16) to address this: "BRSKI-PRM requires pledges to possess an IDevID to enable onboarding in new domains. IDevID (and corresponding trust anchors) are expected to have a rather long lifetime. This may allow for a longer period between device acquisition and initial onboarding. Contrary, if devices that have been provided with an LDevID (and corresponding trust anchors) and temporarily taken out of service, immediate connectivity when bringing them back to operation may not be given, as the LDevIDs typically have a much shorter validity period compared to IDevIDs. It is therefore recommended to onboard them as new devices to ensure they possess valid LDevIDs." > > 7. In many places (mostly in section 7) it states that TLS is optional as object > security properly secures the actual underlying data (objects) being transferred > around, which makes sense. However, TLS is referenced as being helpful to > provide privacy for the exchange (eg. section 7.1 (and 7.2 and ...) "TLS MAY be > used..."). But that's not the only goal of a transport security: it can also assure > you're talking to the end-entity you believed you were attempting to establish a > connection with. End-point verification may be a useful feature worth spelling out > in these sentences as well. [stf] Proposal to include this in section 7.1 OLD Optionally, TLS MAY be used to provide privacy for this exchange between the Registrar-Agent and the pledge (see Appendix B). NEW Optionally, TLS MAY be used to provide transport security, e.g., privacy and peer authentication, for the exchange between the Registrar-Agent and the pledge (see Appendix B). > > 8. In some places (eg 7.1 again) the document states that the Accept field > SHOULD be set to application/voucher-jws+json, but doesn't ever really say > whether or not the receiving party MAY choose to accept a connection from an > entity that doesn't have an Accept field and simply assume this. There is an error > for what happens when you refuse to, but no flip side of can the connection > receiver just make assumptions in absence of information. [stf] Good point! Included: - "If the Accept header was not provided in the PVR, the pledge assumes that the accepted response format is application/voucher-jws+json and proceeds processing." into section 7.1 - "If the Accept header was not provided in the PER, the pledge assumes that the accepted response format is `application/voucher-jws+json` and proceeds processing. " into section 7.2 > > 9. I think the clock drift situations in 7.2.2.3 a bit understate the problem. Clock > drift without connections always has rather bad drift accuracy issues without a > highly accurate clock source available to them. [stf] The note was intended as a hint. Is there anything we could provide in addition? > > 10. I'd like to have a better mime-type string than starting with "voucher" that was > ideally more specific to the voucher this particular system is using. Voucher is > generic but this use case is just to this protocol/application type, and thus I'd > expect/prefer brski-voucher-jws or something. But I recognize this is really a point > for a different document, however, and likely already fairly well set in stone and > monopolized the more generic "voucher" term. [stf] yes, true, we synchronized the naming with the existing BRSKI and voucher RFCs. > 11. 7.3.5 and example in figure 22: it would be good if this figure contained the > agent-proximity string too. [stf] Hm, it was already contained in version 15 and is still available in the last version (17) > > 12. 7.7 "The pledge MAY use the response body to signal success/failure details > to the service technician operating the Registrar-Agent." -- it might be helpful to > suggest that such information be returned as JSON or some other expected > structure. As is, any form could be returned? [stf] Currently, we did not state it explicitly, but since the communication uses JSON already it would be good to provide the suggestion regarding the format directly. Proposal to add the following: "While BRSKI-PRM does not specify which content may be provided in the response body, it is recommended to provided the content as JSON encoded information as other BRSKI-PRM exchanges also utilize this encoding". > > 13. 7.11.1.1: "SHOULD log the contents and alert a human." -- I'd argue that > alerting a human is always an impossible task (or more specifically, there is no way > a for a device to know whether it's alerting another system or a life form). How > about "SHOULD log the contents and emit an operational notification"? [stf] Good suggestion. Took the suggested text directly over into the draft. > > 14. 8.: It would be good to include types of failures to be logged as well. The list > in section 8 seems to only list positive (successful) telemetry. [stf] Section 8 was enhanced based on review feedback from the AD in version 16, which is after the version you reviewed. This should already cater success and failure situations. Best regards Steffen > > > -- > Wes Hardaker > USC/ISI -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
