Re: issue 381: Discovery of the support of the HTTP2 protocol: DNS-based Upgrade

On 20 February 2014 08:26, Eliot Lear <lear@cisco.com> wrote:
>
> On 2/20/14, 10:23 AM, Mark Nottingham wrote:
>> On 18 Feb 2014, at 8:52 pm, Eliot Lear <lear@cisco.com> wrote:
>>
>>> Replying to myself, I'd like to make one point clear:
>>>
>>> It is ABSOLUTELY okay to use SRV so long as we accept that in some
>>> circumstances there will be some performance degradation, and that we
>>> will need to sort versioning beyond h2.  That latter issue implies some
>>> IN BAND upgrade mechanism for h2->hN.  In the case of TLS, we might
>>> simply handle this with ALPN, but someone from the TLS side should think
>>> about this in the context of a fast restart.
>> This is what’s concerned me in the past. We’ve made a lot of decisions based upon the assumption that introducing h3…hn (as well as other protocol identifiers) won’t require adding more round trips.
>>
>> Now, with ALPN, that may be OK, but it doesn’t help for non-TLS deployments, such as they are.
>
> Well, the round trip is hidden in a TLS capabilities exchange and I
> really would like to hear how it plays in the context of fast restart.


I don't know what you mean by "fast restart" here, but looking at some
of the proposed TLS 1.3 cases for fast handshakes, and session
resumption, you end up in a state where the choice from the last
session is maintained by default.  A client can of course opt to use
the longer handshake form in an attempt to move to another selection;
similarly the server can reject the resumption/fast handshake and fall
back to a complete negotiation.

There's a risk there that any choice becomes excessively "sticky" over
time, by which I mean that a choice to use "h2" could persist longer
than would otherwise be ideal.  I'm inclined to rely on operational
guidance (deploy "h3", reject resumptions or shortened handshakes from
prior to when the deployment occurred) rather than build additional
protocol machinery.  After all, that same guidance is going to be
necessary for cipher suite selection and other things as well.

Received on Thursday, 20 February 2014 17:21:46 UTC