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 -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
