Re: [quicwg/base-drafts] Resume HTTP/2 TLS from QUIC ? (#941)

[David Benjamin <[e-mail]>]

QUIC tickets need to include addition source-address information, right? That's not going to exist in TLS a priori. A TLS stack could put it in for you, but that's enough extra work that you probably shouldn't waste single-use tickets on that without an advertisement.

And then you've got the QUIC transport parameters that both sides need to recover for 0-RTT, but TLS over TCP is not going to negotiate that stuff. Though in https://github.com/quicwg/base-drafts/blob/master/draft-ietf-quic-transport.md#values-of-transport-parameters-for-0-rtt-zerortt-parameters, it looks like you all added an extension for the server to supply it independent of what the connection negotiated?

That would suggest the advertisement mechanism can just be the presence of quic_transport_parameters extension on TCP/TLS1.3 tickets. The server can send unsolicited NewSessionTicket extensions in TLS 1.3, so it can just advertise that on its own. Sending that over TCP implies the server has additionally put in whatever source-address information it wants and the client can reasonably expect the ticket to be usable for QUIC.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/941#issuecomment-345420739