Trust anchor pinned to ECDSA P-256 in CLI check. Anchors issued by a P-384 CA hierarchy not possible?

[fdeantoni]

Hi All,

I see in the code that P-256 + ecdsa-with-SHA256 is enforced:

linkerd2/pkg/issuercerts/issuercerts.go

Lines 174 to 188 in 3af2f45

	func checkECDSACertRequirements(cert *x509.Certificate) error {
	k, ok := cert.PublicKey.(*ecdsa.PublicKey)
	if !ok {
	return fmt.Errorf("expected ecdsa.PublicKey but got something %v", cert.PublicKey)
	}
	if k.Params().BitSize != 256 {
	return fmt.Errorf("must use P-256 curve for public key, instead P-%d was used", k.Params().BitSize)
	}
	if cert.SignatureAlgorithm != x509.ECDSAWithSHA256 &&
	cert.SignatureAlgorithm != x509.SHA256WithRSA {
	return fmt.Errorf("must be signed by an ECDSA P-256 key, instead %s was used", cert.SignatureAlgorithm)
	}
	return nil
	}

This can pose a problem if a company has a strict policy to only allow P-384.

Is there a specific reason P-256 is enforced? If I create a PR to support P-384 + ecdsa-with-SHA384, is there a chance it will get merged?

Note that this policy seems to be only enforced in the CLI check. Things seem to work perfectly fine on the cluster when using a trust anchor with P-384 + ecdsa-with-SHA384.

[alpeb]

Hi @fdeantoni, thanks for the detailed writeup. In order to figure the right priority for this, can you clarify whether this is causing you an actual production problem, or is the impact limited to linkerd check failing?

[fdeantoni]

I have deployed Linkerd on clusters with P-384 and so far I have not discovered any issues. To me this then seems limited to the linkerd check failing.

[Yash121l]

As far as I can tell this is a check-only restriction, not a proxy limitation. The P-256 test lives in one place, checkECDSACertRequirements in pkg/issuercerts/issuercerts.go, which rejects any ECDSA key with BitSize != 256, and its only non-test caller is the "trust anchors are using supported crypto algorithm" checker in pkg/healthcheck. On the data plane the proxy configures webpki with the full ECDSA set including P-384 and secp384r1 in its key exchange groups (linkerd/rustls/src/crypto.rs in linkerd2-proxy), so a P-384 anchor and a P-384-signed issuer verify fine at runtime. What is pinned to P-256 is the proxy's own leaf key (ECDSA_NISTP256_SHA256 in meshtls/src/creds/store.rs), which is independent of the anchor's curve. If someone loosens the check, createTemplate in pkg/tls/ca.go also hardcodes x509.ECDSAWithSHA256 for everything Linkerd issues, so a P-384 issuer would still sign leaves with SHA-256 unless that follows the key size.