Subject: Re: [quicwg/base-drafts] Saving a round-trip time in the initial handshakes with retry (#2552)

From: Martin Thomson <[email-masked]>
Date: Mon, 01 Apr 2019 00:01:20 -0700

My recommendation: mark this quicv2.  This is best implemented as an extension.

-- 
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/2552#issuecomment-478459855

---

From: Martin Thomson <[email-masked]>
Date: Mon, 01 Apr 2019 02:25:12 -0700

To expand on this a little.  I don't anticipate Retry being used very often.  QUIC provides Retry for extraordinary circumstances only.  Most servers will be able to complete the handshake without an explicit address validation step, relying on the implicit address validation provided by the sending and receipt of encrypted packets.  Retry might be used by servers with absurd certificates (maybe), by servers deploying massive PQ key exchange messages (maybe in future), or when servers are under load and they want to validate clients before expending resources.

This therefore less useful than a cross-origin TLS session ticket.  It might have some utility, but I suspect that it won't be necessary in the general 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/2552#issuecomment-478504239

---

From: MikkelFJ <[email-masked]>
Date: Mon, 01 Apr 2019 02:36:17 -0700

Isn't retry useful as a replacement to anyCast IP? I'd expect it to be increasingly common to deploy multiple regional clusters and it is not always practical to rely on a global anyIP load balancer - for example one might only support layer 7 traffic.

-- 
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/2552#issuecomment-478508176

---

From: Erik Sy <[email-masked]>
Date: Mon, 01 Apr 2019 05:00:32 -0700

A QUIC server that is not validating the source address of a client before proceeding with the connection establishment is a vulnerable system. Adversaries can easily launch attacks to exhaust the server's resources or exploit the server within reflection attacks against other endpoints. 
QUIC deploys mitigations such as limiting the response size. However, it is unclear at this point in time whether these defenses are sufficient.
As the Internet is a hostile place, we will observe that QUIC servers have to make use of stateless retries to validate the client’s source address. However, a trustworthy prediction of the number of connection establishments using a stateless retry seems currently not to be feasible.

The proposal allows compensating for the costs of preventing IP address spoofing across connections to several hostnames. Thus, it provides an improved security versus performance tradeoff compared to the status quo.

As the probability of a stateless retry seems to be higher for resumed TLS sessions, session resumption across SNI values provides another incentive to implement this proposal.

If we agree, that this presents a useful feature for QUIC’s connection establishment, then I prefer to mark it quicv1. The reason is, that it allows saving round-trip during the establishment of initial connections even when the same security requirements are applied as TLS over TCP does. Thus, it provides an additional incentive to deploy QUIC instead of using TLS over TCP.

-- 
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/2552#issuecomment-478550385

---

From: ianswett <[email-masked]>
Date: Tue, 02 Apr 2019 08:57:17 -0700

I agree with @martinthomson on this.  Without cross-origin TLS tickets, I don't think this is that valuable, and I don't see any need for v1 to dependent upon this, even if it's useful as an extension in v1.

-- 
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/2552#issuecomment-479065802

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 03 Apr 2019 12:54:40 -0700

I agree that this doesn't need to be on the  v1 critical path. That said, as @kazuho mentioned on the list, there's a related issue where a shared token on future connections to the same IP (but different server name) allows a server to bootstrap this connection using path properties that might be stashed in the token.

-- 
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/2552#issuecomment-479635231