Thanks, David! Barry
On Tue, Mar 14, 2023 at 10:46 AM von Oheimb, David <[email protected]> wrote: > > Hi Barry, > > thank you for your review (of early January) on BRSKI-AE draft version 03. > It was helpful to improve both the contents of the draft and its presentation. > > Meanwhile we have addressed all issues/points brought up this way. > Yesterday I've uploaded version 04, which includes the respective changes, > as well as various further improvements due to two recent internal reviews. > > Here is the excerpt of the change log for version 04 regarding your review: > > * In response to SECDIR Early Review of ae-03 by Barry Lea, > > - replace 'end-to-end security' by the more clear 'end-to-end > authentication' > > - restrict the meaning of the abbreviation 'AE' to 'Alternative Enrollment' > > - replace 'MAY' by 'may' in requirement on delegated registrar actions > > - re-phrase requirement on certificate request exchange, avoiding MANDATORY > > - mention that further protocol names need be put in Well-Known URIs > registry > > - explain consequence of using non-standard endpoints, not following SHOULD > > - remove requirement that 'caPubs' field in CMP responses SHOULD NOT be used > > - add paragraph in security considerations on additional use of TLS for CMP > > > We believe that we have followed all comments and suggestions you gave. > > David > > > On Tue, 2023-01-10 at 12:07 -0800, Barry Leiba via Datatracker wrote: > > Reviewer: Barry Leiba > Review result: Has Issues > > The main issue I have is with the term “end-to-end security”, both in general > and especially as it’s applied in the text quoted below. I don’t know what > that term means, just as the general term “security” doesn’t have much meaning > by itself. “End-to-end encryption” is what we usually use, and its meaning is > clear, but that isn’t what you generally mean in this document. I suggest > avoiding “end-to-end security” throughout, and being more specific about what > you’re actually talking about in each instance (encryption, confidentiality, > integrity, or whatever). > > — Section 1.1.2 — > > This approach > supports end-to-end security, without the need to trust in > intermediate domain components. > > This doesn’t seem to match what we usually think of as e2e security — which is > better referred to as e2e encryption. As I say above, I suggest avoiding that > term here. What you have is integrity protection for the enrollment objects, > without having (and without needing) e2e encryption of the enrollment process. > > This > enhancement of BRSKI is named BRSKI-AE, where AE stands for > *A*lternative *E*nrollment and for *A*synchronous *E*nrollment. > > It doesn’t seem a good practice to say that a particular abbreviation can > stand > for two different things. I think it would be better to pick one to call out > as what “AE” stands for. > > — Section 2 — > > Nit: “comprising of” isn’t proper English; it should just be “comprising” (or > “composed of”, but “comprising” is better here). Two instances. > > — Section 4.1 — > > Consequently, the authentication and authorization of the > certification request MAY be done by the domain registrar and/or by > other domain components. These components may be offline or reside > in some central backend of the domain operator (off-site) > > The “MAY” in the first sentence is just like the “may” in the second sentence: > it should be lower case, as it’s not used as a BCP 14 key word. (The other > “MAY” at the end of the same paragraph looks fine.) > > — Section 4.2.3 — > > The only generally MANDATORY message exchange is for the actual > certificate request and response. > > “MANDATORY” is not a BCP 14 key word. Do you mean it as plain English > “mandatory”? Or do you mean it to be the BCP 14 key word “REQUIRED”? In the > diagram below (Figure 2) you should definitely use “REQUIRED” instead of > “MANDATORY”. > > — Section 4.3 — > > * <enrollment-protocol>: MUST reference the protocol being used. > Existing values include EST [RFC7030] as in BRSKI and CMP as in > [I-D.ietf-lamps-lightweight-cmp-profile] and Section 5.1 below. > Values for other existing protocols such as CMC and SCEP, or for > newly defined protocols, require their own specifications for > their use of the <enrollment-protocol> and <request> URI > components and are outside the scope of this document. > > They require not just their own specifications, but registration of their > <enrollment-protocol> into the Well-Known URIs registry. It would be good to > say that, perhaps using RFC 7030 as an example. > > A pledge SHOULD use the endpoints defined for the enrollment > protocol(s) that it is capable of. > > Why “SHOULD” and not “MUST”? What are the alternatives, why might the pledge > not use the defined endpoints, and what are the consequences of not doing so? > > — Section 5.1 — > > In certificate response messages the caPubs field, which > generally in CMP may convey CA certificates to the requester, > SHOULD NOT be used. > > Similar to above: Why “SHOULD NOT”? What happens if it *is* used? Should > there be any instructions about what to do with it (or ignore it, or > whatever)? > > — Section 7 — > > You correctly note that the CMP security considerations apply. Yet it strikes > me that there might be security implications that are specific to applying CMP > to BRSKI, as it’s a different way of binding things and authenticating than > has > been used in BRSKI before. As I don’t know a lot about BRSKI to start with, I > have no specific suggestions here, but I wonder how much this was thought > about, and what the BRSKI-specific implications of this mechanism really are. > For example, are there possible issues with an attacker intercepting the data > elements here, even if the elements are integrity-protected. Are there > possible issues with an attacker preventing delivery of some elements, or > injecting the attacker’s own self-signed elements? That sort of thing, which > EST is protected from by the use of TLS. > > Looking at the building automation example, for instance, which talks about > many sensors, actuators, and controllers, could an attacker gain useful > information by knowing what devices (and/or what types of devices) are being > registered, or by blocking the registration of certain devices to create areas > of vulnerability? > > Just stuff to think about, if it hasn’t been considered and ruled out already. > > And thanks for considering my review! > > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
