> Without thinking it through completely, I think it would probably be safe to > add something about gradual processing, but your text seems to allow throwing > it away, which seems undesirable.
Hm yes. On the other hand, some implementations might deliberately discard some fragments to keep the reassembly logic simple: For example (please correct me if I got it wrong), I think GnuTLS maintains a _contiguous_ reassembly buffer rather than a reassembly bitmap, and only buffers a new fragment if it aligns with the existing buffer at the front or back. This works fine, and yet it's strictly speaking non-compliant, which IMO shouldn't be the case. I guess what we want to express is that implementations must use some algorithm ensuring forward progress (after taking into account the retransmission mechanism). How about something like this - not sure if "forward progress" is precise enough, but anyway: A DTLS implementation MUST process handshake message fragments corresponding to the next expected handshake message sequence number in a way that guarantees forward progress. For example, this can be achieved through reassembling the handshake message from buffered fragments, gradual processing of fragments (if possible), or a combination of both. ________________________________ From: Eric Rescorla <e...@rtfm.com> Sent: Saturday, November 6, 2021 8:57 PM To: Hanno Becker <hanno.bec...@arm.com> Cc: Scott Fluhrer (sfluhrer) <sfluh...@cisco.com>; Achim Kraus <achimkr...@gmx.net>; tls@ietf.org <tls@ietf.org> Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing I'm trying to recall why that text exists. I think the idea wasn't that you actually couldn't start processing it but that you had to keep it rather than discard it. Without thinking it through completely, I think it would probably be safe to add something about gradual processing, but your text seems to allow throwing it away, which seems undesirable. -Ekr On Sat, Nov 6, 2021 at 12:36 PM Hanno Becker <hanno.bec...@arm.com<mailto:hanno.bec...@arm.com>> wrote: > There are a number of postquantum algorithms (e.g. NTRU, Falcon, Dilithium) > that require considerably smaller key shares/signatures - we're talking about > the 1k-2k range. It would sounds reasonable that an MCU implementation might > want to consider those algorithms, if they are more suitable for their > deployment model. I agree that this seems most likely, but it's hard to foresee all contexts in which [D]TLS 1.3 might be deployed. I'm uncomfortable wording the standard in a way that renders potential use cases requiring the use of larger schemes and gradual processing non-compliant. ________________________________ From: Scott Fluhrer (sfluhrer) <sfluh...@cisco.com<mailto:sfluh...@cisco.com>> Sent: Saturday, November 6, 2021 1:56 PM To: Achim Kraus <achimkr...@gmx.net<mailto:achimkr...@gmx.net>>; Hanno Becker <hanno.bec...@arm.com<mailto:hanno.bec...@arm.com>> Cc: tls@ietf.org<mailto:tls@ietf.org> <tls@ietf.org<mailto:tls@ietf.org>> Subject: RE: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing There are a number of postquantum algorithms (e.g. NTRU, Falcon, Dilithium) that require considerably smaller key shares/signatures - we're talking about the 1k-2k range. It would sounds reasonable that an MCU implementation might want to consider those algorithms, if they are more suitable for their deployment model. -----Original Message----- From: TLS <tls-boun...@ietf.org<mailto:tls-boun...@ietf.org>> On Behalf Of Achim Kraus Sent: Saturday, November 6, 2021 6:22 AM To: Hanno Becker <hanno.bec...@arm.com<mailto:hanno.bec...@arm.com>> Cc: tls@ietf.org<mailto:tls@ietf.org> Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing Hi Hanno, > Note also that in the context of Post-Quantum Crypto, we're sometimes > > talking about key material >100Kb - this is an issue for MCUs. I didn't say, this is impossible, it's more that in my opinion for DTLS 1.2 it doesn't pay off. Considering 100k, I guess, that will require a more general update of the RFCs, not just that MUST. For IoT it may be also valid, to assume that such large public keys will be shared ahead by other means. best regards Achim Am 06.11.21 um 09:18 schrieb Hanno Becker: > Hey Achim, > > Thanks for the quick reply! > > Actually, for TLS, you can do the same: Process handshake messages > piece by piece (ordered, this time), without full reassembly. I'm not > aware that the TLS spec forbids that, or does it? > > For Post-Quantum Crypto, streaming implementations of schemes with > very large key materials are a thing, see e.g. SPHINCS or McEliece [1]. > However, those are only of value for (D)TLS if the (D)TLS stack > forwards data to the handshake layer prior to full reassembly -- > again, both in TLS and DTLS. > > You're right that in DTLS the situation is even harder, because > fragments might be received out of order. But that doesn't mean > there's no way of potentially processing them out of order -- it very > much depends on the data. E.g. if you receive a huge matrix which > you'd like to perform a matrix-vector multiplication with, you can do > that entry by entry -- so long as you know the offset of the data you > received, which you do of course. > > Note also that in the context of Post-Quantum Crypto, we're sometimes > talking about key material >100Kb - this is an issue for MCUs. > > I think a MUST like this should have a justification. If there's none, > then IMO it should be left out for the benefit of implementation flexibility. > > Cheers, > Hanno > > [1]: > > Johannes Roth and Evangelos Karatsiolis and Juliane Krämer > > "Classic McEliece Implementation with Low Memory Footprint", > https://eprint.iacr.org/2021/138 <https://eprint.iacr.org/2021/138>, > Cryptology ePrint Archive: Report 2021/138 - Classic McEliece > Implementation with Low Memory Footprint - IACR > <https://eprint.iacr.org/2021/138> > Cryptology ePrint Archive: Report 2021/138. Classic McEliece > Implementation with Low Memory Footprint. Johannes Roth and Evangelos > Karatsiolis and Juliane Krämer eprint.iacr.org<http://eprint.iacr.org> > > // > > ---------------------------------------------------------------------- > -- > *From:* Achim Kraus <achimkr...@gmx.net<mailto:achimkr...@gmx.net>> > *Sent:* Saturday, November 6, 2021 7:36 AM > *To:* Hanno Becker <hanno.bec...@arm.com<mailto:hanno.bec...@arm.com>> > *Cc:* tls@ietf.org<mailto:tls@ietf.org> <tls@ietf.org<mailto:tls@ietf.org>> > *Subject:* Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to > processing 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 > <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<mailto:TLS@ietf.org> >> https://www.ietf.org/mailman/listinfo/tls > <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<mailto: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<mailto: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
