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

From: John Mattsson <[email-masked]>
Date: Mon, 1 Nov 2021 15:17:28 +0000

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

True, the choice of MAC algorithm can probably make a difference during cookie flooding attacks. But I think it is still not a tradeoff between security and performance. The tradeoff between computational complexity and the level of security is true for a cryptographer designing a new algorithm, but not for an implementor or user of SCTP. There is no strong correlation between performance and security in currently used MAC algorithms. On a modern CPU, HMAC-SHA-256, BLAKE3, and HopMAC-KangarooTwelve are all much faster than HMAC-MD5 while also offering much higher security. I would suggest rephrasing to something along the lines of:

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

NEW: "MAC algorithms can have significantly different performance depending on the platform. Choosing a high performance MAC algorithm increases the resistance against cookie flooding attacks”

Cheers,
John

From: Michael Tuexen <[email-masked]>
Date: Sunday, 31 October 2021 at 23:00
To: John Mattsson <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [tsvwg] New Version Notification - draft-ietf-tsvwg-rfc4960-bis-16.txt
> On 31. Oct 2021, at 22:45, John Mattsson <john.mattsson=[email-masked]> wrote:
>
> Thanks Michael,
>
> Good to hear that this is already taken care of.
>
> >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).
>
> 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.
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
>
> 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
>
> > On 31. Oct 2021, at 20:24, John Mattsson <john.mattsson=[email-masked]> wrote:
> >
> > 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://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
> >
> > 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]."
> 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
> >
> > Cheers,
> > John

---

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

> On 1. Nov 2021, at 16:17, John Mattsson <[email-masked]> wrote:
> 
> Hi Michael,
>  
Tero: OK with you?

Best regards
Michael

---

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

[email-masked] writes:
> > True, the choice of MAC algorithm can probably make a difference
> > during cookie flooding attacks. But I think it is still not a
> > tradeoff between security and performance. The tradeoff between
> > computational complexity and the level of security is true for a
> > cryptographer designing a new algorithm, but not for an
> > implementor or user of SCTP. There is no strong correlation
> > between performance and security in currently used MAC algorithms.
> > On a modern CPU, HMAC-SHA-256, BLAKE3, and HopMAC-KangarooTwelve
> > are all much faster than HMAC-MD5 while also offering much higher
> > security. I would suggest rephrasing to something along the lines
> > of:
> > 
> > NEW: "MAC algorithms can have significantly different performance
> > depending on the platform. Choosing a high performance MAC algorithm
> > increases the resistance against cookie flooding attacks” 
> Tero: OK with you?

Looks good for me.

On the other hand, not sure if the performance is really significantly
different, so perhaps just say "have different performance"...
-- 
[email-masked]

---

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

> On 1. Nov 2021, at 17:59, Tero Kivinen <[email-masked]> wrote:
> 
OK. Will take that sentence.

Best regards
Michael