Epoch handling about draft-westerlund-tsvwg-dtls-over-sctp-bis

[gloinul]

First of all I think draining needs to be avoided due to its impact on the application. We can't wait multiple RTT to ensure that the data for all DTLS records with one epoch to be successfully delivered before sending anyone with the new epoch. So I think we need to find a solution that works robustly but also don't cause long delays in finishing this.

So on the sender side there is to my knowledge no issue. The sender switches epoch and simply uses the new keys associated with that epoch and never switches back for all future DTLS records it does protection operation. And to my understanding this can occur in the middle of user message without issues.

It is on the receiver the problem arises when to determine when all DTLS record with the old epoch has been delivered. I think we want to assume the worst case here for this interaction. I think two factors that would be bad are I-DATA combined with a sender implementation that allows sender side buffering between the DTLS protection operation and the SCTP API send call. What I am fearing here is that a large user message have been processed by the DTLS protection operation, but not given to the SCTP stack to send, and in the process of scheduling this buffered user message with old epoch another user message contains DTLS records with new epoch are scheduled and prioritized for transmission.

So from the receiver perspective an epoch changes are initiated by receiving the first DTLS record with the new epoch. So when are the receiver certain that all old epoch DTLS records have been delivered and processed by the DTLS layer? So from a receiver perspective I think this is hard to guarantee due to that the receiver does not know if there are user message on streams that it has not yet seen. My conclusion is that we either have a robust mechanism based on timers and one simple mechanism as proposed below, or we need to have an explicit mechanism for the sender to indicate that it has sent all. I don't think the explicit mechanism is aligning with the goal to finish this work this year. So lets consider if the below proposal is robust enough to be acceptable.

The proposal has these components.

1. A recommendation that the receiver do keep the keep the prior epoch keys longer than maybe usually in other use cases with motivation. My suggestion would be to not drop any key prior to 5 minutes after the last seen DTLS record with that epoch. And for communication scenarios with high RTT or low bandwidth where some low priority user messages may get stuck on the sender side to have this configurable to even higher values.

2. To recommend against to rapid key changes, i.e. keep keys at least for 15+ minutes. And to support more rapid key changes mandate a limitation on the sender to not switch to a new key (epoch) until it has confirmed that all DTLS records on a the prior epoch has been delivered to the receiver. A small hold over just to ensure that the receiver process all the received DTLS records before dropping the key may be needed. This enables the receiver to not need to store more than the latest epoch and the epoch before that for any durations. This requirement pushes the complexity of tracking the user messages and what epoch they have been protected with onto the sender that want to do rapid re-keying. QUIC implements a similar limitation to prevent the key-updates to be out of synch as it uses a single bit to indicate key-phase between the endpoints.

3. As this is timer a failure is not guaranteed to never occur, but I think to be extremely unlikely that we have a case where the receiver will fail to decrypt a DTLS Record because of old epoch. For SCTP user messages that are reliable, and where the sender thinks that the user message was received and the message fails to completely be delivered we need to abort the DTLS connection to signal this so that the application is aware of the failure and can restart the interaction. I think one can be clear that to avoid this from happening one could raise the time for 1) to infinity and only use 2) and have that be implemented.

So I think this is robust enough and can work without draining. It clearly need some text changes to be described and with clear motivation why SCTP makes this hard to determine than in many DTLS applications.

[tuexen]

First of all I think draining needs to be avoided due to its impact on the application. We can't wait multiple RTT to ensure that the data for all DTLS records with one epoch to be successfully delivered before sending anyone with the new epoch. So I think we need to find a solution that works robustly but also don't cause long delays in finishing this.

OK. RFC 6083 relies on that. So we need something else. However, I'm not sure if DTLS implementations support sending user messages which a renegotiation is in process.

So on the sender side there is to my knowledge no issue. The sender switches epoch and simply uses the new keys associated with that epoch and never switches back for all future DTLS records it does protection operation. And to my understanding this can occur in the middle of user message without issues.

I just doubled checked the RFC, and from a receiver perspective you are right. You can use multiple shared secrets for a single user message. When you only consider RFC 4895, you are right, too. However, if you have an SCTP implementation using the socket API as specified in RFC 6458, you are using a single shared key identifier for a user message. The same shared key identifier is also used for retransmissions. That is the reason why you can de-activate a share key (see RFC 6458) and delete one (see RFC 6458 if it is deactivated and not used anymore by the SCTP stacks, indicated by an SCTP_AUTH_FREE_KEY indication (see RFC 6458.

It is on the receiver the problem arises when to determine when all DTLS record with the old epoch has been delivered. I think we want to assume the worst case here for this interaction. I think two factors that would be bad are I-DATA combined with a sender implementation that allows sender side buffering between the DTLS protection operation and the SCTP API send call. What I am fearing here is that a large user message have been processed by the DTLS protection operation, but not given to the SCTP stack to send, and in the process of scheduling this buffered user message with old epoch another user message contains DTLS records with new epoch are scheduled and prioritized for transmission.

I think user messages must no span multiple epochs... I would say that all messages sent by the application before triggering a re-negotiation must be handled in the old epoch. All messages sent by the application after the re-negotiation has been completed must be handled by the new epoch. This leaves out the messages sent after the re-negotiation has be triggered, but has not been completed. If we want to allow them to be sent, they can only use the old epoch. But I'm not sure how flexible DTLS implementations are...

Handling of the AUTH shared keys are simple on the sender side.

So from the receiver perspective an epoch changes are initiated by receiving the first DTLS record with the new epoch. So when are the receiver certain that all old epoch DTLS records have been delivered and
processed by the DTLS layer? So from a receiver perspective I think this is hard to guarantee due to that the receiver does not know if there are user message on streams that it has not yet seen. My conclusion is that we either have a robust mechanism based on timers and one simple mechanism as proposed below, or we need to have an explicit mechanism for the sender to indicate that it has sent all. I don't think the explicit mechanism is aligning with the goal to finish this work this year. So lets consider if the below proposal is robust enough to be acceptable.

We do have to make sure that the receiver configured a new shared secret before a packet is received, which uses it. If we fail, the packet will be dropped.

The proposal has these components.

1. A recommendation that the receiver do keep the keep the prior epoch keys longer than maybe usually in other use cases with motivation. My suggestion would be to not drop any key prior to 5 minutes after the last seen DTLS record with that epoch. And for communication scenarios with high RTT or low bandwidth where some low priority user messages may get stuck on the sender side to have this configurable to even higher values.

We need to distinguish between what the DTLS layer does with the key material it uses and what the DTLS layer with the key material SCTP uses and is configured by the DTLS layer.

2. To recommend against to rapid key changes, i.e. keep keys at least for 15+ minutes. And to support more rapid key changes mandate a limitation on the sender to not switch to a new key (epoch) until it has confirmed that all DTLS records on a the prior epoch has been delivered to the receiver. A small hold over just to ensure that the receiver process all the received DTLS records before dropping the key may be needed. This enables the receiver to not need to store more than the latest epoch and the epoch before that for any durations. This requirement pushes the complexity of tracking the user messages and what epoch they have been protected with onto the sender that want to do rapid re-keying. QUIC implements a similar limitation to prevent the key-updates to be out of synch as it uses a single bit to indicate key-phase between the endpoints.
3. As this is timer a failure is not guaranteed to never occur, but I think to be extremely unlikely that we have a case where the receiver will fail to decrypt a DTLS Record because of old epoch. For SCTP user messages that are reliable, and where the sender thinks that the user message was received and the message fails to completely be delivered we need to abort the DTLS connection to signal this so that the application is aware of the failure and can restart the interaction. I think one can be clear that to avoid this from happening one could raise the time for 1) to infinity and only use 2) and have that be implemented.

So I think this is robust enough and can work without draining. It clearly need some text changes to be described and with clear motivation why SCTP makes this hard to determine than in many DTLS applications.

[gloinul]

@tuexen yes you are completely correct that we need to distinguish between renegotiations that change the SCTP-AUTH key and what is key update in DTLS layer. It was the later that I was thinking of when writing this. Because these operations can be fairly frequent compared to the actual need for the renegotiations. Very few process will exhaust the SCTP-AUTH keys usage limitations within the timespan you want to do these renegotiations for the reason of re-authenticating the endpoints and ensuring PFS. This later appear to be recommended to be done on 1-2 hour basis and in that time you would have to have an extremely high-rate application to exhaust HMAC with SHA-256. However, the AES-GCM keys may have to change more frequently than that due to the more limited key-usage limits.

[gloinul]

Author discussion conclusion was:

• SCTP-AUTH key is bound to user message in socket API.
• Basic rule is that old key will be retired when yet another renegotiation happens.
  • Sender will have to verify that user messages with oldest key has fully been sent before initiating and accepting a renegotiation.
  • This is an actual limitation on the user of the stack they need to follow.
  • Receiver may retire a key earlier if it is certain that it no longer in use.
• Risk of retiring a SCTP-AUTH key to early in receiver is that the user message will never be delivered, any retransmission will be dropped by receiver. Needs some type of handling

[tuexen]

OK, I tried to address this issue in #55.

However, two points are open:

• I don't know how to implement:

   Prior to processing a received ClientHello message or ServerHello
   message, all other received SCTP user messages that are buffered in the
   SCTP layer and can be delivered to the DTLS layer MUST be read and
   processed by DTLS.
  

  The only way I so to do this, is to read SCTP messages until the receive buffer is empty. But what if the sender keeps sending faster than the receiver can read? The receiver can't say something like "I want only read messages which where in the receiver buffer before the the ClientHello arrived".

• For DTLS 1.3 the sender stops sending when an KeyUpdate is sent until it receives an Ack message.

[gloinul]

Closing this and instead tracking remaining issue with much more specific issues #59, #60 and #62