On 6/26/2019 9:11 AM, Stephen Farrell wrote: > Hiya, > > On 26/06/2019 16:58, Michael Richardson wrote: >> Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: >> > 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. >> >> When you say, "general write-access", did you mean that you didn't want to >> setup Dynamic DNS to be able to update the QNAMEs involved, because that >> usually permits the web server to delete A and AAAA records, as well as >> updating the ESNI ? >> >> Or did you mean "general write-access", meaning NFS or something like that? > Both really. NFS, or scripting up something with ssh, > would be easy but isn't desirable for local reasons. > DDNS seemed like more work, (but I didn't check it out > in detail tbh), wouldn't be otherwise useful in my > setup, and yes would need an authorisation model that > doesn't exist at the moment in our setup. > > Like I said, what I did won't be needed everywhere, but > maybe it's useful enough to document properly and/or > standardise, not sure.
I think Stephen's issue will be quite common, especially for small sites. I may be wrong, but it is quite common for small sites to use a DNS provider's management UI to update DNS data. This will create a de-facto limit on how often they can update the ESNIKeys RR, and thus the key itself. But then, we should ask how often these sites need to update the ESNI key. I understand one part of the threat model, that attackers can use an old compromised private key to break the privacy of clients using the old public key, hence the need to refresh the keys reasonably often. But there is a flip side of that. If the TTL of the ESNI record is small, clients will need frequent DNS interactions to refresh it, and their privacy could also be compromised during these operations. So, there are two threats: compromised keys on one side, observable DNS transactions on the other side. How do we navigate between these two threats? -- Christian Huitema
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
