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 > <hannes.tschofenig=40siemens....@dmarc.ietf.org> 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
