Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15

From: Tero Kivinen <[email-masked]>
Date: Mon, 1 Nov 2021 14:22:42 +0200

[email-masked] writes:
> > But the draft does not suggest the method used by FreeBSD, but instead
> > suggest creating TCB and taking minimal subset of it. TCB might have
> > some private data in it, so perhaps adding some comment about that
> > too.
> The text has changed. It doesn't mention the TCB anymore in this subsection.
> 
> It reads:
> 
> Inside this State Cookie, the sender SHOULD include a MAC (see [RFC2104]
> for an example), a timestamp on when the State Cookie is created, and the
> lifespan of the State Cookie, along with all the information necessary for
> it to establish the association including the port numbers and the
> verification tags.

Looks good. 

> > I.e., say that as the cookie is not encrypted care must be taken when
> > constructing cookie, so that the cookie does not leak out any
> > information that should not be leaked.
> Sure. What about adding the following sentence:
> 
> Since the State Cookie is not encrypted, it MUST NOT contain information
> which is not being envisioned to be shared.

That sounds ok too. 

> > Anyways as this is internal matter to the implementation I do not
> > think we need to recommend any specific algorithm, we could simply say
> > any MAC with acceptable security properties is fine, and if we really
> > want to suggest something suggesting HMAC-SHA256 or similar might be
> > better.
> OK. So I remove (the recently added) sentence:
> 
> Using the HMAC-SHA1 might be an acceptable compromise.
> 
> and replace it by
> 
> A MAC with acceptable security properties SHOULD be used.

Yep.

> Then it makes sense to also remove (the recently added) sentence:
> 
> When using HMAC-SHA1, secret keys of at least 160 bits are appropriate according
> to <xref target='RFC2104'/>.

Yep.

> Should I also change back "reasonably frequently (e.g., daily)" to
> "reasonably frequently" when describing that the secret should be
> changed?

Daily does not sound very frequent to me... The attack that this
protects is that someone slowly collects millions of cookies over some
period of time, and then suddenly flood all those connection attempts
to the server all at once, i.e., simulating monday morning problem.

If I have understood correctly the cookie only needs to be valid for
few seconds at most (i.e., few round trips over the network while the
connection is being formed), and the cost of changing secret is just
generating few random bits, changing it hourly or something is not too
expensive. You do need to remember the previous secret for some time
after secret was changed, but for that you can limit yourself to few
tens of seconds.

This of course depends what the failure model is when cookie is wrong.
In IKEv2, if cookie is wrong the server just generates a new cookie,
and sends that back to client, and client retries with that new
cookie. I.e., even if the secret changed in the middle and the old
cookie is no longer accepted as it was using old secret, this is not a
fatal error, it just causes one extra round trip.

The frequency how often you want to change the secret depends how many
outstanding cookies you want to allow. Of course if you do have
lifespan of the cookie inside the cookie, then you can limit the
lifespan even without changing the secret, but changing secret will
also limit the lifespan without a need of storing lifespands in the
cookies.
-- 
[email-masked]

---

From: [email-masked]
Date: Mon, 1 Nov 2021 16:10:57 +0100

> On 1. Nov 2021, at 13:22, Tero Kivinen <[email-masked]> wrote:
> 
We have a cookie lifetime in the cookie. The default value is 1 minute.
If this is too short, the peer can request a longer lifetime, up to
(2^32 - 1) usec, which is about 70 Minutes (there is no requirement
to follow such an request).
In FreeBSD you can change the time after which the secret is changed.
We use 1 hour as the default and keep the current and the last secret.

So if you prefer, I can
(a) remove (e.g., daily)
(b) change (e.g., daily) to (e.g., hourly)
(c) anything else you would prefer.

Just let me know...

Best regards
Michael

---

From: David Mandelberg <[email-masked]>
Date: Mon, 1 Nov 2021 12:00:37 -0400

> (c) anything else you would prefer.

I prefer (b) or explaining the criteria for picking how often to change 
the secret. I think (a) is likely to result in misunderstandings about 
what "reasonably frequently" means. E.g., people who are thinking in 
terms of root CA certificates might think it means more than once per 
decade.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 1 Nov 2021 18:55:53 +0200

> (c) anything else you would prefer.

I think you know much better what kind of default to use than me, so
pick something that makes sense to you. Having some kind of indication
what frequently means it good idea, so having something like (e.g.,
xxx) is good thing.
-- 
[email-masked]

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 1 Nov 2021 18:10:39 +0100

> On 1. Nov 2021, at 17:55, Tero Kivinen <[email-masked]> wrote:
> 
OK, will take hourly.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 1 Nov 2021 18:11:17 +0100

> On 1. Nov 2021, at 17:00, David Mandelberg <[email-masked]> wrote:
> 
> I prefer (b) or explaining the criteria for picking how often to change the secret. I think (a) is likely to result 
Will use (b).

Best regards
Michael
> in misunderstandings about what "reasonably frequently" means. E.g., people who are thinking in terms of root CA certificates might think it means more than once per decade.