Re: [TLS] publishing ESNIKeys under a .well-known URI...

[Christian Huitema <[e-mail]>]

On 6/26/2019 9:11 AM, Stephen Farrell wrote:
> Hiya,
>
> On 26/06/2019 16:58, Michael Richardson wrote:
>> Stephen Farrell <[e-mail]> 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