Re: Advertising WebSocket support in the HTTPS resource record

On Wed, Oct 20, 2021 at 4:37 AM Dragana Damjanovic <
dragana.damjano@gmail.com> wrote:

> On Tue, Oct 19, 2021 at 11:53 PM Ben Schwartz <bemasc@google.com> wrote:
>
...

> On the technical side, I wonder if you've looked at
>> https://datatracker.ietf.org/doc/html/draft-vvv-httpbis-alps?  That
>> proposal would provide the SETTINGS frame earlier in the handshake,
>> achieving the same goal of avoiding this delay.  Compared to delivery over
>> DNS, it has some important benefits.  For example, it reduces the amount of
>> information that needs to be synchronized between HTTP servers and their
>> DNS zones, and encompasses any future HTTP SETTINGS as well.
>>
>
> The draft will eliminate some of this delay, but the TLS handshake still
> needs to be completed. There can be situation where it is possible to use
> HTTP/3 and HTTP/2, the client could choose to try HTTP/3, fallback to
> HTTP/2 and than to HTTP/1.1 or skip one of the steps.
>

This is an interesting observation, but it seems like this only works if
the client can rely on HTTP/2-WebSocket endpoints to publish the
"extended-connect" flag.  For example, if there are
HTTP/2-WebSocket endpoints deployed today with HTTPS records, clients
implementing this specification would lose access to those endpoints (until
they update their HTTPS records).

This change also creates an HTTP/2->HTTP/1.1 downgrade attack.  A DNS
intermediary could delete this flag, in order to force clients to use
HTTP/1.1 instead of HTTP/2.  In general, HTTPS records are designed to
prevent this downgrade attack.  (I don't know if this raises security
concerns for WebSockets.)

Rather than optimize the performance of origins that use WebSockets, and
support HTTP/2 and HTTP/3, but only support WebSockets on HTTP/1.1, I would
prefer to encourage server deployment of WebSockets support on all HTTP
versions.  We could also consider documenting a parallel connection
strategy for clients, if it's important to avoid a fallback delay.