Document: draft-ietf-ace-oscore-gm-admin Title: Admin Interface for the OSCORE Group Manager Reviewer: Wes Hardaker Review result: Has Nits
Reviewer: Wes Hardaker Review result: Almost Ready I 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 authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Document: draft-ietf-lsr-ospf-bfd-strict-mode-07 Reviewer: Wes Hardaker Review Date: 2026-02-16 Overall: this is a generally very well written and clear document. Compliments to the authors. The document is quite dense and would generally benefit from multiple readings to get everything straight in one's head, but I only read it once myself. Comments: - note, I'm not an expert in this area of the IETF though I know enough to say some wrong things. Thus you've been warned and can simply ignore comments that make no sense ;-) - I find the usage of double-using the List permission as a distinguisher to decide if a client is an administrator or in Tperm a bit of an odd choice (pg 11). 1. What if you want a user to be able to get a list even though they have other reduced permissions and are not an admin? What if you want an admin to basically have full permissions but get a list? In particular, the list can reveal information that may be sensitive and a finer grained split-admin role would want to potentially not allow either admin to fully list all groups? I'm obviously making up situations, but they are somewhat common in strange corners of network administration. Listing actually is considered a security leak at times, especially when it comes to configuration. - 3.1: note that though wildcard patterns and complex patterns are indeed great for reducing the size of configuration, they can quickly lead to mistakes as well (ask any regex author). - There are a number of cases, especially section 6, where it doesn't explain what to do in error cases. I may have missed the general description of "allways return FOO in the case of errors, unless otherwise directed". In some cases it's related to receiving incorrect parameters (pg 12: "...MUST adhere to the same pattern semantics" -- what if it doesn't?) - A good example of dense text that is subject to implementation differences just because there is a lot of different little clauses is the steps in section 4. It's likely all complete, but it would take a lot of reading to ensure one was following it to the letter. - 4.1 reads more like operational considerations - 5.2: for default values chosen differently by different group manager implementations means potentially a lack of understanding by the administrative client. Adding a SHOULD fetch configuration after a POST or similar to ensure the semantics are expected would be wise, or to simply not rely on default values at all if possible since there is no standardized default. - 6.2: for the first example in this section, I'd be tempted to drop the gp2 entry or something just to show the filter worked. - 6.2: the second example I think is missing the gp6 entry, since the text seems to say it should be there but is not. - 6.3: I find the creation of a new (randomish) group name when a conflict occurs a bit unnerving. Normally in protocols it is better to return an error on conflict rather than make up a different place to store the data. But maybe it's more common in this usage case? - 6.3: this dense text might be better off with a step-by-step approach for numbering the paragraphs as has been done in other sections. - Generically: what are the dangers of having a malicious device return some URIs that point away from the expected target? Could you get the client to go send configuration or connect to a different destination of a malicious actors choosing? Is there cases where the as_uri or similar really should point only to the same device being communicated with? - I worry about cases where two different operations both use a POST or FETCH and the only way to determine what operation the administrator actually wanted to do is to carefully look at the content being pushed. Compare the operations in 6.2 and 6.6 for example, or 6.3 and 6.6. For example, 6.3 and 6.6 one is a create and one is a modify with similar semantics... this can lead to confusion and interpretation errors on both sides. - 8: blurs the lines between error identifiers and operational considerations (not sure there is much to do in these cases, but I'm just pointing them out). - 9.2: the MUST NOT and SHOULDs in this section seem to sort of be saying nearly the same thing but with different MUST/SHOULD values. A group manager MUST not log secrets, but later only SHOULD do redaction? _______________________________________________ Ace mailing list -- [email protected] To unsubscribe send an email to [email protected]
