>An unhelpful answer is that the key exporter interface was already set by >prior versions of TLS and any TLS 1.3 key exporter needs to >remain analogous. >:-)
I think the opposite is true :) In TLS 1.2 rekeying (with renegotiation) does change the value returned by the key exporter, at least that is my understanding of the TLS 1.2 key exporter specification. By changing so that rekeying (key update) does not change the value returned by the key exporter, TLS 1.3 made a major change compared to earlier versions. I think it would maybe be good if the TLS 1.2 functionality that was removed in TLS 1.3 was documented better. Removed things that have caused problems/surprises for me personally: * Rekeying with Ephemeral Diffie-Hellman in a connection (this was used by DTLS/SCTP). * Post-Handshake server authentication (this was used by DTLS/SCTP). * Rekeying of the exporter secret (this was used by DTLS/SCTP). * Flight #4 (this was used by EAP-TLS 1.2). * Combining certificates with PSK (this was used by 3GPP) * Providing a PSK hint (this was used by 3GPP) (I am not saying these are necessary bad changes. They can be solved by setting up new connections and by using application data instead of flight #4, use RFC 8773, and sending more psk identifiers…) Cheers, John Preuß Mattsson From: TLS <tls-boun...@ietf.org> on behalf of David Benjamin <david...@chromium.org> Date: Wednesday, 29 November 2023 at 18:37 To: Tschofenig, Hannes <hannes.tschofenig=40siemens....@dmarc.ietf.org> Cc: tls@ietf.org <tls@ietf.org> Subject: Re: [TLS] Design Rational for Key Exporter An unhelpful answer is that the key exporter interface was already set by prior versions of TLS and any TLS 1.3 key exporter needs to remain analogous. :-) A more helpful answer is that we cannot simultaneously believe that key update is a transparent feature of TLS, and that exporters are sensitive to key update. Every use of key exporters necessarily involves both client and server computing the value and doing something with it (otherwise you could have just generated random bytes and moved on). That means both sides need to sample it at an analogous point in the connection, so the application protocol needs to be very aware of when all the key updates happen, and take care that corresponding uses of the exporter are sampled at corresponding epochs. That means, if we want to build an exporter update mechanism, it needs to be some operation exported to the application protocol and driven by the application. Key updates are not that. But I also don't think we need to or should do anything to support that use case. It is sufficient to have a single API, discard exporter secret, for the application to tell TLS it is done calling the exporter (and thus discard the root exporter secret). That API requires no new protocol machinery. An application that wants a ratcheting behavior in the exporter would then simply do: 1. After the connection is established, export the initial secret for their application-specific use of exporters and save it somewhere. 2. Discard the exporter secret 3. At whatever points in the application protocol make sense, have both sides run their application-specific ratcheting operation on the application-specific running secret. Not only that, we even intentionally designed the exporters to have a two-step label, then context derivation operation. This means "discard exporter secret" can instead be done by extracting label-specific exporters, in case one label wants to continue deriving values and another one is done and wants to ratchet. If there were some exporter-wide update operation, this would require coordination across all uses of exporters across the entire connection. So leaving the protocol as-is is the best way to meet this use case. On Wed, Nov 29, 2023 at 3:31 AM Tschofenig, Hannes <hannes.tschofenig=40siemens....@dmarc.ietf.org<mailto:40siemens....@dmarc.ietf.org>> wrote: Hi all, I was wondering why the design of the key exporter is such that it is based on the early_exporter_master_secret or the exporter_master_secret and no new key export is triggered at a later point in time, for example when a key update is performed. RFC 5705, which is used as a basis for the key exporter design in TLS 1.3, just states that there are protocols that want to obtain keying material from the TLS exchange. RFC 5705 nor the TLS 1.3 spec indicate the design rational of why no later events (e.g. post-handshake authentication or key updates) trigger a new key export. Was this done on purpose or was there just no use case for it at that time? 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
