[tsvwg] DTLS over SCTP (RFC6083bis): Key-update limitation issue

[Magnus Westerlund <[e-mail]>]

Hi TSVWG,

 

We authors of DTLS over SCTP update
(https://datatracker.ietf.org/doc/draft-ietf-tsvwg-dtls-over-sctp-bis/) have
run into an issue which we think do requires a design direction choice. That
is the reason for the lengthy message below. 

 

So we know that we are going to rekey DTLS fairly frequently for two
reasons. First with DTLS 1.2 and if you want to maintain PFS and not allow a
key-reveal to back track much, then rekeying every hour to a couple of hours
is recommended. Secondly AES-GCM cipher to protect the DTLS records have a
fairly low AEAD limit of 2^24.5 DTLS records before rekeying needs to occur.
Initiating rekeying is not an issue. The main issue we have is to determine
when after a rekeying has occurred the receiver can drop the old keys. 

 

With SCTP's support for multiple streams, with independent transmission of
user messages and its reliability mechanism this becomes a difficult puzzle.
If one looks into the SCTP Sender side one can track which SCTP user
messages or even individual SCTP packets that carry DTLS records that are
protected with a certain key, and thus determine when all of these DTLS
records using the old key have been delivered to the receiver and
acknowledged in a non-renegable way. Then the sender can thus determine that
the receiver will not need the old key anymore.

 

The receiver side of knowing when a key is no longer in use is even harder,
as the receiver may not have seen the user message that is outstanding due
to packet loss and therefore would need an explicit signal from the sender
that it is no longer using a key. 

 

The design in the current version of the draft relies on tracking which key
was used based on the SCTP-AUTH key, which for DTLS 1.2 has a one to one
relationship with the DTLS key and that has a key-ID. However, the current
SCTP API for SCTP-AUTH has made an assumption that you would not rekey in
the middle of an individual user message. The SCTP-AUTH spec can support
rekeying of SCTP-AUTH in the middle of user messages, it is only a factor of
the API and its current function that allow us to use that API from DTLS
level to track when all user messages have been delivered. In summary, each
side in its sender role need to verify that all previous key packets have
been delivered prior to a rekeying. Then the rekey is used as explicit
signal to the receiver  that it can drop the previous key. Thus, the
receiver will have the current key (n) and previous (n-1) key. And n-1 will
only be removed when key n+1 is in place.

 

So if we keep the current design and want to make it possible to implement
the DTLS over SCTP with the current API as basis, then we will have
limitations on how large user messages and how long their delivery may take.
Basically a large user message may not require more bytes then what is
available from the current key's AEAD limit, it needs to be possible to
complete transmission before the next rekeying can occur. You will not be
able to rekey to the next key (n+1), until the user message using key n-1
has completed transmission. And this could cause a block against sending new
user messages if the key-limit is reached for key n. 

 

The strict upper limit to a user message size will be 2^38.5 bytes, i.e. the
user message consume the whole AES-GCM key limit in bytes. Thus in practice
likely a magnitude or more smaller messages can be used. As said you need to
complete the transmission of  this whole message before the need to do the
next, next rekeying. Our thoughts is that this is not suitable for any
application that attempts to use one or more stream as a byte stream within
a single user message and like to apply DTLS to it. We don't know about any
such application currently. 

 

Currently we don't think these limitations will be a problem, however they
are introducing limitations to SCTP that does not exist if you don't attempt
to use DTLS over SCTP. If you have such an application that would run into
this problem we need to hear it. 

 

We have also so far considered two alternative designs (B and C) that could
resolve this issue but which we think have other draw backs that are
significant also.

 

B) As the core of the issue is the SCTP API and how it tracks SCTP-AUTH
keys, we could abandon/update the SCTP API and demand that applications are
capable of tracking the user message packet ranges that are protected with
different keys. Then DTLS and SCTP-AUTH could rekey freely when needed given
that they ensure that all SCTP packets with reliable user messages protected
by the previous key has been delivered. However, this disregard the SCTP API
that are fairly well used would mean that deployment of this version would
be substantially harder and require updated SCTP stack implementations and
APIs. Also an updated SCTP API would be substantial amount of work.  

 

C) We could break the ULP user message to SCTP user message mapping. This
would allow the DTLS layer to freely fragment user messages and the
individual DTLS records and their related keys on to different SCTP user
messages. This would enable rekeying, but would require expanded
functionality in the DTLS layer to track fragments and user message end
markers for the different upper layer protocol user messages. 

 

We will think if we can come up with other solutions and if you have ideas
don't hesitate to contact us. 

 

Thus, we are asking two things of you.

 

First, do you know of an SCTP application that use very large user messages
or maps byte streams onto single SCTP user messages?

 

Secondly, is the currently outlined solution with limitations sufficient, or
do we need alternative designs like B or C?

 

Your feedback is highly appreciated

 

For the co-authors

 

Magnus Westerlund

 

We are tracking this issue at:

https://github.com/gloinul/draft-westerlund-tsvwg-dtls-over-sctp-bis/issues/
62