C2S/S2C lifetime

[Gary E. Miller]

Yo Richard!

On Sat, 2 Feb 2019 20:50:15 -0600
Richard Laager via devel <devel at ntpsec.org> wrote:

> [I have re-ordered the quoted text to fit my response ordering.]
> 
> On 2/2/19 7:13 PM, Gary E. Miller via devel wrote:
> >> Hal's comments and the quote from Daniel are about whether it is
> >> necessary to require rotation of C2S/S2C, not K.  
> > 
> > Yes.  
> 
> This discussion was originally about why it is not necessary to rotate
> C2S/S2C. You have shifted it to a discussion about attacks on K.

Always the same in my mind.  Sorry if I was not clear until now.

> >> Clients can keep their own lifetime to enforce
> >> rotation of it (by re-running NTS-KE), but when Hal asked the
> >> working group, Daniel said that is not necessary:  
> >
> > Yes.  Using flawed assumptions.  Such as only one client using the
> > same key.  
> 
> That's not a flawed assumption in the context of attacks on C2S/S2C. A
> client following the spec has a separate C2S/S2C for every
> association, and it is specific to that client.

Except, those are flawed assumptions.

> In the context of
> attacks on C2S/S2C, if the client willingly shares C2S/S2C in
> plaintext with someone else (other than the server), the client has
> already compromised C2S/S2C by its own actions. There is nothing in
> the protocol which does this.

Yup.  The protocol allows this class of attack.

> Now, in the context of attacks against K, sure you can have multiple
> coordinating clients sharing a C2S/S2C as part of the effort to break
> K. I'll discuss that later.

Now you see my viewpoint.

> > Since their IS a recommended limit, it should be respected.  And
> > very conservatively.  
> 
> The limit is on how many messages should be encrypted by a single key.

Yup.  Except there is NO limit.

> For C2S/S2C, the limit is applicable to a normally functioning client
> (and server).

I'm not talking about normal.  I'm talking about enemy action.

> Even with the worst case assumptions of AES-GCM and minpoll 4, that
> limit is 2,176 years. C2S/S2C are re-keyed at least on client
> restart. I believe 2,176 years is "very conservative[]" relative to
> client ntpd restarts. Do you disagree?

If I agree to your assumptions, then I agree to your conclusion.

Except, I do not agree with your assumptions.  Nothing enforces
minpoll 4.  Nothing prevents cookie sharing.


> For K, the limit is applicable to the number of messages transmitted
> by a server ntpd, or a set of cooperating ntpds sharing K.

Yes, which is unlimited...

> If we assume the attacker can somehow capture all or substantially all
> of the traffic transmitted by that ntpd, it doesn't really matter
> whether this is attacker generated traffic or legitimate traffic.

We seem to be talking past each other.  I'm not talking about a
listener on the wire.  I'm talking about an active adversary.

> but I'll stipulate (for argument's sake at least) that
> attackers can generate lots of traffic that might go unnoticed (e.g.
> due to the volume of legitimate traffic, e.g. at NIST scale).

Good.

> The server chooses its algorithm for protecting K independent of the
> clients. It is not required to support AES-GCM, so it can gain a
> significant factor of protection (2^32 to 2^48) by using only AES-SIV
> as recommended by Daniel.

Good assuming no flaw is found in AES-SIV.  Remember BEAST?

> However, as above, maybe we want some crypto
> diversity, just in case a future problem is found with AES-SIV.

Or, because the Proposed RFC insists on it.

> So
> maybe we do allow AES-GCM too, and thus need to consider that case,
> so we're at 2^32 messages.

Or less, a lot less.  Remember BEAST?

> If we assume the recommended rotation of daily,

Wrong again.  It is not a rotation, it is a ratchet!

> So I conclude that using AES-GCM to protect K is a real problem at
> NIST scale, even if they don't share K across servers, with a daily
> rotation schedule (assuming a world where everyone implemented NTS).

Well, good.  Now extrapolate to other ciphers.

> Rotating more frequently is one possible solution. However, they
> almost certainly need to keep a client's cookie valid for at least
> 1024 seconds (17 hours), as that is a common polling window. So K
> needs to be valid at least that long (i.e. rotate K every 9 hours
> keeping one old K). Trying to support a maxpoll of 17 (36.4 hours) is
> really pushing the boundaries of an AES-GCM protected K at NIST load,
> even if K is per server, unless they deploy more servers (to get more
> Ks) than they used in 2016.

Or, just expire the C2S/S2S a bit more frequently.

> Another option, I suppose, might be to support multiple Ks in use at a
> time, such that the clients are split across them. That would add some
> complexity that seems unnecessary given the alternative of just using
> AES-SIV.

Agreed.

> So I think I conclude that we'd be pushing the boundaries of safety at
> NIST scale if AES-GCM is used. There, it seems we should not use
> AES-GCM for the cookies, to protect K, only using AES-SIV there.

Until AES-SIV is broken.  Alternative solution, as James proposed, like
all other good crypto programs I know: just expire the C2s/S2C after some
reasonable time.

> >> The NTS protocol does
> >> not rotate C2S/S2C.  
> > 
> > Yes, that is bad.  
> The client is not attacking C2S/S2C, because they have C2S/S2C. I've
> addressed the general limit on messages above. If you want to discuss
> some other, specific attack on C2S/S2C, please describe it.

Right, he is attacking K.

> > But what if a thousand AWS instances hit the NIST servers with the
> > same cookie for days, weeks, months.  Each at one second
> > intervals.  10e11 comes quickly  
> Again, for clarity: if multiple clients are sharing the same C2S/S2C
> ("the same cookie"), they are not attacking C2S/S2C, as they have
> that. They are attacking K.
> 
> The implementation decides how to handle K.

Yup, we actually get to make a decision.

> The draft just makes a
> suggestion. (In fact, the whole thing suggesting K at all is just a
> suggestion for the cookie format, but it's likely the general approach
> that will be used by most implementations.)

Yup.  We need to improve on the flawed draft.

> Assuming we're following the recommendation, then K will be rotated
> with a lifetime of two days.

Wrong.  Once again, the draft does NOT rotate K.  It 'ratchets' it.

Flawed assumptions leading to flawed conclusions.

> If each K is randomly generated (let's address ratcheting separately),

Once again, flawed assumption.  Please reread section 6.  NOT randomly
generated.

> do you agree that the window for attack is however long K is valid,
> which by the recommendation is two days?

Yeah, if assume what we are not going to do, then it works.

> > The key is NOT rotated and NOT replaced.  It is 'ratcheted'.  
> 
> This is only a suggestion. It may be better to just generate random Ks
> that the NTS-KE and NTP server share. And also accept as a design
> constraint that NTP servers do not share K.

My preference.  Except it opens up a new can of worms.  How does the
NTPD server tell the NTS-KE what the new K is?

> A large installation could then work like this:
>
> 1) Present a name time.example.com pointing to a single IPv4 as
> before. 2) As before, this IP hits a load balancer.  3) (Non-NTS) NTP
> traffic on UDP port 123 to this IP continues to go to the backend
> servers as always.

Lost me.  Non-NTS is not at issue here.

> In this way, each NTS-KE/NTP server is fully independent (which is a
> nice property anyway) with no need to share K. Then, K can just be
> randomly generated, which takes away any concern about the ratcheting
> mechanism weakening security.

Works for me.  How do we do that?

> > So any master key K that I can eliminate today, I can use the same
> > ratchet, and eliminate tommorrow.
>
> I am not well-versed enough to know if this is correct or not. It
> *sounds* reasonable to me, which would argue against using the
> ratcheting mechanism.

Yup.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190202/fc290b97/attachment.bin>