Last Call Review of draft-ietf-anima-brski-prm-17
review-ietf-anima-brski-prm-17-secdir-lc-hardaker-2025-02-04-00

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]

More specific comments:

1. EST should be expanded on its first use (introduction)

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.

3. Section 4 starts with "...the following requirements..." but the bullets
themselves aren't really written as "requirements".

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.

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.

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.

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.

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.

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.

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.

11. 7.3.5 and example in figure 22: it would be good if this figure contained
the agent-proximity string too.

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?

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"?

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.

--
Wes Hardaker
USC/ISI