Unless I am missing something, the text below seems to say otherwise.
Note: Although the resumption master secret depends on the client's second flight, a server which does not request client authentication MAY compute the remainder of the transcript independently and then send a NewSessionTicket immediately upon sending its Finished rather than waiting for the client Finished. This might be appropriate in cases where the client is expected to open multiple TLS connections in parallel and would benefit from the reduced overhead of a resumption handshake, for example. On Thu, Nov 14, 2019 at 11:52 AM Christopher Wood <c...@heapingbits.net> wrote: > On Thu, Nov 14, 2019, at 8:48 AM, Christopher Wood wrote: > > On Thu, Nov 14, 2019, at 8:43 AM, Daniel Migault wrote: > > > If tickets are sent right after the server Finished, before the the > > > client Finished, these are only triggered by the clientHello - at > least > > > this is my understanding. > > > > Yes, that's correct. I thought your comment was about post-handshake > > tickets (after confirmation from the client). Adding a note about this > > pre-handshake completion is fine with me. > > Scratch that! I forgot we limited this extension to TLS 1.3, which > prohibits sending NSTs until the client finished is received ( > https://tools.ietf.org/html/rfc8446#section-4.6.1). > > Best, > Chris > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
