[Anima] Benjamin Kaduk's Yes on draft-ietf-anima-autonomic-control-plane-29: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-anima-autonomic-control-plane-29: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

We're down to largely editorial stuff at this point, and I'm happy with the overall
state of things.

A couple of the new bits in the -29 might benefit from targeted review (noted
inline), e.g., for CDDL, TSV, or INT-specific aspects.

Section 6.1

   TLS MUST offer TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and
   TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and MUST NOT offer options
   with less than 256 bit symmetric key strength or hash strength of
   less than SHA384.  When TLS 1.3 is supported, TLS_AES_256_GCM_SHA384

One could potentially say "hash strength of less than 384 bits" instead
of anchoring the reference point at SHA384, but I'm not terribly
concerned about it.

   TLS MUST also include the "Supported Elliptic Curves" extension, it
   MUST support the NIST P-256 (secp256r1(22)) and P-384 (secp384r1(24))
   curves [RFC4492].  In addition, TLS clients SHOULD send an
   ec_point_formats extension with a single element, "uncompressed".

We can say "TLS 1.2 clients" for the ec_point_format extension (nit: no 's').

Section 6.2.1

Thank you for clarifying the "serialNumber" attribute; I think that will
be helpful for a lot of people.

   ACP nodes MUST NOT support certificates with RSA public keys whose
   modulus is less than 2048 bits, or certificates whose ECC public keys
   are in groups whose order is less than 256 bits.  RSA signing
   certificates with 2048-bit public keys MUST be supported, and such

I think I mentioned this previously (and sorry for the repetition if I
did), but just in case I didn't: this 256-bit group order requirement
excludes Ed25519 and friends.  If you're fine with that, that's okay; I
just want to make sure it's an informed choice.

   ACP nodes MUST support RSA certificates that are signed by RSA
   signatures over the SHA-256 digest of the contents, and SHOULD
   additionally support SHA-384 and SHA-512 digests in such signatures.
   The same requirements for certificate signatures apply to ECDSA
   certificates, and additionally, ACP nodes MUST support ECDSA
   signatures on ECDSA certificates.

I think "same requirements for digest usage in certificate signatures"
is more accurate.

   In support of ECDH key establishment, ACP certificates with ECC keys
   MUST indicate to be Elliptic Curve Diffie-Hellman capable (ECDH): If
   the X.509v3 keyUsage extension is present, the keyAgreement bit MUST
   be set.

I think I may have failed to think about and comment on this previously,
but doing direct ECDH with the (static) key in the certificate is pretty
uncommon -- as I understand it you don't need this bit set in order to
use the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ciphersuite, for
example.  To be clear, I'm not saying it's inherently wrong to make this
requirement, just that I don't think it's needed for the use-cases
presented in this document.  (It may also make it harder to get such
certificates issued in the future, though it's hard to predict what
path CA policies will take in the future.)

Section 6.2.3

It might be nice to say something about in what cases the transport
address used to reach the peer can/cannot be validated against the
acp-address in the peer's ACP certificate.  I think there are some
classes of interactions for which that check can be done and would add
value, even though there are definitely some classes of interaction for
which it is not viable.

Section 6.2.5.3

   When using a private PKI for ACP certificates, the CRL may be need-
   to-know, for example to prohibit insight into the operational
   practices of the domain by tracking the growth of the CRL.  In this
   case, HTTPS may be chosen to provide confidentiality, especially when
   making the CRL available via the Data-Plane.  Authentication and
   authorization SHOULD use ACP certificates and ACP domain membership
   check.  [...]

(I assume that the SHOULD here is still only in the case where the CRL
is need-to-know; no text changes needed if that's correct.)

Section 6.2.5.5

   To prohibit attacks that attempt to force the ACP node to forget its
   prior (expired) certificate and TA, the ACP node should alternate
   between attempting to re-enroll using its old keying material and
   attempting to re-enroll with its IDevID and requesting a voucher.

I think that as written, this doesn't fully "prohibit" such attacks (but
does make them harder and is good advice).  I suppose some nodes might
continue trying with the old key material for some time even after
obtaining a new voucher, but the state-keeping requirements for that are
big enough that we shouldn't require it.  So I'd suggest just a small
change like s/To prohibit/As a countermeasure against/.

   Maintaining existing TA information is especially important when
   enrollment mechanisms are used that unlike BRSKI do not leverage a
   mechanism (such as the voucher in BRSKI) to authenticate the ACP
   registrar and where therefore the injection of certificate failures
   could otherwise make the ACP node easily attackable remotely by
   returning the ACP node to a "duckling" state in which it accepts to
   be enrolled by any network it connects to.  The (expired) ACP
   certificate and ACP TA SHOULD therefore be maintained and used for
   re-enrollment until new keying material is enrolled.

(editorial) the wording here should probably be checked; right now it
seeems to be saying "use X for re-enrollment until [re-enrollment
succeeds]" which makes me wonder how the new keying material would come
into play.

Section 6.4

Figure 7 has some nits, now -- '|' is not a CDDL keyword.
Also, we should probably get a CDDL expert to look at it, since both
method-params and extensions are 1*any, and I'm not 100% sure what the
order of binding is (Appendix A of RFC 8610 suggests that it is a
prioritized choice in CDDL, so things after the first comma would always
be parameters, not extensions).

   Attackers on a subnet may be able to inject malicious DULL GRASP
   messages that are indistinguishable from non-malicious DULL GRASP
   messages to create Denial-of-Service (DoS) attacks that force ACP
   nodes to attempt many unsuccessful ACP secure channel connections.
   When an ACP node sees multiple AN_ACP objectives for the same secure
   channel protocol on different transport addresses, it SHOULD prefer
   connecting via the well-known transport address if the secure channel
   method has one (such as UDP port 500 for IKEv2).

This new text should probably be run by some TSV-area reviewer (e.g.,
AD).

Section 6.8.3.1

   The IKEv2 Diffie-Hellman key exchange group 19 (256-bit random ECP),
   MUST be support.  Reason: ECC provides a similar security level to

nit: "supported".

Section 6.8.3.2

   If IKEv2 initiator and responder support IPsec over GRE, it will be
   preferred over native IPsec because of the way how IKEv2 negotiates
   transport mode as used by this IPsec over GRE profile) versus tunnel
   mode as used by native IPsec (see [RFC7296], section 1.3.1).  The ACP

nit: missing open paren?

Section 9.2.2

   *  Policies if candidate ACP nodes should receive a domain
      certificate or not, for example based on the devices IDevID
      certificate as in BRSKI.  The ACP registrar may have a whitelist
      or blacklist of devices [X.520] "serialNumbers" attribute in the
      subjects field distinguished name encoding from their IDevID
      certificate.

I note we had that long ietf@ thread about terminology, that included
"whitelist" and "blacklist", and trust you to make an informed choice
about terminology usage.

Section 9.3.5.2

   When a greenfield node enables multiple enrollment/botstrap
   protocols/mechanisms in parallel, care must be taken not to terminate
   any protocol/mechanism before another one has progressed to a point
   where greenfield state is defined to end.

(editorial) Do we give a clear definition of when greenfield state is
defined to end, that would apply to arbitrary such mechanisms?  We might
want to reword a little bit.

Section 11

Wow, so much new good stuff here; thanks!

   *  For IDevIDs to securely identify the node to which it IDevID is
      assigned, the node it needs to (1) utilize hardware support such
      as a Trusted Platform Module (TPM) to protect against extraction/
      cloning of the private key of the IDevID and (2) a hardware/
      software infrastructure to prohibit execution of non authenticated
      software to protect against malicious use of the IDevID.

nit: s/node it needs to/node needs to/

   *  A malicious ACP node could declare itself to be an EST server via
      GRASP across the ACP if malicious software could be executed on
      it.  CA should therefore authenticate only known trustworthy EST
      servers, such as nodes with hardware protections against malicious
      software.  Without the ability to talk to the CA, a malicious EST
      server can still attract ACP nodes attempting to renew their
      keying material, but they will fail to perform successful renewal
      of a valid ACP certificate.  The ACP node attempting to use the
      malicious EST server can then continue to use a different EST
      server, and log a failure against a malicious EST server.

We have two copies of basically this text.  The second one (that I
quoted) does not have a note about id-kp-cmcRA, and is the one that
should be removed.

   If public CA are to be used, ACP registrars would need to prove
   ownership of the domain-name of AcpNodeNames to the public CA.
   However, maintaining the ULA based address allocation when using a
   public CA might be considered to be a violation of the private
   allocation expectation of ULA prefixes.  To avoid this issue, further
   changes to registrar address allocation procedures might be needed,
   for example using global IPv6 address prefixes owned by the public CA
   instead of ULA.

I don't expect any problems here, but it might be good to get some
INT-area (e.g., AD) eyes on this text.

Section 12

   0: ACP Zone Addressing Sub-Scheme (ACP RFC 1: ACP Vlong Addressing
   Sub-Scheme (ACP RFC Figure 12) / ACP Manual Addressing Sub-Scheme
   (ACP RFC Section 6.11.4) Section 6.11.5)

Something went awry here (maybe just formatting?), as the '1' is
supposed to be the initial value allocated by this document, not a
reference to RFC 1.

Section 16

RFC 4492 is obsoleted by RFC 8422.

Section A.6

   When the two peers successfully establish the GRASP/TSL session, they
   will negotiate the channel mechanism to use using objectives such as

nit: s/TSL/TLS/

Section A.10.9

Thank you for adding this discussion; it is a good treatment of the
issues and considerations in play.