**Session Date/Time:** 25 Jul 2022 19:00

# tls

## Summary

The TLS Working Group convened to discuss updates on several key drafts, including the evolving Compact TLS (CTLS) protocol, a proposed mechanism for well-known ECH keys, an update to the TLS registry for cryptographic algorithm recommendations, and the deprecation of obsolete key exchange methods. New work on TLS attestation was presented, exploring hardware-backed identity for endpoints. Finally, the significant challenges and considerations for integrating Post-Quantum Cryptography (PQC) into TLS were highlighted, alongside a decision on the behavior of the TLS Flags extension.

## Key Discussion Points

*   **Document Status Update:**
    *   DTLS 1.3, Ticket Requests, and Exported Authenticators have been published.
    *   Remaining PSK-related drafts are in the RFC 48 queue.
    *   Delegated Credentials (Subcerts) draft is awaiting progress.
    *   The RFC for TLS 1.2 and 1.3 is currently in Work Group Last Call, ending August 5th.
    *   Cross/TLS 1.3 Resumption and TLS Flags Extension drafts were paused but are now being revisited.
    *   Discussion is pending on whether to revive or abandon several scaled/expired working group drafts.

*   **Compact TLS (CTLS) - draft-ietf-tls-ctls-06 (Ben Schwartz)**
    *   **Profile IDs:** Now defined as byte strings (1-255 bytes). Short IDs (<=4 bytes) are reserved for IANA registration and assume prior knowledge by the recipient. Longer IDs are for specific deployments and are not registered.
    *   **Protocol Generator:** CTLS is no longer a compression layer. It now defines unique TLS-like protocols and authenticates its *own* transcript, rather than reconstructing a standard TLS transcript.
    *   **Template in Transcript:** Shared template information is prepended to the transcript and hashed into the `Finished` message to ensure agreement between parties.
    *   **Binary Templates:** A new consistent, reproducible binary format for templates has been defined to facilitate consistent hashing, alongside the existing JSON format.
    *   **Handshake Framing:** Supports both full-size, fragmented handshake messages (for DTLS) and single-record handshake messages for byte savings.
    *   **Discussion Points:**
        *   Compressed elliptic curves: Suggestion to define new code points (like X25519/X448).
        *   Omitting empty messages (e.g., `EndOfEarlyData`): Martin Thompson argued strongly against omitting critical empty messages in stream-based TLS, as they signal transition points. This optimization is likely to be removed.
        *   Relationship to DTLS 1.3: CTLS aims to generate both streaming (TLS) and datagram (DTLS) security protocols. Prototyping will validate this.
        *   Security properties: Clarified that CTLS aims for the same security properties as TLS 1.3, though a profile could theoretically define a broken configuration. Formal analysis would need to model the wire format.
        *   Versioning: A context string in the transcript is considered sufficient for versioning, provided clients reject unknown versions.

*   **Well-Known ECH Keys - draft-ietf-tls-well-known-ech (Stephen Farrell)**
    *   **Proposal:** A `/well-known` URL mechanism for web servers to publish ECH keys, intended for authoritative DNS servers to retrieve and publish in HTTPS RRs. This is to address the challenge of regularly updating ECH keys in DNS.
    *   **Co-authorship:** Rich and Ben Schwartz joined as co-authors.
    *   **Discussion Points:**
        *   **Limited Use Case:** Crucially, this mechanism is intended *only* for communication between an HTTP server and DNS infrastructure, *not* for generic clients. This distinction is critical to avoid desynchronization issues (e.g., caching ECH config from one CDN, IP from another) that general-purpose HTTPS RRs address.
        *   **Alternatives:** Discussed using retry configs (requires ECH draft changes) or other resource records (loses server authentication), both deemed less satisfactory.
        *   **Generality:** Whether to make it a more generic mechanism for HTTP servers to describe themselves to DNS infrastructure, or keep it specific to ECH keys. Stephen favors specific for now.
        *   **Technical Details:** ALPN information and SVCB complexities need further consideration.
        *   **Caching:** Ted suggested that the caching infrastructure for HTTP is not fully considered, and recommended registering it as a provisional experimental document via RFC 8615 to gather deployment experience, especially given its target use case where HTTP and DNS infrastructure owners may be separate.
        *   **Ports:** The JSON description of ports mentions TCP, but could be generalized for other protocols like QUIC.

*   **TLS Registry Update (8447bis) - draft-ietf-tls-rfc8447bis (Shawn Turner)**
    *   **Proposal:** Updates RFC 8447 to add a "D" (Discouraged/Weak) column to TLS registries.
    *   **Specific Recommendations (to be revised):**
        *   Extension Types: `truncated_hmac` and `connection_id` proposed as 'D'.
        *   Cipher Suites: `_DUPLICATED_` (deprecated) proposed as 'D'. Discussion on renaming to `_RESERVED_`.
        *   Hash Algorithms: MD5, SHA1, SHA224 proposed as 'D' (weak).
        *   Signature Algorithms: Anonymous, DSA, and Ghost algorithms proposed as 'N' (Not Recommended), with strong sentiment that anonymous and DSA should be 'D'. Martin Thompson suggested the standard for 'D' should be explicit RFCs stating the algorithm is bad.
        *   Certificate Types: Fortezza, ephemeral RSA, and DH reserved types proposed as 'D'.
        *   Elliptic Curve Related Registries: Most proposed as 'D' (e.g., explicit curves are broken, compressed are unused/problematic), keeping only `uncompressed` and `named_curve`.

*   **Deprecated Obsolete Exchange Methods - draft-ietf-tls-ohttp-dhe-deprecate (Nimrod Aviram)**
    *   **Proposal:** Deprecates RSA key exchange, static Finite-Field Diffie-Hellman Ephemeral (FF-DHE), limits FF-DHE to ephemeral forms with reasonable security groups, and discourages static Elliptic Curve Diffie-Hellman (EC-DHE).
    *   Confirmed by Security AD that the document belongs to the TLS WG.
    *   **Open Issues:**
        *   **FF-DHE Groups:** Whether to safe-list widely used but non-standardized groups (e.g., Postfix). Leaning towards yes for sufficient security.
        *   **Client Behavior:** If a client encounters a "bad group," should it `MUST abort` or `SHOULD abort`? Verifying group structure is computationally expensive.
    *   **Discussion Points:**
        *   Some felt the proposed deprecation list was overly strict, especially considering future post-quantum algorithms.
        *   Recommendation to forbid anything other than named groups for FF-DHE.
        *   Pen testers are increasingly flagging known DH groups as insecure (due to precomputation attack concerns), leading to users asking to generate arbitrary groups, which is problematic for validation. The document needs to address this directly, explaining why random group generation is a bad idea in practice and advocating for safe-listed or standardized named groups.
        *   FF-DHE is generally seen as on its way out in favor of ECDHE. Martin Thompson suggested a flat prohibition on FF-DHE in TLS 1.2 would be the most sensible, though a major revision.

*   **TLS Attestation - draft-tschofenig-tls-attestation-00 (Hannes Tschofenig)**
    *   **Proposal:** New work exploring a generalized mechanism to convey hardware-backed attestation information within TLS, building on new hardware isolation features.
    *   **Goal:** Avoid ad-hoc solutions, support RATS "background check" and "passport" models, support various attestation formats (TPM, ARM PSA attestation token), and be technology-agnostic.
    *   **Technical Approach:** A TLS extension for negotiation, using `certificate_types` but requiring a new `nonce` field for freshness, making direct reuse of existing certificate types extensions complex. Attestation information (a "bare token") would be augmented with a key for TLS client authentication, often via a "key attestation token" (e.g., CBOR Web Document with Proof of Possession).
    *   **Discussion Points:**
        *   It can support both client and server attestation.
        *   **Privacy Concerns:** Significant concerns were raised regarding the persistence, anonymization, and linkability of platform state information conveyed via attestation, particularly for client-side attestation. The privacy considerations section is critical and needs early, thorough development.
        *   **Layer Choice:** Questioned why this should be a TLS layer protocol rather than an application layer one, especially since many fraud cases are application-specific. Hannes noted TLS extensions are needed, and the protocol itself is short, but the context of attestation is broad. Server attestation for confidential cloud workloads was suggested as a clearer use case with fewer privacy pitfalls.
        *   **Terminology:** Clarification needed between "evidence" and "attestation results."
        *   **Complexity:** Acknowledged as valuable but complex work, requiring definition of what platform aspects (BIOS, firmware, OS) are relevant.

*   **Post-Quantum Cryptography (PQC) Process Update - Sophie Schmieg & Tom Hünemörder**
    *   **Key Exchange (KEX):** Relatively straightforward to integrate PQC KEX (hybrid approaches recommended).
    *   **Authentication:** More challenging due to larger sizes and computational times of NIST Round 3 signature algorithms compared to classical ones.
    *   **NIST Algorithms:** Dilithium 2 (faster computation, but larger size), Falcon (small, but tricky implementation), SPHINCS+ (hash-based, slow but conservative). NIST also has a call for new signature schemes (e.g., UOV with 400KB public keys).
    *   **Deployment Challenges:**
        *   **Network Dynamics:** Few real-world authentication experiments. Early experiments focused on KEX (e.g., OpenSSH 8.9 uses Kyber).
        *   **Message Sizes:** PQC certificate payloads can be very large (tens to hundreds of kilobytes), potentially exceeding TLS/QUIC message size limits (e.g., 16MB for certs, but much tighter limits for initial flights in QUIC - e.g., 1300-byte packets).
        *   **Performance:** Large messages severely impact latency and performance, especially within initial window constraints (e.g., IW10 for TCP). Martin Thompson noted that Kyber in a first QUIC packet could already overflow. Sending ClientHello in multiple packets would also cause issues with stateless servers (adding RTT).
        *   **Security vs. Size:** Martin Thompson suggested that NIST's chosen security levels might be too high for practical network limits, advocating for slightly lower security targets if it allows fitting algorithms into single packets.
    *   **Next Steps:** Continued engagement with NIST (workshops, events), further research into the practical size and performance implications for TLS and QUIC.

*   **TLS Flags Extension - draft-ietf-tls-tls-flags-02 (Sean Turner)**
    *   **Open Issue:** Can a flag bit sent in a `ClientHello` (indicating support for an extension) lead to a full extension response with actual content from the server, rather than just the same flag bit?
    *   **Discussion:** There were differing views (Ecker for flexibility, Martin for simplicity). No strong consensus emerged on the mailing list prior to the meeting.
    *   **Consensus:** It was decided to bring the issue to a head with a show of hands.

## Decisions and Action Items

*   **Well-Known ECH Keys:**
    *   **Decision:** Ben Schwartz and Rich will join as co-authors.
    *   **Action Item:** Chairs to discuss creating a GitHub repository for the draft.
    *   **Action Item:** Target WG Last Call around the time of ECH publication.
    *   **Action Item:** Authors to consider the explicit warning about the limited use case (DNS server to HTTP server only) and avoid generic client use.
    *   **Action Item:** Authors to consider registering as a provisional experimental document via RFC 8615.

*   **TLS Registry Update (8447bis):**
    *   **Action Item:** Shawn to revise the draft based on feedback, particularly regarding the 'D' and 'N' classifications for algorithms (e.g., anonymous signatures, DSA, SHA224, elliptic curve types). Shawn agreed to incorporate feedback.

*   **Deprecated Obsolete Exchange Methods:**
    *   **Action Item:** Nimrod to summarize the discussion points and take them to the mailing list for further discussion.

*   **SVCB Validation Requests for DTLS:**
    *   **Action Item:** Chairs will convene and take the request for Working Group adoption to the mailing list.

*   **TLS Attestation:**
    *   **Action Item:** Hannes to revise the draft (01 version), clarify terminology (evidence vs. attestation results), and thoroughly address privacy considerations.
    *   **Action Item:** Hannes to post a white paper from the Confidential Computing Consortium to the mailing list to provide more context on use cases.

*   **TLS Flags Extension:**
    *   **Decision:** The Pull Request disallowing non-flag responses (i.e., a flag bit cannot elicit a full extension response with content) will be merged based on a 15-7 virtual show of hands.

## Next Steps

*   **CTLS:** Continue refining the draft, particularly addressing the omission of empty messages and clarifying the relationship with DTLS 1.3 through prototyping.
*   **Well-Known ECH Keys:** Develop the draft with new co-authors, explore GitHub repo, and prepare for WG Last Call aligned with ECH. Further investigate caching, generic approaches, and wording for port types.
*   **TLS Registry Update:** Implement revisions to the 8447bis draft.
*   **Deprecated Obsolete Exchange Methods:** Continue discussion on the mailing list regarding FF-DHE groups and client abort behavior.
*   **TLS Attestation:** Further develop the draft, focusing on privacy, use cases, and terminology.
*   **Post-Quantum Cryptography:** Continue to monitor NIST's process, participate in relevant workshops (e.g., NIST workshop in November, PQNet), and conduct further research and experiments into the network and performance implications of PQC algorithms in TLS/QUIC, especially regarding message sizes and round-trip times.