Refactor signature algorithm selection logic

[lrstewart]

Problem:

We addressed this security advisory with a fairly hacky fix. Our signature algorithms logic is also one of the first sections of the code touched during our TLS1.3 changes, and is pretty difficult to read and maintain.

Solution:

We should revisit signature algorithm negotiation and do some cleanup, particularly around our default logic.

To keep changes small, I've broken it down into the separate steps of negotiation: the client sends the supported sig algs, the server receives the supported sig algs, the server sends its chosen sig alg, and the client receives the chosen sig alg.

Tasks:

• Switch signature algorithms from copies to pointers Switch sig schemes from copies to references #4237
• Clean up sending supported sig alg Clean up sending supported sig algs #4254
• Clean up receiving chosen sig alg Clean up receiving peer sig alg #4259
• Clean up receiving supported sig algs: we currently copy all the sig algs into memory on the connection. This could be done without the copy by using a pointer to the list instead.
• Clean up choosing a sig alg from supported sig algs Clean up selecting a signature algorithm #4285

Once all tasks are complete, s2n_signature_algorithms.h should look like:

S2N_RESULT s2n_signature_algorithm_recv(struct s2n_connection *conn, struct s2n_stuffer *in);

S2N_RESULT s2n_signature_algorithms_supported_list_process(struct s2n_connection *conn,
        struct s2n_blob *peer_list);
S2N_RESULT s2n_signature_algorithms_supported_list_recv(struct s2n_connection *conn,
        struct s2n_stuffer *in);

S2N_RESULT s2n_signature_algorithms_supported_list_send(struct s2n_connection *conn,
        struct s2n_stuffer *out);

• Does this change what S2N sends over the wire? If yes, explain.
• Does this change any public APIs? If yes, explain.
• Which versions of TLS will this impact?

Requirements / Acceptance Criteria:

What must a solution address in order to solve the problem? How do we know the solution is complete?

• RFC links: Links to relevant RFC(s)
• Related Issues: Link any relevant issues
• Will the Usage Guide or other documentation need to be updated?
• Testing: How will this change be tested? Call out new integration tests, functional tests, or particularly interesting/important unit tests.
  • Will this change trigger SAW changes? Changes to the state machine, the s2n_handshake_io code that controls state transitions, the DRBG, or the corking/uncorking logic could trigger SAW failures.
  • Should this change be fuzz tested? Will it handle untrusted input? Create a separate issue to track the fuzzing work.

Out of scope:

Is there anything the solution will intentionally NOT address?

[maddeleine]

Remaining task: #4543