Subject: Saving a round-trip time in initial handshakes with retry

From: Erik Sy <[email-masked]>
Date: Fri, 22 Mar 2019 14:30:47 +0100

Hi folks,

I noticed that we can often save a round-trip time in initial handshakes
with retry if we allow sharing the source address validation across
different hostnames.

I suggest introducing a new transport parameter for this purpose. Below
is a detailed description and evaluation of this proposal:

https://svs.informatik.uni-hamburg.de/publications/2019/2019-03-22-Sy-preprint-Surfing-the-Web-quicker-than-QUIC-via-a-shared-Address-Validation.pdf

Best,

Erik

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 22 Mar 2019 18:32:32 +0100

Erik,

This is an interesting issue. I think there is value in being able to do
this, especially for CDN-like servers that serve multiple hostnames from
the same server IPs.

Can you open an issue for it?

Thanks!
- jana

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 23 Mar 2019 03:17:24 +0900

2019年3月23日(土) 2:33 Jana Iyengar <[email-masked]>:
>
> Erik,
>
> This is an interesting issue. I think there is value in being able to do this, especially for CDN-like servers that serve multiple hostnames from the same server IPs.

I share the same view.

While I am not sure if I agree with the assumption that most of the
server deployments would require address validation prior to TLS
handshakes, there's great value in sharing token between hostnames:
skipping slow start and sharing congestion controller.

Cross-server-name token allows a server to have a consolidated
congestion controller that covers multiple connections (serving
different server names). A token would carry an identifier of the
consolidated congestion controller. Then, when the server accepts a
new connection that contains an ID of an active consolidated
congestion controller, the server would associate the connection to
that controller once address validation succeeds.

Actually, I have been thinking about precisely that (unlinkability of
NEW_TOKEN tokens that I raised on the other thread is a premise of
that), and have a tentative description on how that can be done [1].

But anyways, in terms of specification, all need is a TP that allows
cross-server-name use of tokens. I will be enthusiastic to argue for
having such thing in QUIC.

[1] https://github.com/kazuho/draft-kazuho-quic-shared-cc/blob/gh-pages/draft-kazuho-quic-shared-cc.txt

> On Fri, Mar 22, 2019 at 2:31 PM Erik Sy <[email-masked]> wrote:
>>
>> Hi folks,
>>

-- 
Kazuho Oku

---

From: Ian Swett <[email-masked]>
Date: Fri, 22 Mar 2019 14:32:40 -0400

+1 that this is/would be useful.

In order to enable 0-RTT, the TLS session ticket would also have to be
shared across domains.  Is the thought that the transport param would
indicate that could be used in addition to the token, or do we need a
separate mechanism in TLS to indicate that?

On Fri, Mar 22, 2019 at 2:17 PM Kazuho Oku <[email-masked]> wrote:

> [1]
> https://github.com/kazuho/draft-kazuho-quic-shared-cc/blob/gh-pages/draft-kazuho-quic-shared-cc.txt
>
> >

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 23 Mar 2019 04:11:48 +0900

2019年3月23日(土) 3:32 Ian Swett <[email-masked]>:
> In order to enable 0-RTT, the TLS session ticket would also have to be shared across domains.

I'm doubtful if that's possible. Especially when different
certificates are being used for such domains.

In case of single certificate covering multiple domains, we would need
to create a TLS extension, but maybe an easier way would be to port
the ORIGIN frame to HTTP/3.

I'd assume that the entire TLS handshake would be tied to the server
name (including the session ticket that's tied to the server name),
while the token is tied to either the list of server names (in case of
Erik's proposal) or to the server's address (in case of mine).

> Is the thought that the transport param would indicate that could be used in addition to the token, or do we need a separate mechanism in TLS to indicate that?
>

-- 
Kazuho Oku

---

From: Ian Swett <[email-masked]>
Date: Fri, 22 Mar 2019 15:27:56 -0400

I was thinking of the case when a single certificate covered multiple
domains, particularly wildcard certs.

On Fri, Mar 22, 2019 at 3:12 PM Kazuho Oku <[email-masked]> wrote:

> shared across domains.
> > Is the thought that the transport param would indicate that could be
> used in addition to the token, or do we need a separate mechanism in TLS to
> indicate that?
> >
> >> > This is an interesting issue. I think there is value in being able to
> do this, especially for CDN-like servers that serve multiple hostnames from
> the same server IPs.
> >>
> >> I share the same view.
> >>

---

From: Erik Sy <[email-masked]>
Date: Fri, 22 Mar 2019 20:39:10 +0100

The TLS working group will discuss a draft on this during their meeting
on Monday.
Here you find the respective draft:
https://datatracker.ietf.org/doc/draft-sy-tls-resumption-group/

On 3/22/19 20:27, Ian Swett wrote:
> On Fri, Mar 22, 2019 at 3:12 PM Kazuho Oku <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     2019年3月23日(土) 3:32 Ian Swett <[email-masked]
>     <mailto:[email-masked]>>:
>     >
Please consider that it is a common practise on the web to do
load-balancing across several IP addresses.
I looked into this and found that about 40% of visited websites are
served from another IP address when revisited after 45 minutes.

>     > Is the thought that the transport param would indicate that
>     could be used in addition to the token, or do we need a separate
>     mechanism in TLS to indicate that?
>     >
>     > On Fri, Mar 22, 2019 at 2:17 PM Kazuho Oku <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >>
>     >> 2019年3月23日(土) 2:33 Jana Iyengar <[email-masked]
>     <mailto:[email-masked]>>:
>     >> >
>     >> > Erik,
>     >> >
>     >> > This is an interesting issue. I think there is value in being
>     able to do this, especially for CDN-like servers that serve
>     multiple hostnames from the same server IPs.
>     >>
>     >> I share the same view.
>     >>
>     >> > On Fri, Mar 22, 2019 at 2:31 PM Erik Sy
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >> >>
>     >> >> Hi folks,
>     >> >>

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 22 Mar 2019 21:11:21 +0100

Ian raises a good point. What does the token buy if you can't do 0RTT
across domains?

---

From: Dmitri Tikhonov <[email-masked]>
Date: Fri, 22 Mar 2019 16:21:21 -0400

> Ian raises a good point. What does the token buy if you can't do 0RTT

Avoiding a stateless retry.

  - Dmitri.

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 22 Mar 2019 21:23:58 +0100

Yeah but that's not the common case. That's typically only useful under DoS

---

From: Dmitri Tikhonov <[email-masked]>
Date: Fri, 22 Mar 2019 16:29:14 -0400

DoS happens.  I may be missing something: why is my answer not
satisfactory?