Subject: [tsvwg] RFC4895bis - List of things that should be done

From: John Mattsson <[email-masked]>
Date: Fri, 25 Mar 2022 10:14:26 +0000

Hi,

Good with some discussion on RFC4895bis this week. As I said before I think RFC4895bis should be written. I read through RFC 4895 and made a list of things I think should be done in RFC4895bis:

-- Make SHA-1 NOT RECOMMENDED to use and not mandatory to support (long term goal should be to completely phase out SHA-1 everywhere in the IETF).

-- Make HMAC-SHA-2 mandatory to implement (only current alternative).

-- Change "HMAC" to the more generic "MAC" to enable future registrations of KMAC, CMAC or any type of MAC. The registry would then be renamed "MAC Identifiers" and contain HMAC-SHA-1 and HMAC-SHA-256 instead of SHA-1 and SHA-256 (no technical changes).

-- Possibly register more algorithms like HMAC-SHA-384 (required by CNSA suite) and KMAC128 (KMAC is the preferred way to do MAC with SHA-3)(SHA-256 and SHA-384 are part of SHA-2). Some of the new MACs could potentially have 128 bits tags instead of 256 bit tags. 256 is overkill for a MAC with 128-bit security.

-- Slightly updated security considerations briefly mentioning the need derive the endpoint pair shared keys with Diffie-Hellman to get forward secrecy and to frequently rekey to avoid “key limits” and to force an attacker to do what RFC 7624 calls dynamic key exfiltration instead of static key exfiltration. These things are required to follow modern zero-trust principles.

Cheers,
John

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 25 Mar 2022 11:32:17 +0100

> On 25. Mar 2022, at 11:14, John Mattsson <john.mattsson=[email-masked]> wrote:
> 
> Hi,
>  
That can break backwards compatibility. For example, the Linux kernel implementation only
support HMAC-SHA1 right now. So adding more algorithms and make additional ones mandatory
to implement (like HMAC-SHA-2) is fine.
> -- Make HMAC-SHA-2 mandatory to implement (only current alternative).
Yepp. Already implemented in the FreeBSD kernel implementation since its beginning.
> -- Change "HMAC" to the more generic "MAC" to enable future registrations of KMAC, CMAC or any type of MAC. The registry would then be renamed "MAC Identifiers" and contain HMAC-SHA-1 and HMAC-SHA-…
I agree.
> -- Possibly register more algorithms like HMAC-SHA-384 (required by CNSA suite) and KMAC128 (KMAC is the preferred way to do MAC with SHA-3)(SHA-256 and SHA-384 are part of SHA-2). Some of the new…
I agree with adding more algorithms.
> -- Slightly updated security considerations briefly mentioning the need derive the endpoint pair shared keys with Diffie-Hellman to get forward secrecy and to frequently rekey to avoid “key limits”…
I don't understand this point. We do have a way of computing the shared key. This is simply
a concatenation of some fields. No DH, no lifetime limitations. Changing this would break
backwards compatibility.

There are also some text improvements I got reported over the time.

I would be willing to work on such a document, if there is any chance in the WG to get
it accepted.

If this work is started, a question would be to either
* have a small document only coping with the differences
or
* have a single document covering everything in one document.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 25 Mar 2022 12:49:03 +0100

> On 25. Mar 2022, at 11:32, Michael Tuexen <[email-masked]> wrote:
> 
And it might even makes sense to move the Socket API Considerations from
draft-ietf-tsvwg-dtls-over-sctp-bis to an SCTP AUTH specific document,
since it actually would better fit.

Best regards
Michael

---

From: John Mattsson <[email-masked]>
Date: Mon, 28 Mar 2022 14:08:56 +0000

Hi,

- I think it would be best to have a single RFC4985bis document obsoleting RFC4895. I think that is preferable for most readers.

- Agree that it would make sense to move the Socket API Considerations from
draft-ietf-tsvwg-dtls-over-sctp-bis to an RFC4895bis.

- I would be willing to help with a RFC4985bis document (but I am on 2/3 parental leave until September, I have more time for IETF 115).

Cheers,
John

From: Michael Tuexen <[email-masked]>
Date: Friday, 25 March 2022 at 12:49
To: John Mattsson <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [tsvwg] RFC4895bis - List of things that should be done

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 28 Mar 2022 16:25:25 +0200

> On 28. Mar 2022, at 16:08, John Mattsson <john.mattsson=[email-masked]> wrote:
> 
> Hi,
>  
I depends how much text is touched. I normally check this with the WG chairs and the
responsible AD. I can try to do that.
> draft-ietf-tsvwg-dtls-over-sctp-bis to an RFC4895bis.
OK, fine.
> - I would be willing to help with a RFC4985bis document (but I am on 2/3 parental leave until September, I have more time for IETF 115).
Thanks. No hurry. We still have two SCTP related documents ahead of this. And possibly RFC 6951bis.

Best regards
Michael