Re: [TLS] Key Update for TLS/DTLS 1.3

[Ilari Liusvaara]

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 bandwidth is less of an issue).

I think the number of messages is the smallest possible for
bidirectional fresh key exchange over reliable channel (3 for non-
crossed, 4 for crossed).

However, there are some bandwith improvements:

- In crossed case if groups match and group is symmetric (not PQC),
  then both sides immediately ack. Saves 2 key shares.
- In crossed mismatch/asymmetric case, one side drops the request,
  and other handles it as non-crossed. Saves 1 server key share.

AFAICT, after that, there are no more pareto improvements.


The flows are (with server responding):

<-- request -->
<-- ack -->

and

<-- request -->
<-- response
ack -->


However, this might not work at all in unreliable case (DTLS).
Especially the symmetric crossed case, but even in the asymmetric
case request getting delayed until after key exchange completes
could cause nasty issues.




-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Key Update for TLS/DTLS 1.3

[Hannes Tschofenig]

Hi Scott,


thanks for your feedback. Introducing PQC algorithms in the design for
this proposal has not been discussed in TSVWG design team and has
therefore not been a requirement for me. (Maybe my co-authors see this
differently.)

I will bring this topic up in the next design team call. In any case, it
is good to hear your preferences.


Ciao

Hannes


Am 05.01.2024 um 20:52 schrieb Scott Fluhrer (sfluhrer):


Here’s an issue I see with postquantum exchanges; Kyber (and most
other postquantum key exchanges) would have an issue with the current
format.  There are distinct ‘initiate key shares’ and ‘response key
shares’, and they’re not interchangeable; a ‘response key share’ must
be generated for a specific ‘initiate key share’.

Now, it would be possible to extend ExtendedKeyUpdate to include a
flag stating whether this is a request for new keys, or a response
(distinguishing the two cases); that would be a relatively small change.

However, what happens if both sides happen to issue ExtendedKeyUpdate
at the same time?

With DH, it’s not an issue; they could ignore the flag, and they would
both accept the other’s ExtendedKeyUpdate as a response to their own,
and both update the keys in the same way.

However, with Kyber, if we issue an ‘initiate key share’ and get an
‘initiate key share’ in response, we can’t generate keys.

One possibility would be if there is a tie-breaker between the two
sides (such as ‘who had the lexically larger key share)’; the loser of
that tie-breaker would discard his original ExtendedKeyUpdate, and
reissue another one (which is a response to the other side’s)?

I believe this idea would extend to DTLS as well as TLS.

A bit kludgy (and definitely adding complexity); however I also
believe that it would be short-sighted to ignore 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 “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 TSVWG. The need for it has, however, already been
discussed years ago on the TLS mailing list in the context of
long-lived TLS connections in industrial IoT environments.

Unlike the TLS 1.3 Key Update message, which is a one-shot message,
the extended Key Update message requires a full roundtrip.

Here is the link to the draft:

https://datatracker.ietf.org/doc/draft-tschofenig-tls-extended-key-update/

I am curious what you think.

Ciao
Hannes


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Key Update for TLS/DTLS 1.3

[Hannes Tschofenig]

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 alternatives keeping the
single shot approach of the keyUpdate in TLS 1.3.

The intension was to have an ephemeral-static DH exchange, which uses
the previously used DH key of the receiver R and an ephemeral DH
parameter for the sender S in the ExtendedKeyUpdate. That way, both
sides can immediate generate a new session key without any
interruption. The receiver R may then directly react with a
ExtendedKeyUpdate utilizing the updated DH key of S and an own
ephemeral DH key for R.  That way both sides have stepwise contributed
an ephemeral DH part. As the ExtendedKeyUpdate messages are
independent, application data may still be exchanged in between,
without introducing waiting time.

While keeping the single shot feature, this approach would have the
disadvantage, that the last received DH key needs to be stored in
cases it is needed for an ephemeral-static exchange. But this may be
easier to handle.

Would that work with groups that are not DH (client and server shares
are not interchangeable)?


My focus was not on PQC algorithms for this work. It was meant as an
extension to be used in the near term.

From Scott's feedback I can see that others seem to have different
priorities.




And would it work with implementations where there is hard constraint
that each key exchange may only be completed once?


No, not in this design. It was not one of the design requirements for me
and, if that's a requirement, then this functionality is probably not
applicable.


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 bandwidth is less of an issue).



I don't know if it would work for DTLS, but I did come up with design
with four different messages: request, response, ack and crossed.

- Request:
   * Has client key share.
   * Causes no key change.
   * MUST NOT be sent while pending handshake.
   * MUST NOT be sent while pending EKU.
   * Receiver responds with response if no pending EKU.
   * Receiver responds with crossed if pending EKU (will also
 happen on the other side).
- Response:
   * Has server key share.
   * Causes forward key change.
   * Reverse keys calculated for install with ack.
   * Receiver responds with ack.
- Ack:
   * Does not carry key share.
   * Causes forward key change (to previously calculated keys).
   * EKU completed on send/receive.
- Crossed:
   * Has server key share.
   * Causes forward key change.
   * No reverse key change (done by other crossed EKU).
   * EKU completed on send/receive.

The possible flows are (all update keys in both directions):

A) Non-crossed, client initiated:
--- request -->
<-- response ---
--- ack -->

B: Non-crossed, server initiated:
<-- request ---
--- response -->
<-- ack ---

C: Crossed

<-- request -->
<-- crossed -->




Ciao

Hannes



-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Key Update for TLS/DTLS 1.3

[Benjamin Kaduk]

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.
> 
> 
[...]
> 
> 
>Here is the link to the draft:
> 
>
> [1]https://datatracker.ietf.org/doc/draft-tschofenig-tls-extended-key-update/

A few thoughts from a quick read (to supplement the good comments already 
received):

- I'm not sure that the current condition "can be sent by either peer after it 
has sent a Finished message" will work quite right for the DTLS case; I think 
that you'd need to also know that your Finished has been processed before 
sending EKU, in order to ensure that the peer will accept it.

- I'd probably drop the "perfect" from "perfect forward secrecy" -- you already 
quote the bit from RFC 9325 that uses just "forward secrecy" as the primary 
term and I don't see much reason to diverge from that.

- The discussion of truncation attacks near the end of §4.1 doesn't seem quite 
right w.r.t. DTLS, in that DTLS is always going to be susceptible to truncation 
attacks (but I do think that the requirement you propose should still be 
enforced).

- The prose discussion of the key schedule should probably get tweaked a bit; 
it makes it sound as if application_traffic_secret_N is not used at all (it's 
currently put in as the "messages" parameter to Derive-Secret(), if I'm reading 
correctly) and that the dh-secret is used directly in HKDF-Expand-Label() 
(which would be misuse since it's not uniformly random and needs an 
HKDF-Extract first, as is shown in the actual figure).

- I'm not sure about using application_traffic_secret_N as the "messages" input 
to Derive-Secret() -- that would seem to imply that we hash it as a transcript 
hash???  Why not use it as HKDF-Extract input alongside dh-secret?

- I'm not sure I'd put something about hybrid key exchange in at this point, 
and IIRC the concatenation secret combiner is not known to be the best choice 
of secret combiner.

Thanks,

Ben

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Key Update for TLS/DTLS 1.3

[Scott Fluhrer (sfluhrer)]

Here's an issue I see with postquantum exchanges; Kyber (and most other 
postquantum key exchanges) would have an issue with the current format.  There 
are distinct 'initiate key shares' and 'response key shares', and they're not 
interchangeable; a 'response key share' must be generated for a specific 
'initiate key share'.

Now, it would be possible to extend ExtendedKeyUpdate to include a flag stating 
whether this is a request for new keys, or a response (distinguishing the two 
cases); that would be a relatively small change.

However, what happens if both sides happen to issue ExtendedKeyUpdate at the 
same time?

With DH, it's not an issue; they could ignore the flag, and they would both 
accept the other's ExtendedKeyUpdate as a response to their own, and both 
update the keys in the same way.

However, with Kyber, if we issue an 'initiate key share' and get an 'initiate 
key share' in response, we can't generate keys.

One possibility would be if there is a tie-breaker between the two sides (such 
as 'who had the lexically larger key share)'; the loser of that tie-breaker 
would discard his original ExtendedKeyUpdate, and reissue another one (which is 
a response to the other side's)?

I believe this idea would extend to DTLS as well as TLS.

A bit kludgy (and definitely adding complexity); however I also believe that it 
would be short-sighted to ignore 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 "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 
TSVWG. The need for it has, however, already been discussed years ago on the 
TLS mailing list in the context of long-lived TLS connections in industrial IoT 
environments.
Unlike the TLS 1.3 Key Update message, which is a one-shot message, the 
extended Key Update message requires a full roundtrip.

Here is the link to the draft:
https://datatracker.ietf.org/doc/draft-tschofenig-tls-extended-key-update/

I am curious what you think.

Ciao
Hannes

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Key Update for TLS/DTLS 1.3

[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 alternatives keeping the
> single shot approach of the keyUpdate in TLS 1.3.
> 
> The intension was to have an ephemeral-static DH exchange, which uses
> the previously used DH key of the receiver R and an ephemeral DH
> parameter for the sender S in the ExtendedKeyUpdate. That way, both
> sides can immediate generate a new session key without any
> interruption. The receiver R may then directly react with a
> ExtendedKeyUpdate utilizing the updated DH key of S and an own
> ephemeral DH key for R.  That way both sides have stepwise contributed
> an ephemeral DH part. As the ExtendedKeyUpdate messages are
> independent, application data may still be exchanged in between,
> without introducing waiting time.
> 
> While keeping the single shot feature, this approach would have the
> disadvantage, that the last received DH key needs to be stored in
> cases it is needed for an ephemeral-static exchange. But this may be
> easier to handle.

Would that work with groups that are not DH (client and server shares
are not interchangeable)?

And would it work with implementations where there is hard constraint
that each key exchange may only be completed once?


I don't know if it would work for DTLS, but I did come up with design
with four different messages: request, response, ack and crossed.

- Request:
  * Has client key share.
  * Causes no key change.
  * MUST NOT be sent while pending handshake.
  * MUST NOT be sent while pending EKU.
  * Receiver responds with response if no pending EKU.
  * Receiver responds with crossed if pending EKU (will also
happen on the other side).
- Response:
  * Has server key share.
  * Causes forward key change.
  * Reverse keys calculated for install with ack.
  * Receiver responds with ack.
- Ack:
  * Does not carry key share.
  * Causes forward key change (to previously calculated keys).
  * EKU completed on send/receive.
- Crossed:
  * Has server key share.
  * Causes forward key change.
  * No reverse key change (done by other crossed EKU).
  * EKU completed on send/receive.

The possible flows are (all update keys in both directions):

A) Non-crossed, client initiated:
--- request -->
<-- response ---
--- ack -->

B: Non-crossed, server initiated:
<-- request ---
--- response -->
<-- ack ---

C: Crossed

<-- request -->
<-- crossed -->




-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Key Update for TLS/DTLS 1.3

[Fries, Steffen]

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 have an ephemeral-static DH exchange, which uses the 
previously used DH key of the receiver R and an ephemeral DH parameter for the 
sender S in the ExtendedKeyUpdate. That way, both sides can immediate generate 
a new session key without any interruption. The receiver R may then directly 
react with a ExtendedKeyUpdate utilizing the updated DH key of S and an own 
ephemeral DH key for R.  That way both sides have stepwise contributed an 
ephemeral DH part. As the ExtendedKeyUpdate messages are independent, 
application data may still be exchanged in between, without introducing waiting 
time.

While keeping the single shot feature, this approach would have the 
disadvantage, that the last received DH key needs to be stored in cases it is 
needed for an ephemeral-static exchange. But this may be easier to handle.

Best regards
Steffen


From: TLS  On Behalf Of Hannes Tschofenig
Sent: Friday, January 5, 2024 3:53 PM
To: David Benjamin ; Tschofenig, Hannes 

Cc: 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 took for the regular TLS 1.3 key update as well. In the 
use cases I have in mind, the application knows whether it has application data 
to send and therefore what a good timing for such an extended key update would 
be. You are correct that there is a short time window when the sender of the 
extended key update has to wait till it receives the response from the peer 
party to also update its sending keys. I have not considered running the 
extended key update in parallel to the application data exchange and the use of 
a three message exchange.

It may be possible that this approach is not possible in environments where 
there is a continuous stream of packets or where potential delays in sending 
data are unacceptable. I suspect you have such an environment (?). When I also 
take the comments from Thom into account, who didn't like the change to the 
state machine with the full-round-trip approach, I am wondering whether the 
alternative of using a semi-static DH, which we considered in Appendix B, may 
ultimately be better.



Ciao
Hannes


Am 05.01.2024 um 01:40 schrieb David Benjamin:
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 ExtendedKeyUpdate, but 
it may see something else that forces it to send data, such as an application 
protocol message or an update_requested KeyUpdate. (Or perhaps an 
update_requested ExtendedKeyUpdate!)

Are you envisioning that the client is unable to send anything until it 
receives the server's response, or that this exchange flows in parallel with 
the rest of the connection?

If the client is unable to send anything, this seems like it would cause 
problems. Certainly it would not be something the TLS library can do 
automatically, because it can only run at a quiet point in the application 
protocol. A priori, you may receive an unbounded amount of application data 
while waiting for ExtendedKeyUpdate. You need to do something with that data, 
but all options result in either an unbounded buffer or a deadlock somewhere.

If the exchange flows in parallel, how does the server know where, in the 
client stream, did the client switch keys? I think you'd need a third message 
to mark this point.Though we then need to reason through what happens if that 
third message doesn't come in for a long while, because the server can't 
release state from that key update until then.

To that end, what happens if someone sends a storm of ExtendedKeyUpdate 
messages with update_requested in a row? Over TCP, we have to worry about a DoS 
issue caused by asymmetric rates on the two sides. (If I send you a storm of 
update_requested but refuse to read from the socket, at some point backpressure 
will stop you from writing responses. At that point, you need to know to stop 
reading or you'll buffer up unbounded data.) For plain KeyUpdate, we said the 
requests can be coalesced, but ExtendedKeyUpdate messages contain different key 
shares. I suspect you need to say that you cannot send a new update_requested 
until after you've sent the third message for the previous one.

Relatedly, this seems tricky:

> If implementations independently send their own ExtendedKeyUpdate messages, 
> and they cross in flight, the result is that each side increments keys by two 
> generation

Re: [TLS] Key Update for TLS/DTLS 1.3

[Hannes Tschofenig]

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 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 perhaps aren't as neat, but it
would only require client side implementation changes and no spec or
server-side changes to deploy.

Opening a new connection is rather distruptive in some applications,
even if done as make-before-break.

For example, if application ties some resources to existence of
connection, there would have to be some mechanism to transfer the
resources from old connection to new to avoid distruption from the
resources going away. And very few applications are capable of doing
that.




-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Key Update for TLS/DTLS 1.3

[Hannes Tschofenig]

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 in mind, the application knows
whether it has application data to send and therefore what a good timing
for such an extended key update would be. You are correct that there is
a short time window when the sender of the extended key update has to
wait till it receives the response from the peer party to also update
its sending keys. I have not considered running the extended key update
in parallel to the application data exchange and the use of a three
message exchange.

It may be possible that this approach is not possible in environments
where there is a continuous stream of packets or where potential delays
in sending data are unacceptable. I suspect you have such an environment
(?). When I also take the comments from Thom into account, who didn't
like the change to the state machine with the full-round-trip approach,
I am wondering whether the alternative of using a semi-static DH, which
we considered in Appendix B, may ultimately be better.


Ciao
Hannes


Am 05.01.2024 um 01:40 schrieb David Benjamin:

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 ExtendedKeyUpdate, but it may see something else that
forces it to send data, such as an application protocol message or an
update_requested KeyUpdate. (Or perhaps an update_requested
ExtendedKeyUpdate!)

Are you envisioning that the client is unable to send anything
until it receives the server's response, or that this exchange flows
in parallel with the rest of the connection?

If the client is unable to send anything, this seems like it would
cause problems. Certainly it would not be something the TLS library
can do automatically, because it can only run at a quiet point in the
application protocol. A priori, you may receive an unbounded amount of
application data while waiting for ExtendedKeyUpdate. You need to do
/something/ with that data, but all options result in either an
unbounded buffer or a deadlock somewhere.

If the exchange flows in parallel, how does the server know where, in
the client stream, did the client switch keys? I think you'd need a
third message to mark this point.Though we then need to reason through
what happens if that third message doesn't come in for a long while,
because the server can't release state from that key update until then.

To that end, what happens if someone sends a storm of
ExtendedKeyUpdate messages with update_requested in a row? Over TCP,
we have to worry about a DoS issue caused by asymmetric rates on the
two sides. (If I send you a storm of update_requested but refuse to
read from the socket, at some point backpressure will stop you from
writing responses. At that point, you need to know to stop reading or
you'll buffer up unbounded data.) For plain KeyUpdate, we said the
requests can be coalesced, but ExtendedKeyUpdate messages contain
different key shares. I suspect you need to say that you cannot send a
new update_requested until after you've sent the third message for the
previous one.

Relatedly, this seems tricky:

> If implementations independently send their own ExtendedKeyUpdate
messages, and they cross in flight, the result is that each side
increments keys by two generations.

Since ExtendedKeyUpdate incorporates new key material into the new
secret, you will get a different result depending on which exchange is
processed first. But the two sides may see each exchange resolving in
a different order when crossed like this. (It /might/ work with a
three-message design? Then there's an in-band signal for when the keys
are applied on each side. Though it means this cross case can actually
resolve in different orders for the two streams, which is kind of
interesting.)

On Thu, Jan 4, 2024 at 6:42 AM 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 need for this functionality surfaced in discussions in a
design team of the TSVWG. The need for it has, however, already
been discussed years ago on the TLS mailing list in the context of
long-lived TLS connections in industrial IoT environments.

Unlike the TLS 1.3 Key Update message, which is a one-shot
message, the extended Key Update message requires a full roundtrip.

Here is the link to the draft:

https://datatracker.ietf.org/doc/draft-tschofenig-tls-extended-key-upd

Re: [TLS] Key Update for TLS/DTLS 1.3

[David Benjamin]

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
ExtendedKeyUpdate, but it may see something else that forces it to send
data, such as an application protocol message or an update_requested
KeyUpdate. (Or perhaps an update_requested ExtendedKeyUpdate!)

Are you envisioning that the client is unable to send anything until it
receives the server's response, or that this exchange flows in parallel
with the rest of the connection?

If the client is unable to send anything, this seems like it would cause
problems. Certainly it would not be something the TLS library can do
automatically, because it can only run at a quiet point in the application
protocol. A priori, you may receive an unbounded amount of application data
while waiting for ExtendedKeyUpdate. You need to do *something* with that
data, but all options result in either an unbounded buffer or a deadlock
somewhere.

If the exchange flows in parallel, how does the server know where, in the
client stream, did the client switch keys? I think you'd need a third
message to mark this point.Though we then need to reason through what
happens if that third message doesn't come in for a long while, because the
server can't release state from that key update until then.

To that end, what happens if someone sends a storm of ExtendedKeyUpdate
messages with update_requested in a row? Over TCP, we have to worry about a
DoS issue caused by asymmetric rates on the two sides. (If I send you a
storm of update_requested but refuse to read from the socket, at some point
backpressure will stop you from writing responses. At that point, you need
to know to stop reading or you'll buffer up unbounded data.) For plain
KeyUpdate, we said the requests can be coalesced, but ExtendedKeyUpdate
messages contain different key shares. I suspect you need to say that you
cannot send a new update_requested until after you've sent the third
message for the previous one.

Relatedly, this seems tricky:

> If implementations independently send their own ExtendedKeyUpdate
messages, and they cross in flight, the result is that each side increments
keys by two generations.

Since ExtendedKeyUpdate incorporates new key material into the new secret,
you will get a different result depending on which exchange is processed
first. But the two sides may see each exchange resolving in a different
order when crossed like this. (It *might* work with a three-message design?
Then there's an in-band signal for when the keys are applied on each side.
Though it means this cross case can actually resolve in different orders
for the two streams, which is kind of interesting.)

On Thu, Jan 4, 2024 at 6:42 AM 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 need for this functionality surfaced in discussions in a design team
> of the TSVWG. The need for it has, however, already been discussed years
> ago on the TLS mailing list in the context of long-lived TLS connections in
> industrial IoT environments.
>
> Unlike the TLS 1.3 Key Update message, which is a one-shot message, the
> extended Key Update message requires a full roundtrip.
>
>
>
> Here is the link to the draft:
>
> https://datatracker.ietf.org/doc/draft-tschofenig-tls-extended-key-update/
>
>
>
> I am curious what you think.
>
>
>
> Ciao
> Hannes
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Key Update for TLS/DTLS 1.3

[Ilari Liusvaara]

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 perhaps aren't as neat, but it
> would only require client side implementation changes and no spec or
> server-side changes to deploy.

Opening a new connection is rather distruptive in some applications,
even if done as make-before-break.

For example, if application ties some resources to existence of
connection, there would have to be some mechanism to transfer the
resources from old connection to new to avoid distruption from the
resources going away. And very few applications are capable of doing
that.




-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Key Update for TLS/DTLS 1.3

[Ilari Liusvaara]

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" supported_groups
and SHOULD send it if doing HRR because of missing group.


> > 
> > - The endpoint sending EKU with update_requested is the initiator for
> >groups that have asymmetric roles, right?
> 
> The client sends an EKU to the server in an attempt to update the
> traffic key for traffic sent from itself to the server. If it also
> wants to trigger the server to update the traffic keys in the reverse
> direction, namely from the server to the client, it needs to set the
> update_requested flag. Then, the server will have to trigger a
> separate exchange.

There are groups where it is not possible for client to tell crossed EKU
request from EKU reply from the key share itself, and things go south if
it processes crossed EKU requesst as EKU reply.

Milder version of that is groups that have incompatble client and server
key shares, but those can be identified from length. 

I don't think having just update_requested/update_not_requested flag
is sufficient. Non-crossed bidirectional update needs three-way (with
two or four key shares), and the crossed case needs to be handled (with
four key shares).




-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Key Update for TLS/DTLS 1.3

[Dennis Jackson]

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 implementation changes and no spec or 
server-side changes to deploy.


Best,
Dennis

On 04/01/2024 11:42, 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 need for this functionality surfaced in discussions in a design 
team of the TSVWG. The need for it has, however, already been 
discussed years ago on the TLS mailing list in the context of 
long-lived TLS connections in industrial IoT environments.


Unlike the TLS 1.3 Key Update message, which is a one-shot message, 
the extended Key Update message requires a full roundtrip.


Here is the link to the draft:

https://datatracker.ietf.org/doc/draft-tschofenig-tls-extended-key-update/

I am curious what you think.

Ciao
Hannes


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Key Update for TLS/DTLS 1.3

[Hannes Tschofenig]

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 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 TSVWG. The need for it has, however, already been
discussed years ago on the TLS mailing list in the context of long-
lived TLS connections in industrial IoT environments. Unlike the TLS
1.3 Key Update message, which is a one-shot message, the extended Key
Update message requires a full roundtrip.

Here is the link to the draft:
https://datatracker.ietf.org/doc/draft-tschofenig-tls-extended-key-update/

Some quick comments:

- The supported_groups in EE is optional. The group used in initial
   handshake is always considered supported, right?



When exchanging key shares, the use of supported_groups is mandatory (at
least that's what I remember).

It would, however, be useful to point out that this needed. As such, the
extended key update is not useful for cases where you only use PSK-based
authentication without a (EC)DHE key exchange.




- I can't quite parse what is going on in figure 3.


Figure 3 is supposed to show you how the extended key update works in
DTLS 1.3 with epoch values indicating when the keys in the different
directions change.

Let me think about how to better get the story across.




- The endpoint sending EKU with update_requested is the initiator for
   groups that have asymmetric roles, right?


The client sends an EKU to the server in an attempt to

update the traffic key for traffic sent from itself to the server.

If it also wants to trigger the server to update the traffic keys in the

reverse direction, namely from the server to the client, it needs to set the

update_requested flag. Then, the server will have to trigger a separate

exchange.


Did I understood you correctly?



- Crossed extended key update with DTLS sounds complicated enough that
   there should be an argument it works even with various message loss
   or reordering patterns.


Happy to add more text.




- TLS 1.3 limits labels in key schedule to 12 bytes (so that all the
   data fits into SHA256 block), but the label used here appears to
   be 13 bytes.


Good catch. Will change that.



Ciao

Hannes
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Key Update for TLS/DTLS 1.3

[Hannes Tschofenig]

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

Alternative designs: At the start I have been quite excited about the
idea of preserving the one-shot semantics of the key update.
Unfortunately, it comes with a price, as you also point out. Building
the design on top of draft-ietf-tls-semistatic-dh or AuthKEM may have
been possible as well but introduces dependencies that not everyone likes.


Ciao

Hannes


Am 04.01.2024 um 15:12 schrieb Thom Wiggers:

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't need
to indicate it supports this extension?
- Section 5 specifies that the N-1 keys SHOULD be deleted once
computed, but in many other sections (e.g. the tail of section 4) keys
are specified (MUST) to stay around for a bit longer. This seems
contradictory, and I think it would be less confusing if handling of
key material is more explicitly treated in the document.

Personally, I’m not super stoked about having extensions that bolt on
a new state machine, but it seems unavoidable for your problem
description (if we’re excluding application-layer fixes).

Your "alternative designs considered” section might have been more
viable if this was built on top of draft-ietf-tls-semistatic-dh or
AuthKEM, as we’d have long-term static key exchange keys (but it does
have other complications, such not allowing server-initiated EKUs if
there was no client auth). Otherwise I think that you’re right to not
require servers to store their ephemeral keys for the session lifetime
if the client sends an extension, while it may never even send the EKU
request.

Cheers,

Thom



Op 4 jan 2024, om 12:42 heeft Tschofenig, Hannes
 het volgende geschreven:

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 TSVWG. The need for it has, however, already been
discussed years ago on the TLS mailing list in the context of
long-lived TLS connections in industrial IoT environments.
Unlike the TLS 1.3 Key Update message, which is a one-shot message,
the extended Key Update message requires a full roundtrip.
Here is the link to the draft:
https://datatracker.ietf.org/doc/draft-tschofenig-tls-extended-key-update/
I am curious what you think.
Ciao
Hannes
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Key Update for TLS/DTLS 1.3

[Thom Wiggers]

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't need to 
indicate it supports this extension? 
- Section 5 specifies that the N-1 keys SHOULD be deleted once computed, but in 
many other sections (e.g. the tail of section 4) keys are specified (MUST) to 
stay around for a bit longer. This seems contradictory, and I think it would be 
less confusing if handling of key material is more explicitly treated in the 
document.

Personally, I’m not super stoked about having extensions that bolt on a new 
state machine, but it seems unavoidable for your problem description (if we’re 
excluding application-layer fixes).

Your "alternative designs considered” section might have been more viable if 
this was built on top of draft-ietf-tls-semistatic-dh or AuthKEM, as we’d have 
long-term static key exchange keys (but it does have other complications, such 
not allowing server-initiated EKUs if there was no client auth). Otherwise I 
think that you’re right to not require servers to store their ephemeral keys 
for the session lifetime if the client sends an extension, while it may never 
even send the EKU request.

Cheers,

Thom


> Op 4 jan 2024, om 12:42 heeft Tschofenig, Hannes 
>  het volgende geschreven:
> 
> 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 TSVWG. The need for it has, however, already been discussed years ago on 
> the TLS mailing list in the context of long-lived TLS connections in 
> industrial IoT environments.
> Unlike the TLS 1.3 Key Update message, which is a one-shot message, the 
> extended Key Update message requires a full roundtrip.
>  
> Here is the link to the draft:
> https://datatracker.ietf.org/doc/draft-tschofenig-tls-extended-key-update/
>  
> I am curious what you think.
>  
> Ciao
> Hannes
>  
> ___
> TLS mailing list
> TLS@ietf.org <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Key Update for TLS/DTLS 1.3

[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 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 TSVWG. The need for it has, however, already been
> discussed years ago on the TLS mailing list in the context of long-
> lived TLS connections in industrial IoT environments. Unlike the TLS
> 1.3 Key Update message, which is a one-shot message, the extended Key
> Update message requires a full roundtrip.
> 
> Here is the link to the draft:
> https://datatracker.ietf.org/doc/draft-tschofenig-tls-extended-key-update/

Some quick comments:

- The supported_groups in EE is optional. The group used in initial
  handshake is always considered supported, right?

- I can't quite parse what is going on in figure 3. 

- The endpoint sending EKU with update_requested is the initiator for
  groups that have asymmetric roles, right?

- Crossed extended key update with DTLS sounds complicated enough that
  there should be an argument it works even with various message loss
  or reordering patterns.

- TLS 1.3 limits labels in key schedule to 12 bytes (so that all the
  data fits into SHA256 block), but the label used here appears to
  be 13 bytes.




-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Key Update for TLS/DTLS 1.3

[Tschofenig, Hannes]

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 
TSVWG. The need for it has, however, already been discussed years ago on the 
TLS mailing list in the context of long-lived TLS connections in industrial IoT 
environments.
Unlike the TLS 1.3 Key Update message, which is a one-shot message, the 
extended Key Update message requires a full roundtrip.

Here is the link to the draft:
https://datatracker.ietf.org/doc/draft-tschofenig-tls-extended-key-update/

I am curious what you think.

Ciao
Hannes

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls