TLS

Summary

This TLS meeting covered several important topics, including the status of existing drafts, the FAT process, and potential adoption of new PQ algorithms. Key discussions revolved around the SSL Keylog draft, the 8773-bis draft relating to PSKs and quantum resilience, and a proposed TLS flag for requesting client certificates in specific scenarios. Decisions were made regarding the SSL Keylog draft, while the 8773-bis draft and the mtLS flag proposal require further consideration.

Key Discussion Points

SSL Keylog Draft: A revived discussion surrounding the adoption of the combined SSL Keylog draft resulted in concerns being raised about extensibility and potential security implications. Some felt the working group hadn't adequately addressed previous concerns on the mailing list.
8773-bis (PSK and Quantum Resilience): A detailed presentation of the FAT report for the 8773-bis draft, which explores the use of PSKs in TLS to achieve quantum resilience. The FAT reviewers found that while the draft did not introduce vulnerabilities to traditional TLS, the claims about quantum resilience were not well substantiated, especially considering PSK reuse and group use scenarios.
mtLS Flag: A proposal for a new TLS flag to signal that a client is configured with a certificate and willing to provide it upon request. The main use case discussed was to allow servers to differentiate between bots and human users.

Decisions and Action Items

SSL Keylog Draft: The working group decided not to progress with the publication of the SSL Keylog draft in its current form.
8773-bis (PSK and Quantum Resilience): Further discussion is required in the working group. Options include publishing the document as is, revising the security claims, or waiting for a formal analysis.
mtLS Flag: Further discussion is required on the mailing list to refine the definition and applicability of the proposed TLS flag.

Next Steps

Chairs to analyze the results of the in-session voting on the 8773-bis draft and determine the next course of action.
Continue discussion on the mtLS flag proposal on the mailing list to address concerns about its applicability and potential for misuse.
Continue to process the existing queue of documents being reviewed by the FAT.
The next TLS meeting will be held on Thursday at 9:30 AM.

Session Date/Time: 20 Mar 2025 02:30

tls

Summary

This TLS working group meeting covered a range of topics, including trust anchors, password-authenticated key exchange (PAKE), encrypted client hello (ECH), and attested TLS. Discussions centered on improving security, addressing deployment challenges, and exploring new approaches to authentication and encryption. Several proposals were presented, generating lively debate and calls for further investigation.

Key Discussion Points

Trust Anchors (David Benjamin):
- Discussion of Trust Anchor Identifier sizes and the best way to transmit the data within TLS.
- Consideration of in-band vs. out-of-band trust anchor metadata provisioning.
- Exploration of the DNS dependency in the proposed trust anchor solution and potential alternatives.
- Debate on the complexity and trade-offs of the retry flow.
- Consideration of using OIDs vs. other ID schemes for identifying trust anchors.
PAKE (Laura Bauman):
- Presentation of a TLS 1.3 PAKE extension draft for low-entropy secrets.
- Discussion of integrating PAKE with existing TLS key exchange mechanisms for post-quantum resistance.
- Consideration of adding certificate support to the PAKE extension.
- Debate on whether to pursue a general PAKE framework or a targeted solution with a specific PAKE algorithm.
- Addressing security concerns related to key leakage and impersonation.
- Questions around interest and a bar for adoption after previous attempts to define PAKEs for TLS.
Post-Handshake PAKE (Yang Xia):
- Presentation of a proposal for post-handshake PAKE negotiation.
- Discussion of the benefits of post-handshake PAKE, including defense in depth and channel binding.
- Concerns raised about the proposal's lack of integration with TLS and potential overlap with existing protocols.
ECH (Nick Sullivan, Martin Thomson, Christopher Wood):
- Discussion of the limitations of current ECH deployments.
- Problems with the outer SNI field of the encrypted client hello making it easier to block.
- Exploration of potential solutions for improving ECH anonymity, including disabling shared caching and using per-connection public names.
- Debate on the role of public names and anonymity sets in ECH.
- Reviewing a different approach on a new way to have all servers re-randomize how public names get transmitted.
Attested TLS (Osama):
- Presentation of a formal analysis of the Attested TLS draft, highlighting a vulnerability that breaks server authentication.
- Discussion of solutions for augmenting rather than replacing server authentication, binding it to the remote attestation identity.
- Discussion of potential solutions involving certificate verify messages and channel binders.
- Concerns raised about the threat model and the difficulty of ensuring trust in the presence of compromised virtual machines.

Decisions and Action Items

Trust Anchors: The discussion will continue on the mailing list to further refine the design and address the identified decision points. The group will need to work towards consensus on key issues such as the DNS dependency and the retry flow.
PAKE: The chairs will initiate an adoption call on the mailing list for the first PAKE proposal focusing on low-entropy secrets.
ECH: Further work is needed to address the privacy and deployment challenges associated with ECH. The working group will continue to explore potential solutions, and any efforts will continue after ECH reaches RFC status.

Next Steps

Adoption call for the first PAKE proposal on the mailing list.
Continued discussion on the mailing lists regarding trust anchors, ECH, and Attested TLS.
Further development and refinement of the proposed solutions based on the feedback received during the meeting.