Security implications of Alt-Svc fallback

[martinthomson]

@LPardue cites the following text:

Furthermore, if the connection to the alternative service fails or is unresponsive, the client MAY fall back to using the origin or another alternative service. Note, however, that this could be the basis of a downgrade attack, thus losing any enhanced security properties of the alternative service.

Then goes on to point out (links mine):

Alt-Svc fall back is described in Section 2.4 and mentions security properties, so I was expecting to see something about fall back in the security considerations. This might be implicitly covered by Section 9.3 but it could potentially be made more clear.

@LPardue proposed nothing more than ¯\_(ツ)_/¯ as the resolution to this issue. Maybe we can come up with something better.

[martinthomson]

My take on this is that the text is somewhat problematic.

Taking the quoted text, the implication is that an alternative service might be provided with the intent of improving security. This is not something we can guarantee through this system, so the text should not imply that. On the contrary, it should explicitly disavow any claim to improving security, except to the extent that an opportunistic upgrade system might provide benefits (there is the potential for better traffic analysis resistance in newer protocols for example, though we might caution that HTTP/3 implementations currently look to be quite poor in this regard).

Section 2.4 makes this vague statement regarding security properties:

[...] and the security properties of the alternative service protocol are desirable, as compared to the existing connection.

This is not the usual way that we approach these sorts of negotiations. We don't compare connections as comparisons across multiple facets of a protocol are difficult to make and unlikely to produce actionable results. Instead, clients establish a set of security expectations and seek to negotiate a connection that meets those expectations. Clients could (and some do) set different expectations for alternative services, but decisions related to that are best made before information from servers influence them. For instance, a client might decide that it will never use HTTP/1.1 for an alternative service on the basis that it offers no (performance/security) benefits that would justify the extra effort.

#1690 covers the ALPN aspect of this, which is the latter half of the quoted paragraph.