Hello Wes, My email went out without my reaction on your last comment. Here it is: > 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 > -----Original Message----- > From: Fries, Steffen <steffen.fries@xxxxxxxxxxx> > Sent: Tuesday, February 4, 2025 6:43 PM > To: Wes Hardaker <wjhns1@xxxxxxxxxxxxx>; draft-ietf-anima-brski- > prm.all@xxxxxxxx; secdir@xxxxxxxx; last-call@xxxxxxxx > Subject: RE: secdir review of draft-ietf-anima-brski-prm-15 > > 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 -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
