> I have not looked at various PQC key exchanges, but possibilities for partial processing are likely limited if existent at all.
That's not the case - see the reference to SPHINCS and McEliece above. > Any existing implementations will certainly not support it. An experimental branch of Mbed TLS does already support it. It provides a common interface between record and HS layer which supports gradual processing. ________________________________ From: TLS <tls-boun...@ietf.org> on behalf of Ilari Liusvaara <ilariliusva...@welho.com> Sent: Monday, November 8, 2021 6:28 PM To: tls@ietf.org <tls@ietf.org> Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing On Mon, Nov 08, 2021 at 04:08:51AM -0800, Eric Rescorla wrote: > On Mon, Nov 8, 2021 at 3:58 AM Hanno Becker <hanno.bec...@arm.com> wrote: > > > > > 'Small tweak in wording': Can we say "Where possible, implementations > > > > MAY process data immediately rather than buffering it"? What I think about possibilities of partial record processing for each message type: Client hello (DTLS 1.3): If PQC is used, fragmentation is likely. Cookie is not guaranteed to be in first fragment, even if fragment sizes are reasonable (cookie is extension, and not header field like in DTLS 1.2). PQC keys are likely to be major part of mesage size, and everything else probably is in first and last fragments. I have not looked at various PQC key exchanges, but possibilities for partial processing are likely limited if existent at all. Any existing implementations will certainly not support it. Server hello (DTLS 1.3): As in client hello. Certificate verify (DTLS 1.3): If full-PQC is used, fragmentation is virtually unavoidable (low level Falcon might avoid it, but poses challenges for MCUs due to its use of FPU). Virtually the entiere message is signature. Notes about partial processing of keys apply here too. Certificate (DTLS 1.2): There are signature algorithms that can not do anything without key, message and signature. However, because DTLS 1.2 requires chain to be ordered, it is possible to process the chain with two or one-and-half (half being certificate up to the SPKI field) certificate window. Certificate (DTLS 1.3): The same trick as in DTLS 1.2 will not work unless one ignores SHOULD and requires ordered chain (ignoring that requirement is also great for reducing probability of serious security issues). For all other messages, I think those messages either are small enough for fragmentation to be unlikely, or be very obscure (e.g., DTLS 1.2 supplemental_data). In summary, I think the only real oppurtunity is Certificate message, if the chain is required to be ordered (which needs ignoring SHOULD in DTLS 1.3; but there are also other good reason for doing so). > > > > I might have misunderstood, I thought you'd confirmed that buffering only > > fragments aligning or overlapping with the current buffer would work OK -- > > it does in the examples you mentioned, I think. > > > > It will eventually work, but I believe it will cause extremely poor > performance. On causing poor performance, some stuff from ACK mechanism: Suppose side attacker sends numerious empty unencrypted ACK packets. It seems like if implementation is not careful, it could immediately resend its entiere first flight (there is holddown for sender, but seemingly not for receiver). This could lead into at least two problems: - Excessive network usage from all the spurious retransmits. Server's first flight is a lot larger than empty ACK, especially if one can pile many empty ACKs into a single packet. - Excessive memory usage from tracking entries for all the resent records. As for ACK holddown, it would seem to me that the following algorithm: - When receiving first fragment of flight, start a timer. - When trailing edge of flight reassembly makes progress, reset the timer. - If flight completes, cancel timer. - When timer expires, send ACK. Would allow much faster timeouts, as it is limited by dispersion, which can be orders of magnitude below RTT. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls 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
