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

From: Daniel Franke <[email-masked]>
Date: Wed, 3 May 2017 12:40:03 -0400

Sorry for the delay in reply. Responses inline.

On 4/23/17, Scott Fluhrer (sfluhrer) <[email-masked]> wrote:
> -          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?

If I were designing a time protocol from scratch, then yes, I'd just
encrypt and authenticate everything. But NTS is supposed to extend
NTP, not replace it, which means we need to operate under the existing
syntactic constraints which require the header to be in the clear. The
privacy problems stemming from the NTP header fields are solvable and
we have a draft for a separate RFC to address those issues.

>
> -          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).

I'm not persuaded that letting the server choose the keys is safe
without seeing some formal analysis to that effect. It's clearly okay
in a simple two-party setting, but what happens in complex hierarchies
where some principals are acting as both clients and servers? It's not
obvious to me that this doesn't lead to any surprising attacks,
perhaps ones thematically similar to
https://mitls.org/pages/attacks/3SHAKE.

Also, I don't think using RFC5705 necessarily precludes the sort of
optimization you're suggesting. Instead of putting the C2S and S2C
keys into the cookie, you could put the master secret in there and
then re-run the RFC5705 PRF each time a request comes in. I hesitate
to make this a recommendation, though.

> -          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.

Yes, that's precisely why I decided not to go that route.

> -          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).

The reason I ended up at SIV as the MTI algorithm is that I don't
think there's *any* sufficiently reliable method of avoiding nonce
reuse in some of the settings where NTP servers operate; see
https://lists.ntp.org/pipermail/ntpwg/2016-August/003038.html. And
anyway, I'm *certainly* not suggesting that it's a good idea to
implement every algorithm in the IANA registry and be willing to
negotiate any of them. Just like in the case of TLS ciphersuite
negotiation, it's up to implementers to keep tabs on which algorithms
are considered safe and to support only those. The first version of my
own implementation will probably support only AES_SIV_CMAC_256, and
later, for greater efficiency, I'll add AES-GCM-SIV once the CFRG
finalizes the spec.

> -          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).

It was never my intent to support the sort of in-place transformations
you're describing; the placeholders are there simply to ensure that
the request and response are the same *length*, to prevent DDoS
amplification and loss of timing precision due to asymmetry. I suspect
that requiring the placeholders to be encrypted would actually hurt
performance, not help it. On the one hand you avoid needing an extra
buffer and maybe that avoids some L1 cache misses, but now you have to
do a few extra AES operations.
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Wed, 3 May 2017 17:51:51 +0000

> -----Original Message-----
> From: Daniel Franke [mailto:[email-masked]]
> Sent: Wednesday, May 03, 2017 12:40 PM
> To: Scott Fluhrer (sfluhrer)
> Cc: [email-masked]
> Subject: Re: [ntpwg] Comments on draft-ietf-ntp-using-nts-for-ntp-08
> 
> > 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).
> 
> I'm not persuaded that letting the server choose the keys is safe without
> seeing some formal analysis to that effect. It's clearly okay in a simple two-
> party setting, but what happens in complex hierarchies where some
> principals are acting as both clients and servers? It's not obvious to me that
> this doesn't lead to any surprising attacks, perhaps ones thematically similar
> to https://mitls.org/pages/attacks/3SHAKE.
> 
> optimization you're suggesting. Instead of putting the C2S and S2C keys into
> the cookie, you could put the master secret in there and then re-run the
> RFC5705 PRF each time a request comes in. I hesitate to make this a
> recommendation, though.

I don’t believe that works; RFC5705 assumes that you have the TLS master secret available; obviously, the server won't have that master secret available after initial negotiation.

> > 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).
> 
> The reason I ended up at SIV as the MTI algorithm is that I don't think there's
> *any* sufficiently reliable method of avoiding nonce reuse in some of the
> settings where NTP servers operate; see
> anyway, I'm *certainly* not suggesting that it's a good idea to implement
> every algorithm in the IANA registry and be willing to negotiate any of them.
> Just like in the case of TLS ciphersuite negotiation, it's up to implementers to
> keep tabs on which algorithms are considered safe and to support only
> those. The first version of my own implementation will probably support only
> AES_SIV_CMAC_256, and later, for greater efficiency, I'll add AES-GCM-SIV
> once the CFRG finalizes the spec.

While I suspect that server nonces *could* by made to never repeat, I would agree that it's nontrivial (and people are likely to get it wrong).  Might I then suggest that you forbid AES-GMAC (and Poly1305, which has similar, if not as severe, issues)?

> > 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).
> 
> It was never my intent to support the sort of in-place transformations you're
> describing; the placeholders are there simply to ensure that the request and
> response are the same *length*, to prevent DDoS amplification and loss of
> timing precision due to asymmetry. I suspect that requiring the placeholders
> to be encrypted would actually hurt performance, not help it. On the one
> hand you avoid needing an extra buffer and maybe that avoids some L1
> cache misses, but now you have to do a few extra AES operations.

If that's your concern, well, if I'm not mistaken, the lengths may be different, because of the different amounts of encryption padding.  In particular, if the client doesn't include any extensions within the encrypted extension (I don't see any extensions which must be encrypted; the place-holder cookies are the only example you give which may be), then it is still required to have 24 octets of padding; coming back, the server moves the placeholders into the encrypted extension (and redubs them as cookies); you need a minimal amount of padding there.

Would a (worse case) 23 octet delta in the sizes be enough to be concerned about?  (To be honest, I don't know)

Oh, and you probably should explicitly require that cookies from the same server (for the same transform/keys) always be the same length.  It'd be rather odd if an implementation didn't do that; however it looks like you do assume it (at least in terms of balancing client/server message sizes).

---

From: Daniel Franke <[email-masked]>
Date: Wed, 3 May 2017 14:17:56 -0400

On 5/3/17, Scott Fluhrer (sfluhrer) <[email-masked]> wrote:
> I don’t believe that works; RFC5705 assumes that you have the TLS master
> secret available; obviously, the server won't have that master secret
> available after initial negotiation.

Which is why I said the master secret needs to go into the cookie if
you take that approach.

> While I suspect that server nonces *could* by made to never repeat, I would
> agree that it's nontrivial (and people are likely to get it wrong).  Might I
> then suggest that you forbid AES-GMAC (and Poly1305, which has similar, if
> not as severe, issues)?

I don't think it's useful to make an explicit blacklist of algorithms
given that the IANA registry is subject to expansion and therefore the
blacklist always risks being incomplete. But I should probably include
more discussion in the security considerations as to why resistance to
nonce reuse should be an important factor in deciding what algorithms
to support.

> If that's your concern, well, if I'm not mistaken, the lengths may be
> different, because of the different amounts of encryption padding.  In
> particular, if the client doesn't include any extensions within the
> encrypted extension (I don't see any extensions which must be encrypted; the
> place-holder cookies are the only example you give which may be), then it is
> still required to have 24 octets of padding; coming back, the server moves
> the placeholders into the encrypted extension (and redubs them as cookies);
> you need a minimal amount of padding there.
>

23 octets would be borderline concerning, but I don't think it can
ever come close to that since the 24-octet minimum is already taken up
by the nonce and the authentication tag. If the sizes of those two
fields sum to a multiple of 4 (which they probably always will) then
the request and response size should come out exactly the same;
otherwise the difference shouldn't exceed 3 octets.

> Oh, and you probably should explicitly require that cookies from the same
> server (for the same transform/keys) always be the same length.  It'd be
> rather odd if an implementation didn't do that; however it looks like you do
> assume it (at least in terms of balancing client/server message sizes).

I think it's overreaching to make that a requirement. If implementers
are generating variably-sized cookies then they must have a reason,
and I don't want to presume that their reason is less important than
guaranteeing exact parity of request and response sizes. This parity
is desirable, but it's not as if being a few bytes off causes anything
catastrophic to happen.
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 3 May 2017 15:47:34 -0700

On 4/23/2017 8:38 PM, Scott Fluhrer (sfluhrer) wrote:
> 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?

Off the top of my head:

- the current time isn't sensitive information.

- encrypting the base packet adds significant overhead for both sides of
the association.  This becomes more significant in a WAN setting, where
the problems of the initial exchange add complexity and time, which
exacerbate DoS problems.

- quickly getting the initial time sync is often very important.  Packet
size is important.  Rate-limiting packet exchanges is a requirement.
Initial key exchange can blow all of this out of the water, and makes
for an obvious DoS vector as well.

- encryption is of dubious value in a LAN setting.

- It makes debugging harder.

So situations where "more encryption" is useful or desirable exist, but
this should be a *choice* and not a *requirement*.

> 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
> select the keys will give the server the option (and, if it’s happy with
> the 5705 method, it could do that as well).

Remember peer mode, and we need to at least be aware of one-way
broadcast.  The above means that the client has no choice but to
accept/believe the server.  Eventually, we want to allow for
bi-directional authentication and authorization.

> 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
> 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
> 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).

While the base packet has known areas in it, the EFs are not fixed.

The purpose of a MAC is to authenticate the previous contents of the packet.

The belief that an EF must be at least 24 bytes long is a mistake that
should have never been propagated.

> Thank you for taking the time to listen to someone new to NTP…

I'm glad to see your participation.

H
--

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 04 May 2017 08:17:20 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 04.05.2017 um 00:47 in Nachricht
<[email-masked]>:

[...]
> - encryption is of dubious value in a LAN setting.
[...]

I'd say "encryption may not be needed or wanted in some LAN environments"

Regards,
Ulrich