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
