create rfc9151 security policy

[toidiu]

Description of changes:

Adds a new security policy with AES256, SHA384 and support for TLS1.3

Testing:

Verified that we can connect via tls1.3/tls1.2 and rsa/ecdsa

# ./build/bin/s2nd --cert tests/pems/ecdsa_p384_pkcs1_cert.pem --key tests/pems/ecdsa_p384_pkcs1_key.pem -c "rfc9151" 127.1.0.1 8888

# ./build/bin/s2nc -i -c "20210816" 127.1.0.1 8888
# CONNECTED:
# Handshake: NEGOTIATED|FULL_HANDSHAKE|TLS12_PERFECT_FORWARD_SECRECY|WITH_SESSION_TICKET
# Client hello version: 33
# Client protocol version: 33
# Server protocol version: 34
# Actual protocol version: 33
# Server name: 127.1.0.1
# Curve: secp384r1
# KEM: NONE
# KEM Group: NONE
# Cipher negotiated: ECDHE-ECDSA-AES256-GCM-SHA384
# Server signature negotiated: ECDSA+SHA384
# Early Data status: NOT REQUESTED
# s2n is ready

# ./build/bin/s2nc -i -c "rfc9151" 127.1.0.1 8888
# CONNECTED:
# Handshake: NEGOTIATED|FULL_HANDSHAKE|MIDDLEBOX_COMPAT
# Client hello version: 33
# Client protocol version: 34
# Server protocol version: 34
# Actual protocol version: 34
# Server name: 127.1.0.1
# Curve: secp384r1
# KEM: NONE
# KEM Group: NONE
# Cipher negotiated: TLS_AES_256_GCM_SHA384
# Server signature negotiated: ECDSA+SHA384
# Early Data status: NOT REQUESTED
# s2n is ready




#############
./build/bin/s2nd --cert tests/pems/rsa_2048_pkcs1_cert.pem --key tests/pems/rsa_2048_pkcs1_key.pem -c "rfc9151" 127.1.0.1 8888

# ./build/bin/s2nc -i -c "rfc9151" 127.1.0.1 8888
# CONNECTED:
# Handshake: NEGOTIATED|FULL_HANDSHAKE|MIDDLEBOX_COMPAT
# Client hello version: 33
# Client protocol version: 34
# Server protocol version: 34
# Actual protocol version: 34
# Server name: 127.1.0.1
# Curve: secp384r1
# KEM: NONE
# KEM Group: NONE
# Cipher negotiated: TLS_AES_256_GCM_SHA384
# Server signature negotiated: RSA-PSS-RSAE+SHA384
# Early Data status: NOT REQUESTED
# s2n is ready


# ./build/bin/s2nc -i -c "default" 127.1.0.1 8888
# CONNECTED:
# Handshake: NEGOTIATED|FULL_HANDSHAKE|TLS12_PERFECT_FORWARD_SECRECY|WITH_SESSION_TICKET
# Client hello version: 33
# Client protocol version: 33
# Server protocol version: 34
# Actual protocol version: 33
# Server name: 127.1.0.1
# Curve: secp384r1
# KEM: NONE
# KEM Group: NONE
# Cipher negotiated: ECDHE-RSA-AES256-GCM-SHA384
# Server signature negotiated: RSA+SHA384
# Early Data status: NOT REQUESTED
# s2n is ready

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[lrstewart]

Looks good now! I would also suggest adding a note about this policy to the documentation

[scottarc]

This looks like a good security policy, but SHA512 isn't included in CNSA (and therefore RFC 9151), so the name is misleading for the current implementation. We'll need to either remove SHA512 from this security policy or name it something different.

[toidiu]

This looks like a good security policy, but SHA512 isn't included in CNSA (and therefore RFC 9151), so the name is misleading for the current implementation. We'll need to either remove SHA512 from this security policy or name it something different.

Lets create a security policy for rfc9151 here. We can create a new one that includes sha512 if that is needed later. b7b81f1

[franklee26]

out of curiosity, is there a reason why we are not using a date version string eg something like 20220822?

[toidiu]

https://github.com/aws/s2n-tls/blob/main/docs/USAGE-GUIDE.md

Numbered versions are fixed and will never change.

we try to avoid numbered version where possible since the numbers dont really mean much and since policy cant ever change, it will become outdated at some point.

[camshaft]

I wouldn't say we avoid them; they're all over. Outside of default, I think all of them are date-versioned. However, in this case I actually think the RFC number is a pretty reasonable version since RFCs are unable to change after being published. So we still have immutability and it actually means something as opposed to some arbitrary date.