Consider SVCB-Used header

[enygren]

If decoupling from Alt-Svc, having an alternative to Alt-Used would be valuable. This should take lessons from challenges with Alt-Used adoption and should minimize the privacy impact.
Some options include:

1. Send SvcDomainName
2. Send SvcFieldPriority
3. Send an (8? 16?) bit value specified in a new parameter
4. Send a variable number of bits from a value specified in a new parameter. (ie, client can zero-out as many MSB as it would like)

I'm leaning towards (3) above as this bounds the amount of additional entropy to be significantly less than what could be done already by using an alternate port number or IP(v4/v6) address but still allows some level of signalling without requiring servers to have to go through the complexity of needing to use distinct ports/IPs (or ESNI key IDs), all of which are possible but which leak more to passive adversaries.

[davidben]

Why does the server need this information when it already knows the IP the client connected to?

[enygren]

It would be preferable to not have to burn IPv4 for this, plus this channel would only ever be sent encrypted in HTTPS requests whereas other options (different IPs, information in echconfig such as the public SNI or keyid) are all much worse in-terms of leaking information to passive network observers.

Is there a version of this that browsers/clients would be willing to implement? (ie, 1 bit? 4 bits? 8 bits? the SvcDomainName? an arbitrary string to avoid a privacy-theatre perspective?)

[enygren]

Proposed to defer this to a future draft (and perhaps as part of an alt-svc-bis).