On Mon, Jan 08, 2024 at 11:52:53AM +0100, Hannes Tschofenig wrote:
>
> Am 05.01.2024 um 16:59 schrieb Ilari Liusvaara:
>
> Your design proposal below is nice but the number of messages make it
> less attractive (even though the use of this mechanism is likely for
> devices where performance and b
postquantum crypto at
this point.
*From:*TLS *On Behalf Of *Tschofenig, Hannes
*Sent:* Thursday, January 4, 2024 6:42 AM
*To:* TLS List
*Subject:* [TLS] Key Update for TLS/DTLS 1.3
Hi all,
we have just submitted a draft that extends the key update
functionality of TLS/DTLS 1.3.
We call it the
Hi Ilari,
thanks for your feedback. A few remarks below.
Am 05.01.2024 um 16:59 schrieb Ilari Liusvaara:
On Fri, Jan 05, 2024 at 03:11:37PM +, Fries, Steffen wrote:
Hi David,
In addition to what Hannes stated, the alternative in Appendix B was
the result of further thoughts on potential
On Thu, Jan 04, 2024 at 11:42:13AM +, Tschofenig, Hannes wrote:
>Hi all,
>
>
>
>we have just submitted a draft that extends the key update functionality
>of TLS/DTLS 1.3.
>
>We call it the “extended key update” because it performs an ephemeral
>Diffie-Hellman as part
crypto at this point.
From: TLS On Behalf Of Tschofenig, Hannes
Sent: Thursday, January 4, 2024 6:42 AM
To: TLS List
Subject: [TLS] Key Update for TLS/DTLS 1.3
Hi all,
we have just submitted a draft that extends the key update functionality of
TLS/DTLS 1.3.
We call it the "extended k
On Fri, Jan 05, 2024 at 03:11:37PM +, Fries, Steffen wrote:
> Hi David,
>
> In addition to what Hannes stated, the alternative in Appendix B was
> the result of further thoughts on potential alternatives keeping the
> single shot approach of the keyUpdate in TLS 1.3.
>
> The intension was to
: TLS List
Subject: Re: [TLS] Key Update for TLS/DTLS 1.3
Hi David,
thanks for sharing your thoughts.
Here is the approach I had in mind: the application code needs to trigger the
TLS/DTLS stack to start the extended key update. For the TLS 1.3 code I wrote,
that's the approach I too
Nicely written, Ilari.
Additionally, there is this patent for such a key update by John, Magnus
and Claudio written for the SCTP context:
https://datatracker.ietf.org/ipr/6218/
Ciao
Hannes
Am 04.01.2024 um 18:37 schrieb Ilari Liusvaara:
On Thu, Jan 04, 2024 at 04:26:09PM +, Dennis Ja
Hi David,
thanks for sharing your thoughts.
Here is the approach I had in mind: the application code needs to
trigger the TLS/DTLS stack to start the extended key update. For the TLS
1.3 code I wrote, that's the approach I took for the regular TLS 1.3 key
update as well. In the use cases I have
Skimming the draft, I am not following the timing of this process. Suppose
the client initiates an extended key update. It cannot update the keys yet,
because it does not know the server's response. It needs to keep reading
from the server. In doing so, it will hopefully see a responding
ExtendedKe
On Thu, Jan 04, 2024 at 04:26:09PM +, Dennis Jackson wrote:
> From a security perspective, this would be equivalent to having the
> client open a new connection to the server using a session ticket from
> the existing connection with psk_dhe_ke mode?
>
> I guess the ergonomics of that approach
On Thu, Jan 04, 2024 at 04:33:30PM +0100, Hannes Tschofenig wrote:
> Hi Ilari,
>
> When exchanging key shares, the use of supported_groups is mandatory (at
> least that's what I remember).
Only for client, it is not mandatory for server.
RFC 8446 only says that servers "are permitted to send" su
From a security perspective, this would be equivalent to having the
client open a new connection to the server using a session ticket from
the existing connection with psk_dhe_ke mode?
I guess the ergonomics of that approach perhaps aren't as neat, but it
would only require client side impleme
Hi Ilari,
thanks again for the super quick feedback. Remarks below:
Am 04.01.2024 um 14:53 schrieb Ilari Liusvaara:
On Thu, Jan 04, 2024 at 11:42:13AM +, Tschofenig, Hannes wrote:
Hi all,
we have just submitted a draft that extends the key update
functionality of TLS/DTLS 1.3. We call i
Hi Thom
thanks for the quick review.
Directionality of the extended key updates: I should be more clear in
the examples and in the write-up that these key updates can be initiated
by both parties.
Description about when the keys can be deleted: I will re-review the
text again to improve the w
Hi Hannes,
Skimming the document, I had the following questions:
- Can only clients request extended key updates (EKUs)? I think the text does
not attempt to impose this as a restriction, but all the examples are
client-initiating.
- If it is limited to client-initiated EKUs, the client shouldn
On Thu, Jan 04, 2024 at 11:42:13AM +, Tschofenig, Hannes wrote:
> Hi all,
>
> we have just submitted a draft that extends the key update
> functionality of TLS/DTLS 1.3. We call it the "extended key update"
> because it performs an ephemeral Diffie-Hellman as part of the key
> update.
>
> The
Hi all,
we have just submitted a draft that extends the key update functionality of
TLS/DTLS 1.3.
We call it the "extended key update" because it performs an ephemeral
Diffie-Hellman as part of the key update.
The need for this functionality surfaced in discussions in a design team of the
TSVW
18 matches
Mail list logo
