I'm not sure what I think about the general idea TBH but just on this bit...
On 08/07/2019 23:08, Erik Nygren wrote: > > 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. I don't think that's such a big deal for the library as that's unlikely to include the code to do DNS queries. Being able to parse a couple of different wrappers for ESNIKeys isn't that big a deal. And at least the code I've done for s_client assumes it gets the RR value on the command line (for now anyway) so that's also no biggie. But I figure s_client isn't that important as an application anwyay;-) Having different DNS RRTYPEs one might need to probe or otherwise know about would make like harder for real application code that does DNS though, and for servers who might end up having to publish the same things in different ways. So I hope we don't create that kind of problem. Cheers, S.
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
