AUTH related issues about draft-westerlund-tsvwg-dtls-over-sctp-bis

[emanjon]

5. Might make sense to register some of SHA-384, SHA-512, SHAKE128, SHAKE256, but not required for RFC6083bis. SHA-384 is required for compliance with US CNSA suite.

[gloinul]

How to deal with this needs further discussion, even if the main part is a separate update of SCTP-AUTH to define those algorithms.

[gloinul]

Let see if we can conclude on this issue. I think what we say is the following.

RFC6083bis can mandate that one uses a SCTP-AUTH implementation that supports SHA-256 and that it prioritize that over SHA-1.

The socket API is lacking functionality to verify that SHA-256 was chosen to be used, but technically this specification can mandate that one verify that choice and if not abort the SCTP connection.

Outside of the scope of this document it would be desirable that the following happened.

SCTP-AUTH update (RFC4895bis) that implements the following:

• Updates the mandatory to implement algorithms and recommended priorities between them.
• Define additional algorithms e.g. SHA-384, SHA-512, SHAKE128, SHAKE256

SCTP Socket API update

• Improved functionality for prioritizing algorithms and control action or verify choice after handshake.

Does anyone see an issue with simply continue with the current method of simply mandating the algorithm support?

[tuexen]

I agree with updating RFC 4895bis, but we currently have RFC 4960bis and the NAT document in TSVWG. My experience is, that TSVWG can handle one SCTP document at a time well. More are difficult. So it may take a while until we can work on 4895bis.

RFC 4895bis does specify SHA-256 and the Socket API can handle it. It can also handle priorities of different algorithms. So we just need to use a working that SHA-256 must be supported and negotiated. Right now, we can't avoid SHA-1 also to be listed as supported. So setting SHA-256 with higher priority is covered (and default in FreeBSD). We just need a way to check what SHA-256 will actually be used. I think we can add the required socket API stuff in this document. This is simple to do and I'm willing to propose the Socket API Considerations section. Then we are completely covered without relying on other documents. OK?

[gloinul]

Yes, I am fine with adding a SocketAPI consideration.

[emanjon]

"RFC6083bis can mandate that one uses a SCTP-AUTH implementation that supports SHA-256 and that it prioritize that over SHA-1.

The socket API is lacking functionality to verify that SHA-256 was chosen to be used, but technically this specification can mandate that one verify that choice and if not abort the SCTP connection."

Allowing negotiation of SHA-1 and then abort if it is chosen seems a bit werid. That is also what the current draft says.

Wouldn't it be better to say that when RFC6083bis is used, then SHA-1 shall not be in the HMAC-ALGO parameter?

[tuexen]

"RFC6083bis can mandate that one uses a SCTP-AUTH implementation that supports SHA-256 and that it prioritize that over SHA-1.

The socket API is lacking functionality to verify that SHA-256 was chosen to be used, but technically this specification can mandate that one verify that choice and if not abort the SCTP connection."

Allowing negotiation of SHA-1 and then abort if it is chosen seems a bit werid. That is also what the current draft says.

Wouldn't it be better to say that when RFC6083bis is used, then SHA-1 shall not be in the HMAC-ALGO parameter?

To avoid interoperability problems, SHA-1 is a MUST to implement and offer. See RFC 4895 for the protocol and you can also not disabled it via the API as specified in RFC 6458. If you are not listing SCTP_AUTH_HMAC_ID_SHA1, the IPPROTO_SCTP level socket option SCTP_HMAC_IDENT will fail to set the parameters.

So we need to do the negotiate with SCTP_AUTH_HMAC_ID_SHA1 dance and lateron check that we are only using SCTP_AUTH_HMAC_ID_SHA256.