Re: [Ntp] Benjamin Kaduk's Discuss on draft-ietf-ntp-using-nts-for-ntp-23: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Kurt!

On Mon, Mar 23, 2020 at 12:39:30AM +0100, Kurt Roeckx wrote:
> On Sun, Mar 22, 2020 at 05:47:16PM +0100, Ragnar Sundblad wrote:
> > > > > Section 9
> > > > > 
> > > > > We should probably have some discussion of the consequences of
> > > > > compromise of the server's cookie-encryption key.  Possibly also for
> > > > > when the key associated with a cookie is compromised from a client,
> > > > > though if cookies are single-use the scope may be quite limited.  (That
> > > > > is, since we are using the shared symmetric key for authentication by
> > > > > virtue of "I didn't send it so it must be from the other party that has
> > > > > the key".)
> > > > 
> > > > NTP and NTS-KE server operators are expected to remove compromised keys as soon
> > > > as the compromise is discovered. This would cause the NTP servers to respond
> > > > with NTS NAK, thus forcing key renegotiation. We are aware that this does
> > > > not protect against MITM attacks where the attacker has access to a
> > > > compromised cookie encryption key.
> > > 
> > > I did not doubt that you are aware of this; the question is whether all
> > > future readers of this document will similarly be aware.
> > 
> > Right, we added a new section ("Key Compromise") to describe the
> > problem and how it should be handled.
> 
> I think this is at least a step in the right direction. I think
> there are 2 keys:
> - The key for the X.509 certificate
> - The key that is negiotatiated during NTS-KE
> 
> Both of them can be compromised, and I think the new section only
> talks about the 2nd key, and talks about how to deal with that
> event, but I think it's also important to deal with the first key.

I think it's talking about a third key, the one internal to the NTS
server(s) that is used to self-encrypt the cookies that are handed out to
clients.  Compromising this key affects all clients, so is particularly
noteworthy.  Compromising the X.509 key does the same, though is in theory
covered by the security considerations of other documents (e.g., RFC 5280).
Compromising the result of the NTS-KE negotiation affects only the one
client in question, and thus has something of a narrower scope.  I wouldn't
turn down text that discussed the consequences of its compromise, though!

-Ben