When a DTLS implementation receives a handshake message fragment
corresponding to the next expected handshake message sequence number,
it MUST buffer it until it has the entire handshake message.
As discussed in https://mailarchive.ietf.org/arch/msg/tls/PLK-EW_bWIXV74nm_8gSHwu5cqk/: The spec mandates buffering all handshake fragments, but some implementations (e.g. GnuTLS) choose to implement simpler reassembly schemes. It has been argued by Ekr that such should be discouraged because they aren't efficient. On the other hand, as Rich Salz remarks, the choice of reassembly mechanism isn't something the peer could tell (the effects of poor reassembly performance are more retransmissions, which could also be due to poor network reliability), so it does feel like we're overspecifying things here. Weakening the MUST to a SHOULD isn't good either as it allows dropping fragments altogether. There's a tension between the desire for a concrete operational guidance, which the current text clearly provides, and a more abstract formulation along the line of "implementations MUST use a reassembly scheme ensuring forward progress".
As suggested by Ekr, taking this off the mailing list and continuing discussion here.
To be clear: This has no bearing on the protocol itself, it's about how much implementation details the spec should enforce.
As discussed in https://mailarchive.ietf.org/arch/msg/tls/PLK-EW_bWIXV74nm_8gSHwu5cqk/: The spec mandates buffering all handshake fragments, but some implementations (e.g. GnuTLS) choose to implement simpler reassembly schemes. It has been argued by Ekr that such should be discouraged because they aren't efficient. On the other hand, as Rich Salz remarks, the choice of reassembly mechanism isn't something the peer could tell (the effects of poor reassembly performance are more retransmissions, which could also be due to poor network reliability), so it does feel like we're overspecifying things here. Weakening the MUST to a SHOULD isn't good either as it allows dropping fragments altogether. There's a tension between the desire for a concrete operational guidance, which the current text clearly provides, and a more abstract formulation along the line of "implementations MUST use a reassembly scheme ensuring forward progress".
As suggested by Ekr, taking this off the mailing list and continuing discussion here.
To be clear: This has no bearing on the protocol itself, it's about how much implementation details the spec should enforce.