On Thu, Nov 14, 2019, at 8:57 AM, Daniel Migault wrote: > 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.
Oops again. I only read the first sentence and drew the wrong conclusion. At any time after the server has received the client Finished message, it MAY send a NewSessionTicket message. > > > 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
