[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

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

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

[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

[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] Media types "application/tls" and "application/ssl", and URIs for schemes "tls" and "ssl"

[Salz, Rich]

> Perhaps a possibility would be "application/tls-record"? This is similar to 
> how "application/dns-message" is defined in [RFC 8484 section 6]

Yes, that seems reasonable.  Your registration should point out that the 
content might not be decodable without external information, and that in at 
least one use-case (yours), a collection of records will not necessarily cover 
the entire message stream.

You might also want to reach out to the wireshark folks and see what they think.

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

Re: [TLS] Media types "application/tls" and "application/ssl", and URIs for schemes "tls" and "ssl"

[Salz, Rich]

> We would be recording the records send by the client to the servers, and 
> those received by the client from the server.

So presumably you need some kind of direction/origin indicator.



___
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

[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] RFC88447bis: additional DE instructions

[Sean Turner]

Happy 2024!  Hoping to close this one out by Monday so get your comment in!

Cheers,
spt

> On Dec 12, 2023, at 08:38, Sean Turner  wrote:
> 
> Hi! Rich $, Martin T, and ekr have all added some thoughts.   Anybody else 
> have some thoughts?
> 
> spt
> 
>> On Dec 6, 2023, at 11:20, Sean Turner  wrote:
>> 
>> Hi! A thread over on the IRTF’s CFRG list, see [0], has resulted in a PR, 
>> see [1], that includes additional instructions for the designated experts 
>> related to “Expert Review of Current and Potential IETF and IRTF Documents". 
>>  Please let us know what you think about the contents of the PR (here or in 
>> the PR). Also, please keep messages related to this PR on this list and off 
>> the CFRG list.
>> 
>> Thanks,
>> spt
>> 
>> [0] https://mailarchive.ietf.org/arch/msg/cfrg/QzxwN9hrSGHl0pBdWOhvfZ1UOhM/
>> [1] https://github.com/tlswg/rfc8447bis/pull/50
>> 
> 

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

Re: [TLS] Media types "application/tls" and "application/ssl", and URIs for schemes "tls" and "ssl"

[arkiver]

> Again, think carefully about the data you are recording. Also, TLS1.2 allows 
> renegotiation in an active connection to do things like change the cipher 
> algorithm, ask the client to send its certificate, and so on. Are you going 
> to record those? Client authentication seems like something important. And 
> which part are you recording". The client or server side or both? You said 
> "outgoing TLS record" but that's not clear to me. Renegotiation can be 
> initiated by either side FYI.

We would be recording the records send by the client to the servers, and those 
received by the client from the server.

> Are you going to support session resumption, session tickets, pre-shared 
> keys? Are you going to ensure your client doesn't do any of those?

Theoretically we would support archiving all SSL/TLS records, with one 
condition (copied from previous email):

While any TLS records may be stored in the WARC, encrypted content in these 
records that needs to be available in decrypted form must be stored in a 
separate record in decrypted form. If the TLS record does not contain any other 
data of interest next to what is stored decrypted separately, the TLS record 
should not be stored, keeping only the decrypted record.

The would prevent any need for storing sensitive keys, and is in line with 
storing the HTTP record in decrypted form as is already being done.

This also means that in some cases it might make no sense to store the TLS 
record as it holds no interesting data next to the data that was stored in 
decrypted form.

> I read RFC 7595 and looked at the IANA registry. I am fairly confident that 
> you will never get the "tls" scheme, so you might want to re-think things a 
> bit.

Thank you for checking that, we will think about this.

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

Re: [TLS] Media types "application/tls" and "application/ssl", and URIs for schemes "tls" and "ssl"

[arkiver]

> Merging the thread this early didn't help this conversation. I am sure I have 
> missed replying to some of my points that you responded to.

Sorry about that, I did not realise it.

There is one important part that was missed, I put it in this message separate 
from the previous reply to your message.

It was the following, your reply and our suggestion for 
"application/tls-record" similar to "application/dns-message".

> In fact, I suggest the media types be “warc+tls” and, if really needed (sure 
> some parts of the web are old), “warc+ssl” Then register those two suffices.  
> At least, I think that’s a reasonable idea. It might be that warc-tls and 
> warc-ssl is better.

This is an option. The problem I see here is that "application/warc-tls" (or 
"application/warc+tls") suggests that the data referenced by it is somehow 
unique to the WARC, while it is not. It is simply a copy of a entire SSL/TLS 
record, with no changes made to it.

Perhaps a possibility would be "application/tls-record"? This is similar to how 
"application/dns-message" is defined in [RFC 8484 section 
6.](https://datatracker.ietf.org/doc/html/rfc8484#section-6) as a "single 
message of the DNS on-the-wire format defined in [Section 4.2.1 of 
[RFC1035]](https://datatracker.ietf.org/doc/html/rfc1035#section-4.2.1)".

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

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