On Wed, May 19, 2021 at 5:52 PM Martin Thomson <m...@lowentropy.net> wrote:
> On Thu, May 20, 2021, at 10:35, Brian Dickson wrote: > > I was under the impression that the extensibility is for the SVCB type, > > and not strictly needed for HTTPS. > > It is absolutely needed for HTTPS. > I'm not saying I doubt you, but maybe you could explain what you think would need to be added as an SvcParam, that would not be an ALPN, port, ech, ipv4hint or ipv6hint? Specifically that would need to be included as part of the one-lookup-DNS value that is needed prior to making the TLS connection? Is it one of those things that are "Well, we think we might need something", or is it "We already know something we need"? Is it something you know about and intend to deploy soon, like within the next couple of years? If not, how would SVCB NOT be reasonable to use instead of adding to the HTTPS record? (There's a reason I'm not suggesting making SVCB non-extensible, or touching any aspect of the SVCB thing itself.) Note that more ALPN values are supported, and how those are defined/used/etc are really not relevant to the structure (wire format) of the records (HTTPS or SVCB). HTTPS needs transport, port number, name, and maybe some hints for IP addresses, plus the new encrypted SNI. I'm at a loss for what else could even be used for establishing a TLS connection, in terms of anything/everything involved in TLS1.3? The transport is signaled via ALPN, alternate ports can be used, addresses are required, and name/SNI/ESNI/ECH are part of the TLS establishment. Everything else is in-band within TLS itself (e.g. certificates) or obtained from other sources (e.g. TLSA from DNS). Is there something I'm missing that would be needed as part of the TLS connection, from DNS ahead of time? Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
