Re: 0-RTT Design for HTTP/2

On Wed, Dec 16, 2020 at 8:46 PM Martin Thomson <mt@lowentropy.net> wrote:

> 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 <ianswett@google.com> 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.
>

I think Bence's work showed that the major servers can be fixed.  However,
upgrades still take time and I'm not sure if they've yet been completed.  I
suspect there's a long tail of servers out there that don't upgrade very
often(or ever :( ), and I feel a bit uncomfortable saying we're just going
to break them.

If I only had to send the SETTING client to server, I think that might be
deployable in the near future, though Chrome would have to run more
widespread tests.  I'm actually more concerned about the fact that the
server has to send the SETTING(which makes complete sense, given what
you're trying to accomplish).  It's impractical to wait for receipt of the
client SETTING before sending the server one, and the client ecosystem is
much slower to upgrade, unfortunately.

Given this, ALPS looks better from a deployability perspective.  To my
knowledge, there are no known issues deploying new TLS 1.3 extensions.
Given the lack of interest in a new h2 ALPN, I'm suggesting ALPS include a
GREASE recommendation, so if one deploys ALPS, it's also an indication it's
a fully compliant h2 implementation.