kernel support for TLS 1.3

[gallatin]

Summary

TLS 1.3 requires a few changes because 1.3 pretends to be 1.2 with a record type of application data. The "real" record type is then included at the end of the user-supplied plaintext data. This required added a field to the mbuf_ext_pgs struct to save the record type, and passing the real record type to the sw_encrypt() ktls backend functions.

The only SW backend that currently supports 1.3 is a version of ISA-L used at Netflix. When this patch lands, I will update the review for the ISA-L port to include 1.3 support. (https://reviews.freebsd.org/D21446)

Test Plan

This has been tested using the Intel ISA-L backend at Netflix, and I believe a NIC vendor with an unreleased NIC supporting NIC TLS has tested this patch as well.

[• hselasky]

sys/kern/uipc_ktls.c

429 ↗

(On Diff #62590)

TLS v1.3 uses an IV of 12 - bytes ? Should this be checked too?

sys/sys/mbuf.h

362 ↗

(On Diff #62590)

Maybe add a comment. This field must be first.

[gallatin]

Updated to address feedback from Hans:

• add comment that record_type must be first in the union
• added a constant for the 1.3 GCM iv len and checked it where we check it for 1.2

[jhb]

sys/kern/uipc_ktls.c

484 ↗

(On Diff #62591)

It's not the sequence number per se, just an explicit 8 byte nonce. I would maybe say:

* TLS 1.2 uses a 4 byte implicit IV with an explicit 8 byte nonce.
* TLS 1.3 uses a 12 byte implicit IV.

488 ↗

(On Diff #62591)

No space after sizeof.

[gallatin]

Applied suggested changes in what I'm about to commit.

[jhb]

Actually, we need to update the logic that populates the TLS header to stop writing the 8 byte nonce for GCM for 1.3 in ktls_seq? It probably doesn't hurt for it to stay, but it would be cleaner if we removed it. I've actually thought about reworking what we do anyway. The 8 byte nonce doesn't have to be the sequence number, it just has to be unique per record. OpenSSL picks a random 8 byte value and increments it. We could actually do the something similar and generate the TLS header always in ktls_frame(). We would generate an 8 byte random value that is saved in the TLS session when it is created and just increment it for each record that is framed. There's no requirement that the nonce's be monotonically increasing, etc. just unique per record. This would simplify ktls_seq() and would make the 1.3 vs 1.2 handling a bit clearer.

[gallatin]

In D21801#476448, @jhb wrote:

Actually, we need to update the logic that populates the TLS header to stop writing the 8 byte nonce for GCM for 1.3 in ktls_seq? It probably doesn't hurt for it to stay, but it would be cleaner if we removed it. I've actually thought about reworking what we do anyway. The 8 byte nonce doesn't have to be the sequence number, it just has to be unique per record. OpenSSL picks a random 8 byte value and increments it. We could actually do the something similar and generate the TLS header always in ktls_frame(). We would generate an 8 byte random value that is saved in the TLS session when it is created and just increment it for each record that is framed. There's no requirement that the nonce's be monotonically increasing, etc. just unique per record. This would simplify ktls_seq() and would make the 1.3 vs 1.2 handling a bit clearer.

The code can stay, all that matters is that the seq is passed to the backend. But yes, I like your idea of a random value.