Lines Matching +full:use +full:- +full:handshake

8 Part of the QUIC state comprises the TLS handshake layer. However, synchronising
11 At first glance, one could synchronise handshake layer public APIs by locking a
12 per-connection mutex for the duration of any public API call which we forward to
13 the handshake layer. Since we forward a very large number of APIs to the
14 handshake layer, this would require a very large number of code changes to add
15 the locking to every single public HL-related API call.
31 - **1. Application-controlled explicit locking.**
43   It would also only be required for applications which want to use thread
50 - **2. Handshake layer always belongs to the application thread.**
52   In this model, the handshake layer “belongs” to the application thread
55   - `SSL_tick()` (or another I/O function) called by the application fully
58   - The assist thread performs a reduced tick operation which does everything
60     future which would be processed by the handshake layer.
62   - This is rather hacky but should work adequately. When using TLS 1.3
63     as the handshake layer, the only thing we actually need to worry about
64     servicing after handshake completion is the New Session Ticket message,
66     post-handshake messages used by TLS 1.3 aren't relevant to QUIC TLS:
68     - Post-handshake authentication is not allowed;
70     - Key update uses a separate, QUIC-specific method;
72     - TLS alerts are signalled via `CONNECTION_CLOSE` frames rather than the TLS
74       handshake completion (which would in itself be highly unusual), we simply
78   generate alerts or New Session Ticket messages after handshake completion,
85 - **3. Handshake layer belongs to the assist thread after connection begins.**
87   In this model, the application may make handshake layer calls freely prior to
94   connection. We could selectively enable some important post-handshake HL calls
101   we don't implement for thread assisted post-handshake QUIC, we would