Early Review of draft-ietf-anima-brski-ae-03
review-ietf-anima-brski-ae-03-secdir-early-leiba-2023-01-10-00

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!