gloinul / draft-westerlund-tsvwg-dtls-over-sctp-bis Goto Github PK

In #60 there was the proposal of defining a new SCTP Socket API feature that allows one to determine when the sending stack has had all SCTP packets with a specific SCTP-AUTH key-id having been ACKed in a non-renegable way.

If that is going to be a good indicator that all ULP protected user message DTLS records for the corresponding DTLS connection that exported the SCTP-AUTH key some additional rules appear to be required. The current rule and a RFC6458 implementation has no way of sending SCTP packets with a newer DTLS connection SCTP-AUTH key than what has been used. So as long as the DTLS/SCTP implementation starts using the new DTLS connection to protect new ULP user messages and possibly also to complete ongoing ones, there will never be any DTLS records for the old connection in a SCTP packet with the newer SCTP-AUTH key.

However, a more flexible API could follow the current text and switch SCTP-AUTH key immediately while still having DTLS records for the old DTLS connection in the packet. Thus, I think a clarification is necessary that the SCTP-AUTH key used must never be newer than the DTLS records being carried. It is okay to use the old key in SCTP-AUTH for newer DTLS records.

Recevied this comment from Mohamed Boucadair

I have a question about this text:

As SCTP with SCTP-AUTH provides replay protection for DATA chunks,
DTLS/SCTP provides replay protection for user messages.

RFC4895 says the following:

Because SCTP already has a built-in mechanism that handles the
reception of duplicated chunks, the presented solution makes use of
this functionality and does not provide a method to avoid replay
attacks by itself.

With that in mind, what is meant by "SCTP with SCTP-AUTH"?

So we should clarify what we refer to when stating that replay protection exists prior to the decryption of DTLS records.

RFC 7624 defines good terminology and discusses the problems with key exfiltration. We should refer to this document and add a few sentences about this (might replace some existing text in the security consideration).

The initial DTLS connection will be used to establish a new shared
secret as specified per DTLS version below, and which MUST use shared
key identifier 1. After sending the DTLS Finished message, the
active SCTP-AUTH key MUST be switched to the new one. 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.

Some unclarity apparently exist related to the above paragraph. Middle sentence can be clarified to say that one must switch from key-id 0 to key-id 1 which is will occur for the initial DTLS handshake.

Daria raised a potential issues:

"Retransmission negatively impacts on performance. So, it would be good to recommend to set receiver buffer side at least to 2*(2048 + 13(or more because header of message with CID is longer than usual header of DTLS record) + 2^14 ) for such traffic."
This is for traffic that does not support I-DATA but send multiple messages at the same time but in continuous TSN ranges to fit the whole message.

So I think we need to consider if it should be clarified how to interact with the SCTP receiver buffer.

So currently any plain text prior or during a DTLS connection is considered a protocol violation. The reaction to this protocol violation is that it is allowed to do a SCTP association termination (ABORT). This issue is to track two aspect of this, while a related issue is #35 that impacts if plain text occur. But assuming that it can't we should clarify two things.

1. Is MAY the right level or should this be RECOMMENDED or MUST?
2. Should there be a particular error for this being sent back to peer?

I looked into resumption a bit more and made an issue and a PR for RFC8446bis.

The question is if a ticket issued in connection N can be used in the parallel connection N+1. I see no reason why not except for the name "resumption".

RFC8446 is clear on that a ticket issued in connection N can be used to set up the connections N+2 and N+3 in parallel.

tlswg/tls13-spec#1243
tlswg/tls13-spec#1244

See the following mail thread in SAAG.

https://mailarchive.ietf.org/arch/msg/saag/6ImeENhteXGdLsnaJHRoN6LW1zk/

I think we should rephrase to talk about "forward secrecy" and protection against different kinds of key exfitration.

We need the sender dry dance here (similar to the re-negotiation), I guess.

The current text lack any mention of sending updated revocation information, i.e. OSCP stapling.

The document is vary vague on authentication. The TLS spec unfortunatly give the idea it provides authentication. It does not. It provides proof of possesion of a key and provides information to enable the application to do authentication.

SCTP/DTLS is very similar to HTTPS in this aspect. HTTPS clearly states how to do the identity authentication: The server certificate MUST contains a domain name in a subjectAltName field of type DNSname. The application MUST check that the subjectAltName field of type DNSname is equal to the host name.

Would it be possible to give more details to the implementation here. These are things that has to be done. Right now it is up to every implementation/deployment to specify this.

Could we say that in case X.509 certificates are used, the client and server identity SHALL be stored in subjectAltName as DNSname or IPaddress and that the other party MUST check that the received identity is within a small restricted set of identities.

In Section 4.1:

"The fragmentation works similar as the DTLS fragmentation of handshake messages."

Daria Ivanova noted that this comparison is not accurate. It should be rewritten to actually describe the used mechanism. This is a companion issue to #82 which is the reassembly description part needing improved.

The current SCTP API spec have limited a user message to be authenticated by a single key. This leads to a limitation in that a single large user message needs to finish before more than one SCTP-AUTH key update happens. This results in a practical limitation of how big user messages that can be supported. This practical limits results in user messages that are much smaller than the theoretical upper limit. So depending on how often one target renegotiation, and what key life time one has on the used ciphers. The desire to rekey for PFS reasons are likely more restricting than the HMAC-SHA256 key life time.

Also for DTLS 1.3 key update the document is not clear if it can support multiple key epoch within a single user messages.

So at a minimal this limitation needs to be made clear. Alternatively we can enable user messages to use multiple epoch to support large user messages or user messages used as byte streams. However, that will likely come at a higher cost in implementation and tighter integration between DTLS and SCTP. So this likley need more investigation and discussion.

The current text on parallel DTLS connections do allow DTLS 1.2 Renegotiation However, we should consider forbidding the use of DTLS 1.2 renegotiation for several reasons.

• Creates potential race condition between initiating new DTLS Connection and a renegotiation
• With renegotiation we end up two different cases that creates SCTP-AUTH keys and the process needs to ensure that both sides installs the keys with the same key-ids or things will fail.
• The renegotiation have draining requirement that works worse than new DTLS connection as there are no explicit indication when the old epoch has been fully delivered, and thus the key can be retired which increases exposure.
• DTLS 1.2 Renegotiation is often disabled in implementations due to security concerns in non-mutual authenticated usages.

As we have a situation where a new DTLS connection can fulfill all that DTLS 1.2 renegotiation can do and it works for both DTLS 1.2 and 1.3 it would be simpler to use only new DTLS connections and not allow DTLS renegotiation to avoid the above issues.

We need to consider if the API specification that is currently is at all useful with the updated.
Secondly, if a more high level API Consideration for potentially missing functionality is more useful so that those that both future socket API specifications and proprietary APIs can consider what functionality simplifies supporting this specification.

So the partial delivery of user messages will create situation where some DTLS records in a sequence of a protected used message will not be delivered in its entirety. Thus, I think we need to add some words on how one handles this situation.

First, there is the question of ensuring that any buffer containing data that contains partial DTLS record are flushed.
Secondly, if one have a partial delivery API towards the application, then that needs to get a error indication that this user message was not delivered in its entirety.

These issues are much more significant for this spec than it was for RFC 6083, where the DTLS record needed to be complete to decrypt and pass integrity. In this case one or more DTLS records from the start might be delivered.

https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc8446bis-01

Removes "master" in TLS 1.2 and 1.3. This will very likey be the future terminology so we should probably use the term "main secret".

Based on that we don't have feature parity between DTLS 1.2 and 1.3 I think the Version of DTLS section needs to be rewritten a bit to make it clear that this spec is defining usage of both and maybe have a upfront discussion of the limitations?

SCTP stacks can handle large received messages. There is no requirement to use the SocketAPI, although we make sure things can be implemented using it...

We may need text for the fact that DTLS 1.2 and 1.3 is limited to 65535 rekeyings and then the DTLS assocation needs to be terminated and restarted in that case. This produces a limited association lifetime that may need to be made explicit in the document.

@tuexen 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".

Renegotiation seems to be disables in a lot of libraries.

https://security.stackexchange.com/questions/24554/should-i-use-ssl-tls-renegotiation/230327#230327

Might be ok as long as RFC 5746 is used,

https://tools.ietf.org/html/rfc5746

but there are still attacks and weaknesses remaining. Not sure how severe the attacks are. But that the feature seems to be disables by default is quite bad. Such corners of the code base is not reviewed much and might contain other bugs and implementation weaknesses....

To allow refreshing the keys.

The specification is supporting both DTLS 1.2 and DTLS 1.3. Do we need a discussion how an client or server can negotiate which DTLS version to use and are there a downgrade risk here. And can that be handled in other ways that having the ULP mandate particular versions?

1. Only SHA-1 is mandatory to implement.
2. SHA-1 can't be disabled via the socket API for the algorithm requested to be used by the peer.
3. The AUTH negotiation relies on an acceptable mandatory to implement algorithm.
4. There is no socket option to query which algorithm is used to send AUTH chunks.
5. What about SHA-384 and SHA-512?

1.-3. could be addressed by requiring that SCTP AUTH used SHA-256 instead of SHA-1 as mandatory to implement. 4. Can easily be addressed by adding another socket option. It would be nice to address 5., but that is not necessary.

If the peer replies with an INIT-ACK not containing all DTLS/SCTP
Mandatory Options, the Client can decide to keep on working with
RFC 6083 fallaback, plain data only, or to ABORT the association.

How does this work? If the RANDOM, CHUNKS, or HMAC-ALGO parameter is missing, RFC 6083 does not work. So the only possibility is that ADAPTATION-LAYER-INDICATION is
missing or only SHA-1 is offered. That would mean RFC 6083 is used in combination with DTLS 1.2 or DTLS 1.3. I would vote for ABORTing. In the other cases, aren't we providing a way for downgrade attacks (SHA-256 -> SHA-1)?

Why is

For an RFC 6083 client it is likely that the preferred HMAC-ALGO indicates SHA-1.

true? RFC 6083 does not make a statement...

The procedures of Section 4.2.1 of [I-D.ietf-tls-dtls13] are irrelevant. When receiving DTLS packets using epoch n, no DTLS packets from earlier epochs are received.

From a parallel stream perspective I think there exist a probability that the DTLS connection will be asked to handle DTLS records out of order and over epoch boundaries.

In general I think we should shorten Section 4.9, and also as we are not using this procedures, should the section saying don't use these rather be in Section 3?

This document defines a maximum message size SCTP parameter to allow peers to indicate some limitations in the receiver implementation. Currently this is defined in a DTLS/SCTP specific way. However, it appears that this could be a parameter that could be generalized and thus possible one should work to ensure that the parameter is not specific to DTLS/SCTP and instead can be used by other usages to indicate limitations.

Let us discuss if it would make sense to generalize this, or keep it DTLS/SCTP specific.

"The DTLS Connection ID SHOULD NOT be negotiated (Section 9 of [I-D.ietf-tls-dtls13]). If DTLS 1.3 is used, the length field MUST NOT be omitted and a 16 bit sequence number SHOULD be used."

Can this be rewritten to no use double negative form. "the length field MUST NOT be omitted" -> the length field MUST be included"?

DTLS 1.2 (from RFC 5246):
"An upper limit of 24 hours is suggested for
session ID lifetimes, since an attacker who obtains a master_secret
may be able to impersonate the compromised party until the
corresponding session ID is retired."

DTLS 1.3 (from RFC 8446):
"It is RECOMMENDED that
implementations place limits on the total lifetime of such keying
material; these limits should take into account the lifetime of the
peer's certificate, the likelihood of intervening revocation, and the
time since the peer's online CertificateVerify signature."

64-bit sequence numers should not be a problem as they require 2^32 records every second for 136 years to overflow. They also reset after KeyUpdate or renegotiation.

I assume DTLS/SCTP need to override the DTLS 1.2 lifetime of 24 hours.

Post-Handshake frequent client authentication is possible, just like in DTLS 1.2, but Post-Handshake server authentication is not possible.

Section 4.8 describes the epoch handling and relies on the methods described for example in Section 4.2.1 to avoid message loss within the DTLS layer. I don't think that this works. One reason is that it is assumed that after an MSL no messages from an older epoch can be received anymore. How can this be concluded?

1. Even RFC 793 states for MSL: Arbitrarily defined to be 2 minutes.
2. For making sure that no TCP segments from an old TCP connection are in the network anymore, TCP waits twice as long.
3. We need to consider the time time-interval between the DTLS layer at the sending side passes the message to its lower layer and the DTLS layer at the receiving side get the message from its lower layer. When using DTLS/UDP and assuming that the UDP and IP layer do not buffer messages, this time interval can be approximated by the MSL. However when considering DTLS/SCTP, we also need to consider the time a message can be buffered in the SCTP layer. This can not be bound by an MSL.

Therefore I think we need to do the draining game also used for DTLS 1.0/SCTP. Or am I missing anything?

Use an adaptation layer indication

In Section 4.1 of -03 there is this sentence:

"Thus, it is RECOMMENDED to not use the zero length CID values and instead use a single common length for the CID values."

Daria commented that to avoid the implementation handling of zero-length case why not mandate that non-zero MUST be used?

I think that is a valid idea, especially as non-zero is not suitable and only result in extra issues in this usage.

For DTLS messages that are not protected ULP user messages, it is not clear which PPID should be used in SCTP for these messages. @teiclap and I think using ppid=0 is fine for this as the DTLS/SCTP layer will be able to identify these messages based on the message itself.

We should also verify that it is clear the ULP protected messages shall use the PPID that was provided by the upper layer protocol.

"DTLS records of content type "application_data", which carries the protected user messages, SHOULD use multiple streams other than stream 0; they MAY use stream 0. On stream 0 protected user messages as well as any DTLS messages that aren't record protocol will be mixed, thus the additional head of line blocking can occur."

This text appear to be a poor way of saying. The ULP stream choice for a user message are to be maintained when the messages are protected by DTLS. However, the ULP could use Stream 0 for its messages, therefore could be a head of line blocking due to the DTLS conneciton messages when they are sent. Thus the ULP is RECOMMENDED to use other streams than Stream 0.

With the changes there might not in fact exist an clear limitation to user messages. Daria Ivanova asked if there was a reason for this limitation.

So there are no actual limitation of rekeying operations with the parallel DTLS connection solution. Thus there are no hard limit on SCTP association length.

The only reason I see for maintaining a 2^64-1 user message size restriction is to make it clear that you can assume that 64-bit pointers and offset and length fields in handling the data will be sufficient. 2^64 is also a very large number that are extremely unlikely to be consumed. At 1 Tbps it will take almost 4,7 years to transfer 2^64 bytes. And that is for a single user message in a single stream. So this utilizing SCTP like like some type of byte stream.

I think one alternative is to make it clear that there are no hard limit, but that implementations are not required to support user messages larger than 2^64-1 bytes.

DTLS 1.3 removed renegotiation and replaces it with symmetric Post-Handshake KeyUpdate.

KeyUpdate provides less security properties than rerunning Diffie-Hellman. This might be ok, but the properties are below what government requirements stipulate for IPsec.

KeyUpdate in DTLS 1.3 does not update the exporter_master_secret. Any update of keys for SCTP-AUTH needs to be done by adding some information to the exporter label.....

DATA chunks that are received before DTLS handshake will be silently discarded.

Needs to be changed.

• Why Fallback when the correct adaptation layer indication has been received, but the HMAC or CHUNKS parameter is not as expected. Shouldn't we handle this as a protocol violation? An old implementation will not send the adaptation layer indication...
• Should we describe what to do if the adaptation layer indication is received, but DTLS version 1.0 is indicated?

The draft is written to align with (D)TLS 1.3 behaviour. DTLS 1.2 do however have a different behaviour. DTLS 1.2 will soon be obsolete but likely needs to be supported short-time.

Section 6.1 of RFC 8446 explains the differences:

   Each party MUST send a "close_notify" alert before closing its write
   side of the connection, unless it has already sent some error alert.
   This does not have any effect on its read side of the connection.
   Note that this is a change from versions of TLS prior to TLS 1.3 in
   which implementations were required to react to a "close_notify" by
   discarding pending writes and sending an immediate "close_notify"
   alert of their own.  That previous requirement could cause truncation
   in the read side.  Both parties need not wait to receive a
   "close_notify" alert before closing their read side of the
   connection, though doing so would introduce the possibility of
   truncation.

Currently DTLS 1.3 key update procedure relies on a form of draining which is limiting and can impact the upper layer protocol application as they can't send new user messages during key update procedures.. Thus a better solution should be found.

Daria Ivanova noted some unclarity in the procedures around shutdown. This needs to be clarified and also the implementation implications are relevant. Using a worst case time as might be acceptable for the rekeying with parallel DTLS conencection are not acceptable during graceful shutdown as that will take 10 min then.

The application intiaties a shutdown request to the DTLS/SCTP layer.

1. DTLS/SCTP Flush its buffer and get any DTLS/SCTP layer buffered user data protected and sent to SCTP.
2. SCTP sends data and await SACK from peer to know all has been delivered. Then DTLS/SCTP layer can issue DTLS Close Notify.
3. DTLS/SCTP stack sends CLOSE_notify.
4. SCTP sends DTLS Close_notify to peer. Now the SCTP stack close can be initiated to get the SCTP stack into SHUTDOWN pending state.
5. When peer side get DTLS Close_Notify on the last DTLS connection, that is a signal for shutdown procedure.
6. Then the left does corresponding to 2-4.
7. SCTP association is shutdown.

So this needs to be clarified in document.

Daria Ivanova noted that there is a potential risk for a race condition between incomming DTLS handshake messages and the DTLS server in the implementations.

So this is clearly an implementation issue. From a protocol standpoint the SCTP server has been informed about the DTLS/SCTP adaptation layer usage and agreed to it. Thus, that implementation must be ready for DTLS handshake packets part of received user messages, even if the server instance has not yet brought the DTLS server instance up and is ready with all context.

So the question is if there is any need to note this protocol vs implementation detail in the draft?

So part of the discussion in #27 brought up the case of STARTTLS. I think that needs more consideration as due to even RFC 6083 requirement to have SCTP-AUTH, one can't move from a plain SCTP association to one with DTLS. Instead one actually need to create an association with the intent to use DTLS. So are there any point in attempting to support STARTTLS like for services that use TLS/TCP where it works.

This is not necessarily an issue for RFC6083bis, but it is likely good to have a discussion regarding the topic sooner rather than later. Deployment of DTLS 1.3 (still a draft) is several years behind TLS 1.3 but in the not-so-distant future, DTLS 1.2 should be phased out.

DTLS 1.3 is not suitable for semi-permanent connections required to be up and running for years. DTLS 1.3 removes the DTLS 1.2 renegotiation and does not replace the functionality. DTLS/SCTP relies heavily on DTLS 1.2 renegotiation. I think this needs to be fixed in DTLS 1.3 before DTLS 1.3 is suitable for semi-permanent connections. The TLS working group does likely not want renegotiation in DTLS 1.3. I see two ways forward.

1. A slimmed down post-Handshake "authentication and key exchange" that performs a Diffie-Hellman key exchange, updates the exporter_secret, and performs client and server authentication without renegotiation of any parameters (except the ephemeral keys and potentially new certs with the same identities).

2. Doing resumption in parallel with the existing connection together with post-handshake client authentication and post-handshake server authentication. Resumption performs a Diffie-Hellman key exchange and updates the exporter_secret. Post-handshake server authentication would have to be specified. With DTLS connectionID several connections can be sent over the same 5-tuple at the cost of 1 extra byte (note that the DTLS 1.3 record layer is significantly smaller than the DTLS 1.2 record layer). While resumption was not designed to be used in parallel with the original connection, I don’t think it is forbidden anywhere.

Li Yan commented on the TSVWG mailing list that backwards compatibility which really is fallback to RFC 6083 behavior needs to be better considered. Maybe the issue is that the description of this is not clear enough.

Propose that we look over the text and clarify.

From Li Yan:

It is better to add more description in section 4.1 in the current draft.
The description about how to reassemble the fragemented user message in the DTLS layer is not clear enough, and may cause confusion for readers.It is recommended to add further description about it.
For example：
On the receiving side, after getting the user_message’ from SCTP, DTLS makes use of the length field in the DTLS record header to decrypt the content of the first DTLS record to get m0, then m1......
The length field in DTLS record header is very import for decryption of each DTLS record.According to the length field, the receiving side knows the end of decryption of one DTLS record and the start of the next DTLS record.
Detemining which DTLS record is the last one needs to use the overall length of the user_message’ from SCTP to minus the lenght of each DTLS record.
After the last DTLS record is decrypted, the user_message is reassembled: user_message = m0 | m1 | m2......