Draft: draft-ietf-tls-dtls13

Commentary: here is another try at this . 
 I did not realize that the intent of your text was to allow out of order processing . IMO that 's off the fairway and we should n't allow that any more than we let you reach into the TCP stack and pull out forward messages . 
 I do n't think the comparison with TCP works - the handshake protocol is internal . We should not force a particular implementation unless there 's good reason to . In this case , as explained on the list , there 's potential merit of allowing out of order processing of very large handshake messages with known structure . What 's your opinion ? 
 Again , this is a last minute change during Auth48 , so the bar is much higher than " potential merit " 
 This is n't motivated by security - related reasons like , so I agree with that this does not raise to the level of an AUTH48 change . I propose we land this PR and close out . 
 Thanks for considering this in the first place . As I understood since this does not impact the wire - format , we can revisit once the RFC has been finalized ? 
 Once the RFC is finalized , it 's final . Changes can be requested via the , or via a new document that updates the RFC in question . 
 Ok , thank you . I was referring to comment on the list 
 Yes . What I was saying is that you could just write an RFC that said " you can process out of order " 
 corresponding to the next expected handshake message sequence number , it MUST buffer it until it has the entire handshake message . As discussed in The spec mandates buffering all handshake fragments , but some implementations ( e.g.  ) choose to implement simpler reassembly schemes . It has been argued by Ekr that such should be discouraged because they are n't efficient . On the other hand , as   remarks , the choice of reassembly mechanism is n'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 is n'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 mentioned on the list , I do n't like the in - order qualification . I agree it 's debatable whether there will be cases where it makes sense to process data out of order , but ( see list again ) it is not inconceivable , and I see no reason to exclude this here . I would therefore prefer to drop the in - order qualification .
Mailing list commentary: Hi all , Both DTLS 1.2 and DTLS 1.3 mandate : Can someone explain the underlying rationale ? It seems that in the context of very large key material or certificate chains ( think e.g. PQC ) , gradual processing of handshake messages ( where possible ) is useful to reduce RAM usage . Is there a security risk in doing this ? It would also be useful for stateless handling of fragmented ClientHello messages . I ' m sure this was discussed before but I do n't remember where and who said it , but a server implementation could peek into the initial fragment of a ClientHello , check if it contains a valid cookie , and if so , allocate state for subsequent full reassembly . That would n't be compliant with the above MUST , though , as far as I understand it . Thanks ! Hanno IMPORTANT NOTICE : The contents of this email and any attachments are confidential and may also be privileged . If you are not the intended recipient , please notify the sender immediately and do not disclose the contents to any other person , use it for any purpose , or store or copy the information in any medium . Thank you .
Paragraph (version A):
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.  DTLS
implementations MUST be able to handle overlapping fragment ranges.
This allows senders to retransmit handshake messages with smaller
fragment sizes if the PMTU estimate changes.  Senders MUST NOT change
handshake message bytes upon retransmission.  Receivers MAY check
that retransmitted bytes are identical and SHOULD abort the handshake
with an "illegal_parameter" alert if the value of a byte changes.
Paragraph (version B):
When a DTLS implementation receives a handshake message fragment
corresponding to the next expected handshake message sequence number,
it MUST process it, either by buffering it until it has the entire
handshake message or by processing any in-order portions of the
message.  DTLS implementations MUST be able to handle overlapping
fragment ranges.  This allows senders to retransmit handshake
messages with smaller fragment sizes if the PMTU estimate changes.
Senders MUST NOT change handshake message bytes upon retransmission.
Receivers MAY check that retransmitted bytes are identical and SHOULD
abort the handshake with an "illegal_parameter" alert if the value of
a byte changes.