Re: 0-RTT Design for HTTP/2

[Martin Thomson <[e-mail]>]

Mega-reply...

On Wed, Dec 16, 2020, at 21:33, Cory Benfield wrote:
> I am somewhat nervous here about how many servers will implement this.
> 
> Typical OSS server implementations have a somewhat arms-length
> relationship with their TLS stack. This tends to mean they don't
> actually know exactly when new session ticket messages were sent.
> While this is not a hard limitation (OpenSSL has the requisite
> functions) it's the kind of barrier to entry that could be quite
> awkward. This may also lead to limitations in how many HTTP/2 stacks
> go through the effort of implementing the extension.

So there is a lot of text here, but it is very easy to implement the server side of this if you don't change settings often.  Just set the value to 1 in the preface and remember those values.  Confirm that the TLS stack isn't spitting out session tickets except during the handshake (which is the only place they appear in TLS 1.2) and you are good.

There is a risk with TLS 1.3 that sending session tickets might take some time.  This depends on things like ticket requests with large numbers and how the stack schedules those relative to application data.  Basically, you need to ensure that you delay any changes to settings (changes you might not be able to synchronize with ticket issuance properly) until you are reasonable sure that tickets aren't being sent.

BTW, I like how NSS manages this, and not just because it's my code :).  NSS makes it the responsibility of the application to send extra tickets [1].  It might send one, but that is sent ahead of any responses you might generate.

Short story: I believe that it is easy to implement this with TLS 1.2; TLS 1.3 might take a little care.

[1] https://searchfox.org/nss/rev/51b18ad6c1e627ada90028df9062f7200f7cec94/lib/ssl/sslexp.h#245-264 (I really need to promote that one from experimental some time.)

On Wed, Dec 16, 2020, at 23:34, David Schinazi wrote:
> If there's energy in the community to improve HTTP/2 SETTINGS,
> I would personally prefer to direct that energy at also solving the
> "not having SETTINGS when sending the first request" problem.
> Once potential solution is ALPS [1]. Would it make sense to join
> these two efforts to ensure we fix SETTINGS for good?

I'm glad you raise ALPS David.  My view is that we can't really deploy ALPS in an incremental fashion for HTTP/2.  Part of what I'm looking for here is an incremental solution.

I do see the possibility of just trying ALPS when it is available.  However, I think that is enough of a different protocol that it requires a new ALPN to go along with it.

I've watched the discussion regarding the possibility of defining a new ALPN for HTTP/2 and my sense is that there isn't overwhelming support for the idea.  If we had that support, then it might be good to try to fix ALPS into the design of a new protocol, but that isn't how things appear to be going.

On Wed, Dec 16, 2020 at 4:31 AM Ian Swett <[e-mail]> wrote:
> Before we get to that, one Q on deployability: Does the working group think enough of the ecosystem can handle this new EARLY_DATA_SETTINGS setting?  If no one sends it, even if they support the functionality, it sort of defeats the purpose.

Good question and worth answering before considering this.  I think that the work Bence has done here shows that there is some hope of success on this front.  That goes back to the "new ALPN" question.  I'm reading a pretty strong desire to fix "h2" rather than give up on it, but I'm sure that everyone is open to conceding that the bustage cost is too high if that is where things stand.