Closed cjpatton closed 6 months ago
Thinking about this more, I think (2.) is the safer choice and is worth the extra bit of deployment complexity. However, we'll need to say what we mean by "domain name". If we follow draft-ietf-tls-esni, we could just say that it's a "DNS name".
(See https://mailarchive.ietf.org/arch/msg/ntp/l9TQUJT6Tq46OSs8xObxS2FWlcw/ for the initial thread on this topic.)
There are situations in which it is desirable for a single Roughtime server to support multiple root keys simultaneously. For example, the operator may wish to rotate the root key but still support the old one for a time while it waits for clients to update their server configuration.
In order to support two root keys simultaneously, we need a way for the client to signal which root key it expects the server to use. Today there are just two options:
Open up an additional port and use the new key for requests coming on that port. This is expensive from an operational standpoint, as it increases the attack surface.
Allocate a new address for the new key. This is also expensive from an operational standpoint, for the same reason. In addition, it may be a financial burden depending on the operator.
Another option is to modify the protocol so that the client signals explicitly to the server which key it expects to verify the response with.
So far there a couple viable objections.
Define a new tag whose value is the hash of the root public key.
(Suggested by @wbl): Define a new tag that encodes (the hash of) the server's domain name. The server uses the domain name to select which root key.
Both seem to work. I think I'd prefer (1.) because it requires one less deployment step.