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?
I
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 (t
cr.org
From: Achim Kraus
Sent: Saturday, November 6, 2021 7:36 AM
To: Hanno Becker
Cc: 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,
___
From: TLS on behalf of Hanno Becker
Sent: Saturday, November 6, 2021 8:18 AM
To: Achim Kraus
Cc: tls@ietf.org
Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing
Hey Achim,
Thanks for the quick reply!
Actually, for TLS, you can do the same: Process handsh
-
*From:* Achim Kraus
*Sent:* Saturday, November 6, 2021 7:36 AM
*To:* Hanno Becker
*Cc:* tls@ietf.org
*Subject:* Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to
processing
Hi Hanno,
> Can someone explain
table for their
deployment model.
-Original Message-
From: TLS On Behalf Of Achim Kraus
Sent: Saturday, November 6, 2021 6:22 AM
To: Hanno Becker
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
mes and gradual processing non-compliant.
From: Scott Fluhrer (sfluhrer)
Sent: Saturday, November 6, 2021 1:56 PM
To: Achim Kraus ; Hanno Becker
Cc: tls@ietf.org
Subject: RE: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing
There are a number of pos
November 6, 2021 1:56 PM
> *To:* Achim Kraus ; Hanno Becker >
> *Cc:* 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
From: Scott Fluhrer (sfluhrer) mailto:sfluh...@cisco.com>>
Sent: Saturday, November 6, 2021 1:56 PM
To: Achim Kraus mailto:achimkr...@gmx.net>>; Hanno Becker
mailto:hanno.bec...@arm.com>>
Cc: tls@ietf.org<mailto:tls@ietf.org> mailto:tls@ietf.org>>
Sub
immediately.
-Ekr
--
> *From:* Eric Rescorla
> *Sent:* Saturday, November 6, 2021 8:57 PM
> *To:* Hanno Becker
> *Cc:* Scott Fluhrer (sfluhrer) ; Achim Kraus <
> achimkr...@gmx.net>; tls@ietf.org
> *Subject:* Re: [TLS] DTLS 1.2 and 1.3: HS messa
rom: Eric Rescorla
Sent: Sunday, November 7, 2021 9:14 PM
To: Hanno Becker
Cc: Scott Fluhrer (sfluhrer) ; Achim Kraus
; 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
mailto:hanno.bec...@arm.com>
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
essing, or
gradual processing of fragments (if possible), or a combination of both.
From: Eric Rescorla
Sent: Sunday, November 7, 2021 9:36 PM
To: Hanno Becker
Cc: Scott Fluhrer (sfluhrer) ; Achim Kraus
; tls@ietf.org
Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing
essing 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
> *Sent:* Sunday, No
immediately rather than buffering it"?
From: Eric Rescorla
Sent: Sunday, November 7, 2021 10:16 PM
To: Hanno Becker
Cc: Scott Fluhrer (sfluhrer) ; Achim Kraus
; tls@ietf.org
Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing
I'd like to
"?
>
That would be fine with me.
-Ekr
> --
> *From:* Eric Rescorla
> *Sent:* Sunday, November 7, 2021 10:16 PM
> *To:* Hanno Becker
> *Cc:* Scott Fluhrer (sfluhrer) ; Achim Kraus <
> achimkr...@gmx.net>; tls@ietf.org
> *Sub
ations MAY
process data immediately rather than buffering it.
From: Eric Rescorla
Sent: Monday, November 8, 2021 11:47 AM
To: Hanno Becker
Cc: Scott Fluhrer (sfluhrer) ; Achim Kraus
; tls@ietf.org
Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing
On Sun, Nov 7, 2021
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
>
>
> --
> *From:* Eric Rescorla
> *Sent:* Monday, November 8, 2021 11:47 AM
> *To:* Hanno Becker
> *Cc:* Scott Fluhrer (sfluhrer) ; Achim Kraus &
* 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.
___
TLS mailing list
TLS@ietf.
__
From: Eric Rescorla
Sent: Monday, November 8, 2021 12:08 PM
To: Hanno Becker
Cc: Scott Fluhrer (sfluhrer) ; Achim Kraus
; tls@ietf.org
Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing
On Mon, Nov 8, 2021 at 3:58 AM Hanno Becker
mailto:hanno.bec...@arm
On Mon, Nov 8, 2021 at 4:12 AM Salz, Rich wrote:
>
>- 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.
>
>
>
* 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.
* Well, right now it's forbidden. I am saying we shouldn't relax that.
On Mon, Nov 08, 2021 at 04:08:51AM -0800, Eric Rescorla wrote:
> On Mon, Nov 8, 2021 at 3:58 AM Hanno Becker 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
nch of Mbed TLS does already support it. It provides a
common interface between record and HS layer which supports gradual processing.
From: TLS on behalf of Ilari Liusvaara
Sent: Monday, November 8, 2021 6:28 PM
To: tls@ietf.org
Subject: Re: [TLS] DTLS 1.2
@ietf.org
Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing
> 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
25 matches
Mail list logo
