MikeBishop / dns-alt-svc

Draft for listing Alt-Svc records in the DNS
Other
71 stars 26 forks source link

Evaluate where else we need to mention SVCB-optional protocols #293

Closed enygren closed 2 years ago

enygren commented 3 years ago

There may be a few other places we need to mention the implications of SVCB-optional vs mandatory protocols. For example:

There may be others that jump out with a read for this in-mind.

bemasc commented 3 years ago
  • We should clarify that HTTPS is SVCB-optional by default (although that future specifications may build SVCB-required services on top of HTTPS)

I think this is already pretty clear (e.g. here).

  • We may wish to add this optional/mandatory status to the non-normative table on protocols

The current text speaks about this as a property of the client, not the protocol or mapping. While most HTTPS clients should be SVCB-optional, I think it's conceivable that in green-field contexts, SVCB-reliant behavior may be permissible.

  • We should cover the implications on Proxies. In-particular, for a SVCB-mandatory protocol a client MUST get a SVCB record prior to initiating a CONNECT (if only because this is needed to get the SvcDomainName), at least absent optimizations that may be defined in the future.

Do you think there's potential for confusion here? This seems pretty straightforward to me. The current text says "If these concerns apply, the client SHOULD disable SVCB resolution.", which seems unambiguous, even if the effect is different for SVCB-reliant and SVCB-optional clients.

enygren commented 3 years ago

I think #295 may be adequate to address this. There is no way to implement a SVCB-reliant client as the proxy text currently stands. (I suspect various forms of privacy proxies will want to use DoH or ODoH or similar lookups via a proxy to get SVCB records prior to making CONNECT requests.)