**Session Date/Time:** 18 Mar 2024 23:30 ```markdown # TLS Working Group Meeting ## Summary This TLS working group meeting covered several topics, including updates on existing drafts, discussions about new proposals, and considerations for future work. Key discussions revolved around IRADA resolution for 8446bis, the ECH update, registry updates, hybrid key exchange, obsolete key exchanges, formal analysis for TLS, large record sizes, a flag for client certificates, extended key updates, and pure ML-KEM support. ## Key Discussion Points * **8446bis and 8447bis Updates:** Progress is stalled on 8446bis due to unresolved IRADA reports. 8447bis is entering working group last call. * **ECH Update:** The working group last call for ECH is ending this month, with no major issues reported. * **Registry Updates:** A review of recent code point registrations was presented. There's a need to clarify the requirements for code point allocation, especially regarding concurrent standardization efforts in other IETF working groups or IRTF groups. * **Hybrid Key Exchange:** Discussion on the TLS hybrid draft, focusing on the selection of ML-KEM finalists and the approach to shared secret combination. A decision on concatenating shared secrets was favored due to TLS 1.3 key derivation logic. * **Obsolete Key Exchanges:** Reviewing the key exchange obsolete draft, aligning it with the new "discouraged" state in 8447bis. Discussion on deprecating specific key exchange methods, including ECDH and FFDHE. * **Formal Analysis:** A proposal was presented to establish a triage panel for formal analysis of TLS changes, especially for TLS 1.3. The focus is on maintaining security assurance and identifying potential issues early in the development process. Concerns were raised about blocking document progress based on student timelines and formal analysis completion. * **Large Record Sizes:** A draft proposing larger record sizes in TLS and DTLS to improve performance in certain use cases was discussed. Concerns about the diminishing performance returns and potential impact on traffic analysis were raised. Alternative approaches like record size scaling were suggested. * **Client Certificate Flag:** A proposal to add a flag to the client hello indicating the presence of a client certificate for web crawlers was discussed. * **Extended Key Update:** Presenting a design for the extended key update, particularly discussion around application layer interaction and HPKE usage. There were concerns about the complexity of doing this at the application layer as it relates to security proofs and concerns. Also, the original draft for this update had key share and key exchange as well as the HPKE. * **Pure ML-KEM:** Proposal to add pure ML-KEM as a new named group for TLS 1.3. Arguments included alignment with CNSA 2.0 guidelines and potential regulatory requirements. Concerns were raised about the maturity of post-quantum cryptography and the consistency of supporting both hybrid and PQ-only solutions. ## Decisions and Action Items * **8446bis:** The document shepherd (Sean Turner) will address the remaining IRADA reports before submitting the document to the ISG. * **ECH:** The chairs will proceed with sending the ECH draft to Paul Hoffman/Deb Matthews for IETF last call, assuming no new major issues arise. * **Registry Updates:** Rich Saltz will work with the draft authors to clarify the language regarding the code point registration requirements to address the concerns raised regarding the scope of standardization. * **Hybrid Key Exchange:** The draft authors will continue development, awaiting the final NIST selections of ML-KEM finalists. * **Obsolete Key Exchanges:** The draft authors will update the draft based on the feedback, including differentiating between TLS 1.2 and TLS 1.3 in deprecation recommendations and considering static DH certificate handling. * **Formal Analysis:** The chairs will consider forming a triage panel to review TLS drafts for formal analysis needs. More discussion on the mailing list to refine processes. * **Large Record Sizes:** The draft authors will revise the draft to address concerns about performance metrics, traffic analysis, and consider a record size scaling parameter as alternative proposal. * **Client Certificate Flag:** The chairs will take the client certificate proposal to the mailing list for further discussion. * **Extended Key Update:** The draft authors will revisit the design, removing the application layer dependency and the use of HPKE. Will address possible message de-syncing. * **Pure ML-KEM:** The chairs will confer and announce a path forward, likely involving individual draft publication and registration of a code point. ## Next Steps * Follow up on action items listed above. * Continue discussions on the mailing list for proposals and drafts. * Address open issues and concerns raised during the meeting. ```