if cipher preferences remain the same when minimum protocol is changed, does s2n still sends tls 1.2 ciphersuites?

my understanding is that yes, it would still send 1.2 ciphersuites. so for a 1.3-requiring policy we can save some bytes on the wire by creating a new cipher_preferences list that elides ≤1.2 ciphersuites.

good catch, I'll create/use a new cipher_preferences list here for TLSv1.3.

As SHA1 & SHA224 are discouraged, Can we remove the support of these for all the new CloudFront upstream security policies added in this change?

Also, Since s2n_signature_preferences_20201021 is used by other policies, I think its better to create a new signature preferences list by excluding signature schemes containing SHA1 & SHA224 from s2n_signature_preferences_20201021.

for CloudFront-Upstream-TLS-1-3-2025 yes, but probably not all for now

From a security perspective, I agree that SHA1 should be actively discouraged, deprecated, and removed. I have fewer concerns with SHA2.

One goal of this change is to preserve CloudFront's compatibility with outbound connections. If CloudFront is OK with dropping support for SHA1 in signature preferences, I'm more than happy to create/use a new signature preference list for all or some of these policies.

cc @zz85

@gokul-sai-doppalapudi let's follow up once after this gets merged

Did you intend to prefer aes 256 over aes 128? Just checking since the TLS 1.3 preference is inverted.

Hm, not particularly, but this is how CloudFront had set preferences before, so I'm inclined to leave this as-is for when TLS ≤1.2 is negotiated.

To confirm, did previous Cloudfront policies also prefer aes128 over aes256 for TLS1.3? Like existing policies have both orderings?

This PR adds CloudFront's first "upstream" (i.e. outbound PoP => Origin connections) TLSv1.3-enabled policies. It looks like their existing server-side policies (i.e. inbound client => PoP connections) favor AES 128 over 256 for TLSv1.3.

I might have misunderstood your question Lindsay; my above answer is incomplete. CF's server-side policies appear to favor AES 128 over 256 for TLS ≤1.2 as well as TLS 1.3.

However, CF's upstream (i.e. client-side) policies seem to favor AES 256 over 128 for TLS ≤1.2. Should we follow that latter pattern for upstream TLS v1.3 and prefer AES 256 over 128? I'm not sure, but I suppose it's slightly more consistent than preferring 128 here. It's easy to prefer 256.

Thoughts @zz85?

Talked with @zz85 offline, and he's OK with reordering the ≤1.2 ciphersuite preferences to prefer AES 128 over 256 for performance + consistency with the TLSv1.3 ciphers. Done in 0455414.

Also worth pointing out: given both an EC and RSA cert, this policy will choose the RSA cert. If there are any plans to actually support EC certs, the ECDSA ones should probably be at the top. Putting ECDSA second was a mistake we made on a bunch of early policies.

I did this to mirror prior CF Upstream policies. I agree that we should take this opportunity to prefer ECDSA over RSA (PKCS1 for security + performance reasons, PSS for performance reasons).

done in 71a7bce.

Did you do it only to the PQ policies intentionally, or by accident?

To answer your question directly: by accident.

I'd previously relied on older signature preferences for non-PQ policies (no ML-DSA), so only updated the new signature preference list. I've created a new set of signature preferences w/o ML-DSA and prioritizing ECDSA over RSA PSS signatures (performance win there, in cases where the server wouldn't select ECDSA anyway).

A bit of an aside -- it's not totally clear to me that TLS 1.3's spec requires that the server honors the client's ordered preferences (although it does seem implied).

  Each SignatureScheme value lists a single signature algorithm that
   the client is willing to verify.  The values are indicated in
   descending order of preference.

If that ordering were required or reasonably expected to be honored by the server, I'd expect an RFC 2119 "MUST" or "SHOULD". Perhaps older TLS versions' RFCs were worded differently, I haven't read them as closely...

Anyway, easy to adjust here.