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> 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 > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
