On Sun, Nov 7, 2021 at 2:27 PM Hanno Becker <hanno.bec...@arm.com> wrote:
> > So absent serious flaws, I think we should make as few changes as
> possible
>
> Understood and agreed, though if a small tweak in wording gets all cases
> covered we care about,
> let's do it now.
>
> > Yes, the current text which requires you to buffer, ...
>
> That existing text does not allow the mentioned simplified reassembly
> scheme though, does it?
>
No. As I indicated in my earlier, email, while that scheme may technically
work, it is potentially highly inefficient and I think we should discourage
it.
> ... with an addendum such as "Implementations may process in-order data
> rather than merely buffering it.
>
> 'Small tweak in wording': Can we say "Where possible, implementations MAY
> process data immediately rather than buffering it"?
>
That would be fine with me.
-Ekr
> ------------------------------
> *From:* Eric Rescorla <e...@rtfm.com>
> *Sent:* Sunday, November 7, 2021 10:16 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'd like to preface my comments by observing that we are in AUTH48 for
> DTLS, and it's only being held up on resolving #254
> (and maybe #247 which I just saw). So absent serious flaws, I think we
> should make as few changes as possible, especially
> because if what you propose turns out to be fine we can just do an update
> without changing the protocol on the wire.
>
>
> On Sun, Nov 7, 2021 at 1:58 PM Hanno Becker <hanno.bec...@arm.com> wrote:
>
> > Re (2), I think we could just add a sentence saying that it was legal
> to process any in-order data immediately.
>
> I wouldn't want to restrict that to in-order data, but keep the door open
> for e.g. crypto implementations
> which can even process data out of order. E.g. process the beginning of a
> {Client,Server}Hello in-order to the point where the KeyShare extension
> starts, and then -- if it makes sense for the scheme in question -- process
> the actual KeyShare content out of order. Whether that complexity would
> ever be worth the effort is hard to foresee, but I think we shouldn't
> rule it out from the start.
>
>
> This is generally very difficult because of the encoding. As noted above,
> we can always allow this later without any change to the wire, but I don't
> think we should change the text not.
>
>
>
> > > 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.
>
> Do you have some text in mind?
>
>
> Yes, the current text which requires you to buffer, with an addendum such
> as.
> "Implementations may process in-order data rather than merely buffering
> it."
>
>
>
> > ... 1. Guaranteeing eventual delivery.
>
> That sounds like a good term to me, so how about:
>
> A DTLS implementation MUST process handshake messages corresponding to
> the next
> expected handshake message sequence number in a way that guarantees
> eventual delivery
> to the respective handshake state handler. For example, this can be
> achieved through
> reassembling the handshake message from buffered fragments prior to
> processing, or
> gradual processing of fragments (if possible), or a combination of both.
>
>
> This doesn't accomplish the goal of having a clear set of behaviors which
> endpoints can engage in. It's just a requirement.
>
> -Ekr
>
>
> ------------------------------
> *From:* Eric Rescorla <e...@rtfm.com>
> *Sent:* Sunday, November 7, 2021 9:36 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
>
>
>
> On Sun, Nov 7, 2021 at 1:32 PM Hanno Becker <hanno.bec...@arm.com> wrote:
>
> > 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 shouldn't have said "aligned" but "overlap": Fragments would be
> considered precisely if they have nontrivial overlap with the existing
> buffered contiguous fragment, and then used to extend this fragment This
> practically means that the buffer is extended either at the front or back.
> So if, say, in your example, the second 1000 goes through, and in the
> retransmit, the first and second 700 go through, then the first will be
> dropped because it doesn't overlap with (1000,2000), while the second 700
> will be kept and extend the reassembly buffer to (700,2000). That's a valid
> strategy, isn't it?
>
>
> I believe that will work, yes.
>
> -Ekr
>
> ------------------------------
> *From:* Eric Rescorla <e...@rtfm.com>
> *Sent:* Sunday, November 7, 2021 9:14 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
>
>
>
> 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.
>
> 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.
>
> 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.
>
> 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
