Hi Hanno, > Can someone explain the underlying rationale?
I can only guess, that this makes the processing of the handshake messages equal to TLS. So it's separating the layers (record layer - handshake layer). > 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? I'm not sure, if such an approach really pays off. Consider, that sometimes the fragments may be reordered or single fragments are missing. Under such conditions, collecting the fragments is a solution, which makes receiving the complete message more probable. For me, if someone decides to go with x509, then please provide the RAM. That RAM may only be used temporary, later it may be used for application payload processing. So, I don't think this should be really an issue. > It would also be useful for stateless handling of fragmented > ClientHello messages. I'm sure this was discussed before but > I don'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 wouldn't be compliant with the above MUST, though, > as far as I understand it. How do you want to calculate the cookie. According: https://datatracker.ietf.org/doc/html/rfc6347#section-4.2.1 Cookie = HMAC(Secret, Client-IP, Client-Parameters) So, which Client-Parameters are included? For me, stateless processing would require to challenge the first fragment (0) only, though otherwise, I can't see, how that could work stateless. If the cookie is build only for the first fragment, you must ensure, that the Client-Parameters, which may be shifted by the cookie to the next fragment, are excluded from the cookie's Client-Parameters, otherwise you will not be able to do a stateless check of first fragment with cookie. But that all seems for me to be not mentioned nor intended by RFC6347. Therefore I would recommend, to use less Client-Parameters to make the ClientHello small. That's one good reason for RFC7252 to define a mandatory set, clients can rely on. best regards Achim Kraus Am 05.11.21 um 20:14 schrieb Hanno Becker:
Hi all, Both DTLS 1.2 and DTLS 1.3 mandate: > 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. 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 don'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 wouldn'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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
