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

[Benjamin Kaduk <[e-mail]>]

On Tue, Oct 06, 2020 at 04:43:31PM -0400, Michael Richardson wrote:
> On 2020-10-01 6:36 p.m., Benjamin Kaduk via Datatracker wrote:
> > 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.
> 
> Carsten has already done that for CDDL.

(If you have a link handy, I'd love to have it.  I couldn't quite convince
myself that RFC 8610 actually said that CDDL has the "first successful
match" nature of a PEG, with respect to the method-params and extensions.
Maybe I was just reading too quickly.)

> I'm unclear what TSV and INT specific things you have in mind.

Sorry; this was:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
   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).
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
(Specifically, the use of the well-known port as a signal.)

and

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
   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.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
(The ULA usage here is IIUC a bit different than previous revs of the
draft.)


> 
> >     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.
> 
> Right, Ed25519 is considered to be a curve of 128-bits of equivalent 
> strength.  My understanding is that secp256*, while having 256-bit 
> curves, is also 128-bits of strength.
> And RSA keys of 2048 bits is also of that relative strength.
> 
> I think that this is what Toerless is trying to say, but he didn't get 
> the wording right.  Can you advise what the correct way to ask for this 

This one is a bit awkward, since we need to allow 2048-bit RSA based on our
understanding of the TPM ecosystem, but 2048-bit RSA is currently thought
to have roughly 112 bits of strength (you need 3072-bit RSA to get 128-bit
strength).  RFC 8032 hedges a little bit to say that "Ed25519 is intended
to operate at around the 128-bit security level" (i.e., just below).  The
smallest possible change here would be s/256/254/, I think, but it could be
restructured a bit to be genericized if we want, perhaps:

% The ACP aims to provide authentication at around the 128-bit security
% level or stronger.  Accordingly, ACP nodes MUST NOT support certificates
% whose ECC public keys are in groups providing weaker security than this
% 128-bit level.  In order to accomodate limitations of TPM hardware
% modules, this requirement is slightly weakened for RSA certificates; ACP
% nodes MUST NOT support certificates with RSA public keys whose modulus is
% less than 2048 bits (which corresponds to roughly a 112-bit security
% level).  RSA signing certificates with [...]

A parenthetical note that "(this explicitly permits Ed25519 keys)" is
possible, but probably optional.

> is?  Can we just point elsewhere?

I am not thinking of anything offhand that we can just refer to,
unfortunately.

> > 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.)
> 
> Agreed, and it's why I prefer to say less.

That's my preference, too, but (as Brian has recently reminded us [0]) I'm not
in charge.

-Ben

[0] https://www.ietf.org/id/draft-carpenter-nomcom2020-letter-00.html