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

From: krasic <[email-masked]>
Date: Fri, 17 Nov 2017 00:43:33 +0000 (UTC)

Section 2 and 3 of the HTTP mapping describe the progression from HTTP QUIC advertisement to QUIC connection establishment.

For the very first time accessing an HTTP origin, typical progression is:
   o make initial request via HTTP/2
       - this involves TLS 1.3 handshake
       - client see response contains QUIC advertisement
   o subsequent request to same origin 
        - client tries QUIC, does QUIC TLS 1.3 handshake
        - so two RTTs before first QUIC request goes out.

Would it be possible for QUIC to instead of treating it as an initial TLS 1.3 handshake, but rather  treating the first QUIC request as TLS zero RTT, based on resuming the HTTP/2 TLS session (over QUIC)?   Saving 1 RTT for that case?

-- 
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

---

From: Subodh Iyengar <[email-masked]>
Date: Fri, 17 Nov 2017 03:00:23 +0000 (UTC)

Do you mean use the same session ticket from a TLS 1.3 connection over TCP for Quic 0-RTT? I don't think anything expressly prohibits x-protocol resumption right now, but we could do a security analysis on this.

-- 
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-345131573

---

From: Brian Trammell <[email-masked]>
Date: Fri, 17 Nov 2017 06:54:05 +0000 (UTC)

see also https://tools.ietf.org/html/draft-kuehlewind-taps-crypto-sep for some of the implication of the general space of cross-protocol resumption. Seems like it might be useful to allow for this capability in the design, or at least not gratuitously prohibit it.

-- 
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-345160945

---

From: krasic <[email-masked]>
Date: Fri, 17 Nov 2017 17:08:15 +0000 (UTC)

siyengar@: yes.

-- 
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-345303860

---

From: ianswett <[email-masked]>
Date: Sat, 18 Nov 2017 03:03:58 +0000 (UTC)

+1 to making this possible.  We could add a MAY resume with the session ticket from the TCP/TLS 1.3 connection if available?

It would be nice to know if the resumption was likely to work or if the TCP and QUIC TLS 1.3 resumption tokens were completely disjoint.  So possibly we either need to encourage applications to make resumption back and forth between QUIC and TCP work OR include some explicit indicator?

-- 
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-345413832

---

From: David Benjamin <[email-masked]>
Date: Sat, 18 Nov 2017 05:50:35 +0000 (UTC)

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

---

From: Subodh Iyengar <[email-masked]>
Date: Sat, 18 Nov 2017 21:06:53 +0000 (UTC)

@davidben ya i mentioned that in a previous comment that tls tickets would have to have the quic params in them :) A QUIC compatible server would be aware that clients would use TLS 1.3 + TCP connections to them and send them the same ticket. 

We should probably also have a MUST restriction that this sharing should only be limited to TLS 1.3 + TCP clients (and maybe TLS 1.2 with Extended master secret) otherwise we end up running into issues with the session ticket for TLS 1.2  being reusable for 1.3 creating the potential for triple handshake like attacks.

-- 
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-345471223

---

From: ekr <[email-masked]>
Date: Sat, 18 Nov 2017 21:45:25 +0000 (UTC)

On Sun, Nov 19, 2017 at 5:06 AM, Subodh Iyengar <[email-masked]>
wrote:

> @davidben <https://github.com/davidben> ya i mentioned that in a previous
> comment that tls tickets would have to have the quic params in them :) A
> QUIC compatible server would be aware that clients would use TLS 1.3 + TCP
> connections to them and send them the same ticket.
>
> We should probably also have a MUST restriction that this sharing should
> only be limited to TLS 1.3 + TCP clients (and maybe TLS 1.2 with Extended
> master secret) otherwise we end up running into issues with the session
> ticket for TLS 1.2 being reusable for 1.3 creating the potential for triple
> handshake like attacks.
>

I think we should just say TLS 1.3. I don't even know how to reason about
TLS 1.2 -> TLS 1.3 resumption, but I know it has non-awesome security
properties b/c of the key ladder.

> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/941#issuecomment-345471223>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABD1odv-ATn0vpkiVpTAnqxx0bEigpNiks5s30brgaJpZM4QhXjN>
> .
>

-- 
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-345473631

---

From: ianswett <[email-masked]>
Date: Sun, 19 Nov 2017 12:45:47 +0000 (UTC)

Agreed, TLS 1.3 only.

-- 
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-345513844