Hiya, I'm wondering if a thing I did when setting up a web server with ESNI might be generally useful for some, but not all, implementers.
My web server doesn't have an API it can use to update ESNIKeys in the DNS. Many implementations/deployments may have such an API but in my case, the zone file that includes the ESNIKeys RR is on another machine and the web server doesn't have write access to that. I do control both machines as it happens, but I still don't want to give general write-access to the web server. So what I did was create a .well-known URI on the web server that allows our "zone factory" to poll for changes to ESNIKeys RRs. In my case I have the web server generate new ESNIKeys each hour and publish those at .well-known URIs; the "zone factory" polls for those (also hourly) and when it sees new values, it checks that those work, and if they do it updates the zone file and re-publishes (DNSSEC signing, sending to hidden master etc.) There are some more details below that could easily change if we wanted to standardare this. Anyway it all seems to work ok and could be useful for others in a similar situation, or for web server implementers as a generic way to make ESNIKeys available, so I'm wondering if this'd be a useful PR for the ESNI I-D, or if a separate I-D would be useful, or maybe not enough people would need to do this to bother? Cheers, S. Details: - Web server generates new ESNIKeys hourly at N past the hour via a cronjob - ESNIKeys are "current" for an hour, and published with a TTL of 1800 for no particularly good reason - Old ESNIKeys are still usable for 3 hours, again for no particular reason (just 2 should do:-) - Web server has a set of "hidden" sites ($HIDDEN) and a "cover" site ($COVER) - The cronjob creates creates a JSON file for each hidden site at https://$COVER/.well-known/esni/$HIDDEN.json - Each JSON file contains an array with the ESNIKeys RR values for that particular $HIDDEN as shown below: [ { "ESNIKeys.version": 0xff01, "desired-ttl": 1800, "ESNIKeys": "/wH5QHc...=" }, { "ESNIKeys.version": 0xff02, "desired-ttl": 1800, "ESNIKeys": "FF02897...OA" } ] - The specifics of the JSON structure are just what was handy for me, I'm sure it could be better, and would change as we go if we standardise this - The values above with ellipses are the RR values we want to eventually see in the DNS - On the zone factory, a cronjob runs at N+3 past the hour, it knows all the names involved and checks to see if the content at those well-known URIs has changed or not - If the content has changed the cron job attempts to use the ESNIKeys and for each $HIDDEN where that works, it updates the zone file and re-publishes - Possibly interesting unintended consequence: after a TLS client had first gotten ESNIKeys from the DNS for $HIDDEN with the draft-03 ESNIKeys structure containing the public_name field, the TLS client would know both $COVER and $HIDDEN and so could later probe for this .well-known as an alternative to doing so via DoT/DoH. Probably not something a web browser might do, but could be fun for other applications maybe
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
