- I think this is an opportunity to improve usable security. While RFC 8466 states that implementations using AES-GCM SHOULD (MUST in RFC8446bis) perform a key update before reaching 2^24.5 full-size records, the key update mechanism is weak, and the requirement overlooks that rekeying should also be based on elapsed time. In OpenSSL (and very likely other libraries), compliance with the rekeying limit is left entirely to the application, which is poor security design.
I recommend that the draft require TLS 1.3 implementations to enforce rekeying limits based on both data volume and elapsed time. This aligns with the draft’s goal of enhancing security against key-exfiltration attacks (RFC 7624). A compliant TLS 1.3 implementation shall automatically ensure rekeying with MLS before the limits are reached. This places the enforcement responsibility on the protocol implementation rather than on the application developer. - Since the draft targets high-security deployments, I think it should mandate that compliant implementations support Traffic Flow Security (TFS). Notably, some TLS 1.3 implementations do not allow sending zero-length fragments of application data. Cheers, John Preuß Mattsson
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
