On Sun, Nov 7, 2021 at 12:10 PM Hanno Becker <hanno.bec...@arm.com> wrote:
> > 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 actually do not believe that this will work correctly in all cases. Consider the case where we have a 2K message where the peer sends: - 1000, 1000 ... som retransmits <backs off the MTU> - 700, 700, 600 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. > I'm not sure how to operationalize this. I believe we should provide simple guidance such that a compliant implementation works with another compliant implementation in a reasonably finite time. ISTM that there are two separable issues here: 1. Guaranteeing eventual delivery. 2. Allowing incremental processing. I believe that (1) requires that you buffer out of order fragments. S 5.8.2 and S 5.8.3.permits implementations to send a flight all at once provided it's < 10 flights. Imagine the following situation: 1. A handshake message which must be fragmented, say 2KB. 2. A network which reorders packets so that they are received in reverse order. In this case, an implementation which always discards out of order records will require N round trips in order to receive the entire flight. This doesn't seem good. For this reason, I think we should strongly encourage/require buffering. Re (2), I think we could just add a sentence saying that it was legal to process any in-order data immediately. -Ekr ------------------------------ > *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> 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> > *Sent:* Saturday, November 6, 2021 1:56 PM > *To:* Achim Kraus <achimkr...@gmx.net>; Hanno Becker <hanno.bec...@arm.com > > > *Cc:* tls@ietf.org <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> On Behalf Of Achim Kraus > Sent: Saturday, November 6, 2021 6:22 AM > To: Hanno Becker <hanno.bec...@arm.com> > Cc: 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 > > > > // > > > > ---------------------------------------------------------------------- > > -- > > *From:* Achim Kraus <achimkr...@gmx.net> > > *Sent:* Saturday, November 6, 2021 7:36 AM > > *To:* Hanno Becker <hanno.bec...@arm.com> > > *Cc:* tls@ietf.org <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 > >> 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 > 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 > > 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
