Hi Stephen, On Mon, Jul 8, 2019 at 5:39 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > On 08/07/2019 22:27, Erik Nygren wrote: > > > > In particular for the TLS WG, we'd be interested in hearing if this would > > solve enough of the ESNI-key-delivery-via-DNS needs for the HTTPS > use-case. > > I'm not clear if you envisage this entirely replacing the > new ESNI RR (as defined in ESNI draft-03), or if you envisage > both being defined, with this one (HTTPSSVC) being used for > the web and the ESNI RR for non-web uses of TLS, or maybe > something else? > > It'd seem like a bad plan two have multiple ways of doing > the same thing, but I guess there're trade-offs in various > directions here. > My thinking is that different protocols have different needs and requirements for key delivery via DNS. As such, separating out the ESNI key format from the DNS record for provisioning makes sense. EKR had the valid point that it would be valuable to have a basic way of doing ESNI key provisioning for protocols lacking complex requirements. This could end up as "protocols should specify bindings for how ESNI keys are delivered via DNS", with a HTTPSSVC RR for the HTTPS use-case, perhaps with other protocol bindings for other things with specific requirements, and with an ESNI RR (which might be able to be made simpler if some of the Web requirements can be abstracted) for generic use-cases. A downside is that this does add complexity for tools that operate entirely at the TLS layer such as openssl s_client that would be happier if only an ESNI record existed. However, the HTTPS use-case already has a bunch of other scenarios such as HTTP/3 that break/blur this abstraction layer such that it may be that this type of HTTPS connection management and DNS resolution needs to be done at the HTTP session layer regardless, with TLS libraries providing an interface to pass in ESNI keys. Encrypting authoritative DNS from recursives to authorities is in its early days, but it would not surprise me if similar requirements show up there and require a new DNS record type. (eg, an extensible NS record or an extensible record named by an NS record that includes information about protocols and ESNI keys and the like.) Best, Erik
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
