> we're talking about a host that fronts for multiple different names, so I'm > finding it hard to imagine how finding a name usable for this purpose would > be challenging.
This does sound unusual. That said, if this sort of set-up is possible (which presumably it is), it seems unfortunate to make ECH impossible in that scenario. > On Apr 20, 2021, at 6:00 PM, Martin Thomson <m...@lowentropy.net> wrote: > > On Wed, Apr 21, 2021, at 10:33, Christopher Wood wrote: >> Taking a step back, it would be great if we could reach consensus on >> whether or not this is a use case we actually want to solve. > > The Web currently recognizes IP certificates. The specs, thanks RFC 6125, > largely missed this, but we're fixing that. ACME has RFC 8738 and the latest > HTTP(S) spec finally defines validation for an IP-based reference identity. > > All that said, IP certificates are naturally a feature with narrow > applicability. For something like ECH fallback, which should be rare, we > benefit more from reduced options and simplicity than we do by enabling niche > features. Adding a dependency on a rarely used feature, optional or not, > only increases the risk profile. And complexity. > > So I don't think we should support different anything other than a domain > name for ECH fallback. > > If someone could demonstrate that it would be an undue imposition to require > a client-facing server to use a domain name, then I would happily concede the > point. As it is, we're talking about a host that fronts for multiple > different names, so I'm finding it hard to imagine how finding a name usable > for this purpose would be challenging. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
