Subject: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing

From: Hanno Becker <[email-masked]>
Date: Fri, 5 Nov 2021 19:14:49 +0000

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.

---

From: Achim Kraus <[email-masked]>
Date: Sat, 6 Nov 2021 08:36:53 +0100

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).

 > 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.

 > 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:
>  > 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.
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Hanno Becker <[email-masked]>
Date: Sat, 6 Nov 2021 08:18:50 +0000

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,
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 <[email-masked]>
Sent: Saturday, November 6, 2021 7:36 AM
To: Hanno Becker <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing

Hi Hanno,

best regards
Achim Kraus

---

From: Hanno Becker <[email-masked]>
Date: Sat, 6 Nov 2021 10:12:11 +0000

Concretely: Are there reservations towards replacing

> MUST buffer it until it has the entire handshake message.

by

> corresponding to the next expected handshake message sequence number,
> it is RECOMMENDED that it buffers it until it has the entire handshake message.

in the DTLS 1.3 draft?

Happy to file a PR if not.

Regards,
Hanno
________________________________
From: TLS <[email-masked]> on behalf of Hanno Becker <[email-masked]>
Sent: Saturday, November 6, 2021 8:18 AM
To: Achim Kraus <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing

Hey Achim,

Cheers,
Hanno

[1]:

Hi Hanno,

best regards
Achim Kraus

---

From: Achim Kraus <[email-masked]>
Date: Sat, 6 Nov 2021 11:21:44 +0100

Hi Hanno,

 > 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:
> 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 <[email-masked]>
> *Sent:* Saturday, November 6, 2021 7:36 AM
> *To:* Hanno Becker <[email-masked]>
> *Cc:* [email-masked] <[email-masked]>
> *Subject:* Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to
> processing
> Hi Hanno,
>
>   > 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.
>
> <https://datatracker.ietf.org/doc/html/rfc6347#section-4.2.1>
>
>>  > When a DTLS implementation receives a handshake message fragment
> <https://www.ietf.org/mailman/listinfo/tls>
>>
>

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Sat, 6 Nov 2021 13:56:38 +0000

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 <[email-masked]> On Behalf Of Achim Kraus
Sent: Saturday, November 6, 2021 6:22 AM
To: Hanno Becker <[email-masked]>
Cc: [email-masked]
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:
> 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.
>
> 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.
>
> 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]:
>
> Karatsiolis and Juliane Krämer eprint.iacr.org
>
> //
>
> processing Hi Hanno,
> missing. Under such conditions, collecting the fragments is a 
> solution, which makes receiving the complete message more probable.
> application payload processing. So, I don't think this should be 
> really an issue.
>
> otherwise you will not be able to do a stateless check of first 
> fragment with cookie.
>
>>it  MUST buffer it until it has the entire handshake message.
>>
>> 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.
>> 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 
>> 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.
>>
> 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.

---

From: Hanno Becker <[email-masked]>
Date: Sat, 6 Nov 2021 19:35:24 +0000

> 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 reasonabl…

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) <[email-masked]>
Sent: Saturday, November 6, 2021 1:56 PM
To: Achim Kraus <[email-masked]>; Hanno Becker <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: RE: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing

-----Original Message-----
From: TLS <[email-masked]> On Behalf Of Achim Kraus
Sent: Saturday, November 6, 2021 6:22 AM
To: Hanno Becker <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing

Hi Hanno,

best regards
Achim

Am 06.11.21 um 09:18 schrieb Hanno Becker:
> certificate

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 6 Nov 2021 13:57:40 -0700

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 <[email-masked]> 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.
>
> ------------------------------
> *From:* Scott Fluhrer (sfluhrer) <[email-masked]>
> *Sent:* Saturday, November 6, 2021 1:56 PM
> *To:* Achim Kraus <[email-masked]>; Hanno Becker <[email-masked]
> >
> *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.
>
> 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
>
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.

---

From: Hanno Becker <[email-masked]>
Date: Sun, 7 Nov 2021 20:10:13 +0000

> 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 <[email-masked]>
Sent: Saturday, November 6, 2021 8:57 PM
To: Hanno Becker <[email-masked]>
Cc: Scott Fluhrer (sfluhrer) <[email-masked]>; Achim Kraus <[email-masked]>; [email-masked] <[email-masked]>
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

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) <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, November 6, 2021 1:56 PM
To: Achim Kraus <[email-masked]<mailto:[email-masked]>>; Hanno Becker <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: RE: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing

-----Original Message-----
From: TLS <[email-masked]<mailto:[email-masked]>> On Behalf Of Achim Kraus
Sent: Saturday, November 6, 2021 6:22 AM
To: Hanno Becker <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing

Hi Hanno,

best regards
Achim

Am 06.11.21 um 09:18 schrieb Hanno Becker:
> Karatsiolis and Juliane Krämer eprint.iacr.org<http://eprint.iacr.org>
>
> //
>
> *From:* Achim Kraus <[email-masked]<mailto:[email-masked]>>
> *To:* Hanno Becker <[email-masked]<mailto:[email-masked]>>
> *Cc:* [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
>> [email-masked]<mailto:[email-masked]>

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 7 Nov 2021 13:14:46 -0800

On Sun, Nov 7, 2021 at 12:10 PM Hanno Becker <[email-masked]> 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.
>

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

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 <[email-masked]>
> *Sent:* Saturday, November 6, 2021 8:57 PM
> *Cc:* Scott Fluhrer (sfluhrer) <[email-masked]>; Achim Kraus <
> [email-masked]>; [email-masked] <[email-masked]>
> 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.
>

---

From: Hanno Becker <[email-masked]>
Date: Sun, 7 Nov 2021 21:31:51 +0000

> I actually do not believe that this will work correctly in all cases. Consider the case where we have a 2K message where

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?
________________________________
From: Eric Rescorla <[email-masked]>
Sent: Sunday, November 7, 2021 9:14 PM
To: Hanno Becker <[email-masked]>
Cc: Scott Fluhrer (sfluhrer) <[email-masked]>; Achim Kraus <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing

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'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.

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.

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 <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, November 6, 2021 8:57 PM
To: Hanno Becker <[email-masked]<mailto:[email-masked]>>
Cc: Scott Fluhrer (sfluhrer) <[email-masked]<mailto:[email-masked]>>; Achim Kraus <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing

-Ekr

-----Original Message-----
From: TLS <[email-masked]<mailto:[email-masked]>> On Behalf Of Achim Kraus
Sent: Saturday, November 6, 2021 6:22 AM
To: Hanno Becker <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing

Hi Hanno,

best regards
Achim

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 7 Nov 2021 13:36:47 -0800

On Sun, Nov 7, 2021 at 1:32 PM Hanno Becker <[email-masked]> wrote:

> 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

> *Sent:* Sunday, November 7, 2021 9:14 PM
> I'm not sure how to operationalize this. I believe we should provide
> simple guidance such that a compliant implementation works
> 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

---

From: Hanno Becker <[email-masked]>
Date: Sun, 7 Nov 2021 21:58:07 +0000

> 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.

> 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?

> ... 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.

Sent: Sunday, November 7, 2021 9:36 PM

-Ekr

- 1000, 1000
... som retransmits
<backs off the MTU>
- 700, 700, 600

-Ekr

-Ekr

-----Original Message-----
From: TLS <[email-masked]<mailto:[email-masked]>> On Behalf Of Achim Kraus
Sent: Saturday, November 6, 2021 6:22 AM
To: Hanno Becker <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing

Hi Hanno,

best regards
Achim

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 7 Nov 2021 14:16:02 -0800

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 <[email-masked]> wrote:

> > Re (2), I think we could just add a sentence saying that it was legal
> to process any in-order data immediately.
>
> 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.

> simple guidance such that a compliant > implementation works with another
> compliant implementation in a reasonably finite time.
>

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."

>   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

> *Sent:* Sunday, November 7, 2021 9:36 PM

---

From: Hanno Becker <[email-masked]>
Date: Sun, 7 Nov 2021 22:27:06 +0000

> 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?

> ... 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"?

Sent: Sunday, November 7, 2021 10:16 PM

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.

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.

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."

This doesn't accomplish the goal of having a clear set of behaviors which endpoints can engage in. It's just a requirement.

-Ekr

-Ekr

- 1000, 1000
... som retransmits
<backs off the MTU>
- 700, 700, 600

-Ekr

-Ekr

-----Original Message-----
From: TLS <[email-masked]<mailto:[email-masked]>> On Behalf Of Achim Kraus
Sent: Saturday, November 6, 2021 6:22 AM
To: Hanno Becker <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing

Hi Hanno,

best regards
Achim

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Nov 2021 03:47:10 -0800

> That existing text does not allow the mentioned simplified reassembly

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.

> '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

> *Sent:* Sunday, November 7, 2021 10:16 PM

---

From: Hanno Becker <[email-masked]>
Date: Mon, 8 Nov 2021 11:58:15 +0000

> That would be fine with me.

Great!

> 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.

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.

If we disregard this issue for now: Strictly speaking, we would need to weaken the existing buffering MUST anyway for the above addendum on immediate processing to make sense, no?

Is a SHOULD strong enough for you? Concretely:

When a DTLS implementation receives a handshake message fragment corresponding to the next expected handshake message sequence number, it SHOULD buffer it until it has the entire handshake message. Where possible, implementations MAY process data immediately rather than buffering it.

Sent: Monday, November 8, 2021 11:47 AM

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.

-Ekr

-Ekr

-Ekr

- 1000, 1000
... som retransmits
<backs off the MTU>
- 700, 700, 600

-Ekr

-Ekr

-----Original Message-----
From: TLS <[email-masked]<mailto:[email-masked]>> On Behalf Of Achim Kraus
Sent: Saturday, November 6, 2021 6:22 AM
To: Hanno Becker <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing

Hi Hanno,

best regards
Achim

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Nov 2021 04:08:51 -0800

On Mon, Nov 8, 2021 at 3:58 AM Hanno Becker <[email-masked]> wrote:

> > > 'Small tweak in wording': Can we say "Where possible, implementations
> MAY process data immediately rather than buffering 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.
>
> 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.

If we disregard this issue for now: Strictly speaking, we would need to
> weaken the existing buffering MUST anyway for the above addendum on
> immediate processing to make sense, no?
>
> SHOULD buffer it until it has the entire handshake message. Where
> possible, implementations MAY process data immediately rather than
> buffering it.
>

No, I don't think that this works. Because it allows you to simply drop it.
If you want to file an issue, I will attempt to draft some text.

-Ekr

> *Sent:* Monday, November 8, 2021 11:47 AM

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 8 Nov 2021 12:12:27 +0000

*   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.

To be clear, not something we need to address here and now.

---

From: Hanno Becker <[email-masked]>
Date: Mon, 8 Nov 2021 12:36:56 +0000

Ok, let's defer discussion around potential rewording of the buffering text, and go with the following:

"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. [same as before]
Where possible, implementations MAY instead process data immediately rather than buffering it."

(Same as before, just added 'instead' after MAY to make it clearer that it's an exception to the previous MUST).

Settled?
Sent: Monday, November 8, 2021 12:08 PM

Great!

It will eventually work, but I believe it will cause extremely poor performance.

No, I don't think that this works. Because it allows you to simply drop it. If you want to file an issue, I will attempt to draft some text.

-Ekr

-Ekr

-Ekr

-Ekr

- 1000, 1000
... som retransmits
<backs off the MTU>
- 700, 700, 600

-Ekr

-Ekr

-----Original Message-----
From: TLS <[email-masked]<mailto:[email-masked]>> On Behalf Of Achim Kraus
Sent: Saturday, November 6, 2021 6:22 AM
To: Hanno Becker <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing

Hi Hanno,

best regards
Achim

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Nov 2021 06:33:48 -0800

On Mon, Nov 8, 2021 at 4:12 AM Salz, Rich <[email-masked]> wrote:

>
>    - No. As I indicated in my earlier, email, while that scheme may
Well, right now it's forbidden. I am saying we shouldn't relax that.

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 8 Nov 2021 15:03:14 +0000

*   Well, right now it's forbidden. I am saying we shouldn't relax that.

Sorry, I meant “we shouldn’t change things for that.”

I mean, how would a peer know, anyway?

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 8 Nov 2021 20:28:06 +0200

> > > > 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).

> It will eventually work, but I believe it will cause extremely poor

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

---

From: Hanno Becker <[email-masked]>
Date: Mon, 8 Nov 2021 18:56:09 +0000

> 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 <[email-masked]> on behalf of Ilari Liusvaara <[email-masked]>
Sent: Monday, November 8, 2021 6:28 PM
To: [email-masked] <[email-masked]>
Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing

-Ilari

---

From: Hanno Becker <[email-masked]>
Date: Wed, 10 Nov 2021 06:58:43 +0000

PR for immediate processing: https://github.com/tlswg/dtls13-spec/pull/258
Issue for buffering text: https://github.com/tlswg/dtls13-spec/issues/259

Thanks all
________________________________
From: TLS <[email-masked]> on behalf of Hanno Becker <[email-masked]>
Sent: Monday, November 8, 2021 6:56 PM
To: Ilari Liusvaara <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing

not support it.

-Ilari