Subject: Re: [tsvwg] New Version Notification - draft-ietf-tsvwg-rfc4960-bis-16.txt

From: John Mattsson <[email-masked]>
Date: Sun, 31 Oct 2021 19:24:23 +0000

Hi,

I reviewed the crypto parts of the draft and have some comments on the following text:

  "There is a tradeoff
   between to computational complexity and the level of security the MAC
   provides. Using the HMAC-SHA1 might be an acceptable compromise.
   The secret key SHOULD be random ([RFC4086] provides some information
   on randomness guidelines).  The secret keys need to have an
   appropriate size.  When using HMAC-SHA1, secret keys of at least 160
   bits are appropriate according to [RFC2104]."

The first statement seems to indicate that that the choice of MAC makes a performance difference. For the cookie use case in SCTP I would say that the choice is negligible. I would suggest deleting this sentence.

Regarding SHA-1. HMAC-SHA1 has been removed or degraded to NOT RECOMMENDED in most IETF security protocols. There is an industry-wide trend to deprecate its usage. Governments like BSI and NIST treat SHA-1 as a legacy algorithm.

Many modern CPUs include acceleration of SHA-256 and SHA-1. Many future CPUs will likely have acceleration of SHA-256 but not SHA-1, see e.g., the RISC-V document [1]. SHA-1 might be a non-optimal recommendation for both performance, compliance, and security going forward.

[1] https://github.com/riscv/riscv-crypto/releases/download/v1.0.0-rc5-scalar/riscv-crypto-spec-scalar-v1.0.0-rc5.pdf

I don't think a draft published in 2021 or 2022 should give SHA-1 as a recommendation or example. I would suggest updating the text as follows:

OLD:
  "There is a tradeoff
   between to computational complexity and the level of security the MAC
   provides. Using the HMAC-SHA1 might be an acceptable compromise.
   The secret key SHOULD be random ([RFC4086] provides some information
   on randomness guidelines).  The secret keys need to have an
   appropriate size.  When using HMAC-SHA1, secret keys of at least 160
   bits are appropriate according to [RFC2104]."

NEW:
   "One example MAC algorithm that can be used is HMAC-SHA-256.
   The secret key SHOULD be random ([RFC4086] provides some information
   on randomness guidelines).  The secret keys need to have an
   appropriate size.  When using HMAC-SHA-256, secret keys of at least
   256 bits are appropriate according to [RFC2104]."

Cheers,
John

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 31 Oct 2021 22:19:06 +0100

> On 31. Oct 2021, at 20:24, John Mattsson <john.mattsson=[email-masked]> wrote:
> 
> Hi,
>  
Hi John,

these changes came in via the secdir review. The discussion is still ongoing.
Right now, no concrete algorithm is suggested anymore. Here is the current
text (might change):

There is a tradeoff between to computational complexity and the level of
security the MAC provides.
A MAC with acceptable security properties SHOULD be used.
The secret key SHOULD be random (<xref target='RFC4086'/> provides some
information on randomness guidelines).
The secret keys need to have an appropriate size.
The secret key SHOULD be changed reasonably frequently (e.g., daily), and the
timestamp in the State Cookie MAY be used to determine which key is used to
verify the MAC.</t>
<t>Since the State Cookie is not encrypted, it MUST NOT contain information
which is not being envisioned to be shared.</t>

Since the choice of the concrete algorithm does not affect interoperability,
I actually prefer not specifying any particular algorithm (like it was
in RFC 2960 and RFC 4960).

Best regards
Michael

---

From: John Mattsson <[email-masked]>
Date: Sun, 31 Oct 2021 21:45:27 +0000

Thanks Michael,

Good to hear that this is already taken care of.

>in RFC 2960 and RFC 4960).

I agree. I suggested HMAC-SHA-256 simply because draft-ietf-tsvwg-rfc4960-bis-16 talked about HMAC-SHA1.

The new text seems good. I would still suggest deleting the sentence

   “There is a tradeoff between to computational complexity and the level of
     security the MAC provides.”

While this is a correct statement, I don’t see how it would be relevant for a reader of draft-ietf-tsvwg-rfc4960-bis. In fact, I think it might make the reader believe the choice of MAC has a significant effect on performance, which I think it does not.

Cheers,
John

From: Michael Tuexen <[email-masked]>
Date: Sunday, 31 October 2021 at 22:21
To: John Mattsson <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [tsvwg] New Version Notification - draft-ietf-tsvwg-rfc4960-bis-16.txt
> [1] https://protect2.fireeye.com/v1/url?k=6f2823a2-30b31aa0-6f286339-869a14f4b08c-afb3d099b09501aa&q=1&e=3a2f97e7-d069-4ba0-bf41-1a02b1c7fe7a&u=https%3A%2F%2Fgithub.com%2Friscv%2Friscv-crypto%2Freleases%2Fdownload%2Fv1.0.0-rc5-scalar%2Friscv-crypto-spec-scalar-v1.0.0-rc5.pdf
>
Hi John,

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 31 Oct 2021 22:57:36 +0100

> On 31. Oct 2021, at 22:45, John Mattsson <john.mattsson=[email-masked]> wrote:
> 
> Thanks Michael,
>  
Well, if you are looking at resistance against cookie flooding attacks where
the attacker just sends garbage, it is the CPU resource you are spending
before dropping the packet.

Best regards
Michael