[secdir] Re: secdir review of draft-ietf-anima-brski-prm-15

["Fries, Steffen" <[e-mail]>]

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 <[e-mail]>
> Sent: Tuesday, February 4, 2025 6:43 PM
> To: Wes Hardaker <[e-mail]>; draft-ietf-anima-brski-
> [e-mail]; [e-mail]; [e-mail]
> 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 <[e-mail]>
> > Sent: Monday, February 3, 2025 8:17 PM
> > To: [e-mail]; [e-mail];
> > [e-mail]
> > 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