DTLS Considerations for Handling of Endpoint Pair Shared Secrets about draft-westerlund-tsvwg-dtls-over-sctp-bis

[emanjon]

I plan to adress #183 and #184 in the same PR as they affect the same clauses.

[emanjon]

Regarding DTLS 1.2

RFC 6083

   Before sending the Finished message, the active SCTP-AUTH key MUST be
   switched to the new one.

   Once the corresponding Finished message from the peer has been
   received, the old SCTP-AUTH key SHOULD be removed.

In draft-ietf-tsvwg-dtls-over-sctp-bis-04 this has been changed to

   After sending the DTLS Finished message for the
   initial DTLS connection, the active SCTP-AUTH key MUST be switched
   from key identifier 0 to key identifier 1.  Once the initial Finished
   message from the peer has been processed by DTLS, the SCTP-AUTH key
   with Shared Key Identifier 0 MUST be removed.

   After sending the DTLS Finished message, the new SCTP-AUTH key can be
   used according to Section 4.7.

I don't understand why this was changed (though I might be responsible...). The abobe text in draft-ietf-tsvwg-dtls-over-sctp-bis-04 seems to contradict other text in draft-ietf-tsvwg-dtls-over-sctp-bis-04

   The 64-byte shared secret MUST be provided to the SCTP stack as soon
   as the computation is possible.

[emanjon]

Also, after the completion of the DTLS handshake, a new SCTP-AUTH key will be exported per {{handling-endpoint-secret}}.
This is also different from RFC 6083.

[gloinul]

We should clarify that no ULP data shall be sent until the peer has been authenticated by the endpoint, as well as having derived the key for SCTP-AUTH.

[gloinul]

I do think this issue is now handled with text changes in -05.