Subject: Re: [ntpwg] Comments on draft-ietf-ntp-using-nts-for-ntp-08

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Mon, 24 Apr 2017 03:38:47 +0000

Resending (as apparently the original didn't make it out...)

From: Scott Fluhrer (sfluhrer)
Sent: Friday, April 21, 2017 5:45 PM
To: [email-masked]'
Subject: Comments on draft-ietf-ntp-using-nts-for-ntp-08

Hello,

    I've just reviewed draft-ietf-ntp-using-nts-for-ntp-08, and I thought I might raise a few comments.  Now, for my background (to give context to my comments):

-          I know little about the subtleties of handling time to the precision that NTP does.

-          I do know cryptography

Also, I have not been active in this group (even as a lurker); I did go through the mail archives (and didn't see much discussion).  As there may be context that I'm missing, my comments may be totally off-base (or are just reraising issues that have already been discussed and dismissed).

The draft actually looks pretty good; I'll not list the things I basically agree with, but instead just mention the things that sound a bit off:

-          First off, you are using encryption to generate privacy for part of the messages, but not the main part (the NTP header).  That strikes me (from a security standpoint) as odd.  In your objectives, you said you wanted unlinkability, but you also state (second paragraph of 8.2) that there are existing issues that you don't address, and hope that the client will handle it.  It would make sense to me to have the protocol handle it, and not rely on the client getting it right.  Is there a reason you need the NTP header to be in the clear (e.g. some middleware box expects to see it, or you need the unprotected NTP format to be essentially the same as a protected one)?  As an outsider, it would appear to me that it would make more sense to encrypt everything other than the cookie; is there a specific reason not to?

-          Key generation; the draft has both the server and the client calling TLS to generating the keying data (RFC5705); then, the server puts the keys into each cookie.  From a security standpoint, this is fine; however it does make each cookie rather large.  With the standard encryption method (SIV), each key is 32 bytes; that means that the cookie must be at least 68 bytes long (and likely somewhat longer).  Now, this does have the advantage of being idiot proof (an incorrect implementation will not work, rather than use an insecure key).  However, to me, it would make more sense to have the server select the keys, and have them send them in the NTS-KE response.  While this gives the server the responsibility to select the keys securely, this also opens up options that allows the cookies to be much smaller; for example, the server could select a random 16 byte value, run that through a Key Derivation Function to generate the keys, and then encrypt that 16 byte value (along with a nonce and the encryption transform) to generate the cookies; if the server decided to do that, that might give a 24 or 28 byte cookie.  Now, I'm not suggesting that this alternative method be mandated; what I am saying is that allowing the server to select the keys will give the server the option (and, if it's happy with the 5705 method, it could do that as well).

-          On a related note, you have separate S2C and C2S keys; if you using the RFC5705 method, that means that both keys must be listed separately in the cookie.  Is there a specific reason not to use the same key to protect both directions?  The NTP header (which is integrity protected) lists whether this is a server-to-client or a client-to-server message, and so an attacker doesn't gain anything by taking one message and reflecting it back to the source (as that'll reject it as an unexpected mode); is there any other vulnerability you are worried about?  Again, this makes the cookies larger than necessary.  One complication with using the same keys in both directions: if you're negotiating GCM (or another AEAD algorithm that requires nonce uniqueness), you'd also need to make sure the client and the server use distinct nonces (e.g. the client use even nonces, the server use odd ones); perhaps that's a complication you'd prefer not to have to address.

-          AEAD transforms; you allow the negotiation of any AEAD transform from the IANA registry; however there is a potential issue; as above, some transforms (such as GCM) disallows nonce reuse; this becomes an issue for the server (as it doesn't keep per client state).  This can be handled (e.g. by having a global counter it uses for all clients; that would allow someone to deduce how busy a server is; I don't believe that's secret); however I believe it does need to be spelled out (or alternatively simply disallow such transforms).

-          NTS cookie placeholders; you allow them in either the authenticated, or in the authenticated-and-encrypted section.  Here's why that sounds wrong: I believe that the model that the NT has is that it allows the server to process the request in place; it receives the NTP message, it modifies it, and then sends it back to the client.  That's the reason the NTP cookie placeholders are there; so that the server can replace them with the cookies (rather than allocating extra space).  However, the cookies need to be in the encrypted section; if the client places them in the authenticated-only section, that means that the server needs to reorder things.  It would seem to me that it'd make more sense to insist that the NTP cookie placeholders be mandated to be in the encrypted region (even though we really don't care about their privacy).

Thank you for taking the time to listen to someone new to NTP...
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg