[TLS] Weekly github digest (TLS Working Group Drafts)
Issues -- * tlswg/draft-ietf-tls-esni (+0/-1/💬5) 2 issues received 5 new comments: - #628 DNS issues from AD review. (4 by bemasc, ekr, paulwouters) https://github.com/tlswg/draft-ietf-tls-esni/issues/628 - #626 Proxy Mode (1 by ekr) https://github.com/tlswg/draft-ietf-tls-esni/issues/626 1 issues closed: - Proxy Mode https://github.com/tlswg/draft-ietf-tls-esni/issues/626 * tlswg/tls13-spec (+1/-0/💬3) 1 issues created: - HKDF label budget in 7.1 is off by 9 (by pkelsey) https://github.com/tlswg/tls13-spec/issues/1365 1 issues received 3 new comments: - #1365 HKDF label budget in 7.1 is off by 9 (3 by ekr, ilaril, pkelsey) https://github.com/tlswg/tls13-spec/issues/1365 Pull requests - * tlswg/draft-ietf-tls-svcb-ech (+0/-0/💬1) 1 pull requests received 1 new comments: - #18 Add a variety of examples (1 by seanturner) https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/18 * tlswg/rfc8447bis (+1/-0/💬0) 1 pull requests submitted: - A few WGLC nits (by richsalz) https://github.com/tlswg/rfc8447bis/pull/58 * tlswg/tls-key-update (+1/-2/💬1) 1 pull requests submitted: - Update to Exporter (by tireddy2) https://github.com/tlswg/tls-key-update/pull/10 1 pull requests received 1 new comments: - #9 Update draft-ietf-tls-extended-key-update.md (1 by hannestschofenig) https://github.com/tlswg/tls-key-update/pull/9 2 pull requests merged: - Update to Exporter https://github.com/tlswg/tls-key-update/pull/10 - Update draft-ietf-tls-extended-key-update.md https://github.com/tlswg/tls-key-update/pull/9 Repositories tracked by this digest: --- * https://github.com/tlswg/certificate-compression * https://github.com/tlswg/dnssec-chain-extension * https://github.com/tlswg/draft-deprecate-obsolete-kex * https://github.com/tlswg/draft-ietf-tls-cert-abridge * https://github.com/tlswg/draft-ietf-tls-ctls * https://github.com/tlswg/draft-ietf-tls-ecdhe-psk-aead * https://github.com/tlswg/draft-ietf-tls-ech-keylogfile * https://github.com/tlswg/draft-ietf-tls-esni * https://github.com/tlswg/draft-ietf-tls-external-psk-importer * https://github.com/tlswg/draft-ietf-tls-grease * https://github.com/tlswg/draft-ietf-tls-iana-registry-updates * https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate * https://github.com/tlswg/draft-ietf-tls-semistatic-dh * https://github.com/tlswg/draft-ietf-tls-svcb-ech * https://github.com/tlswg/draft-ietf-tls-ticketrequest * https://github.com/tlswg/draft-ietf-tls-tls13-vectors * https://github.com/tlswg/dtls-conn-id * https://github.com/tlswg/dtls-rrc * https://github.com/tlswg/dtls13-spec * https://github.com/tlswg/oldversions-deprecate * https://github.com/tlswg/rfc4492bis * https://github.com/tlswg/rfc8447bis * https://github.com/tlswg/sniencryption * https://github.com/tlswg/sslkeylogfile * https://github.com/tlswg/sslv3-diediedie * https://github.com/tlswg/tls13-spec * https://github.com/tlswg/tls-exported-authenticator * https://github.com/tlswg/tls-flags * https://github.com/tlswg/tls-key-share-prediction * https://github.com/tlswg/tls-key-update * https://github.com/tlswg/tls-record-limit * https://github.com/tlswg/tls-subcerts * https://github.com/tlswg/tls12-frozen * https://github.com/tlswg/tls13-pkcs1 * https://github.com/tlswg/tls13-rfc ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] I-D Action: draft-ietf-tls-extended-key-update-02.txt
Internet-Draft draft-ietf-tls-extended-key-update-02.txt is now available. It is a work item of the Transport Layer Security (TLS) WG of the IETF. Title: Extended Key Update for Transport Layer Security (TLS) 1.3 Authors: Hannes Tschofenig Michael Tüxen Tirumaleswar Reddy Steffen Fries Yaroslav Rosomakho Name:draft-ietf-tls-extended-key-update-02.txt Pages: 16 Dates: 2024-10-20 Abstract: The Transport Layer Security (TLS) 1.3 specification offers a dedicated message to update cryptographic keys during the lifetime of an ongoing session. The traffic secret and the initialization vector are updated directionally but the sender may trigger the recipient, via the request_update field, to transmit a key update message in the reverse direction. In environments where sessions are long-lived, such as industrial IoT or telecommunication networks, this key update alone is insufficient since forward secrecy is not offered via this mechanism. Earlier versions of TLS allowed the two peers to perform renegotiation, which is a handshake that establishes new cryptographic parameters for an existing session. When a security vulnerability with the renegotiation mechanism was discovered, RFC 5746 was developed as a fix. Renegotiation has, however, been removed from version 1.3 leaving a gap in the feature set of TLS. This specification defines an extended key update that supports forward secrecy. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-extended-key-update/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-tls-extended-key-update-02 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-extended-key-update-02 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Consensus call for RFC8773bis Formal Analysis Requirement
Hi Russ, The recommendation in [1], which I very much agree with, is to continuously perform ephemeral key exchange at frequent intervals and to chain connections together, forcing an adversary to break them in sequence. Today, you can chain TLS 1.3 connections together by doing resumption, but resumption cannot be combined with certificate-based reauthentication, which is a must as soon as one of the certificates expire and is replaced. To address this I strongly think draft-ietf-tls-8773bis should allow both external and resumption PSKs. I don't see any reason to restrict the type of PSK. Thanks BTW for driving this kind of functionality for high-security use cases. I think this will be useful in 3GPP interfaces. If there is any GitHub repository for the draft, I am happy to suggest updates in a PR. Cheers, John [1] Ekerå, "On factoring integers, and computing discrete logarithms and orders, quantumly" http://kth.diva-portal.org/smash/get/diva2:1902626/FULLTEXT01.pdf From: John Mattsson Date: Saturday, 19 October 2024 at 16:19 To: Eric Rescorla , Russ Housley Cc: IETF TLS Subject: [TLS] Re: Consensus call for RFC8773bis Formal Analysis Requirement Hi, I think this is a very straightforward way to introduce hybrid keying to TLS 1.3. I think this extension will increase the use of TLS 1.3 in national security systems, which I think is very welcome. This kind of hybrid keying / defense-in depth is exactly what is recommended in the excellent PhD thesis by Martin Ekerå [1], who is also chief cryptographer of the Swedish NCSA. As long as the extension does not alter the certificate authentication or the ephemeral key exchange, I do not see any way it could lower the security, but I am not against formal analysis. I am satisfied with the Privacy Considerations section and would like to see this draft published as proposed standard. Some comments on draft-ietf-tls-8773bis-02: - - - "There are two motivations for using a certificate with an external PSK." For national security systems, I think it is motivated to always use hybrid keying, combining symmetric keying with post-quantum secure asymmetric keying. The recommendation in [1] is to combine symmetric keying, post-quantum secure asymmetric keying, and classically secure asymmetric keying, as a defense-in depth. See Algorithm 1 and Figure A.1 of [1]. - - - "but it will take many years for TLS 1.3 ciphersuites that use these algorithms to be developed and deployed" X25519MLKEM768 already seem developed and deployed. - - - "Since the "tls_cert_with_extern_psk" extension is intended to be used only with initial handshakes, it MUST NOT be sent alongside the "early_data" extension." I don't think the MUST NOT follows from that "tls_cert_with_extern_psk" is intended to be used only with initial handshakes. External PSKs can be used with "early_data" in the initial handshake according to RFC 8446. Suggestion: NEW: "tls_cert_with_extern_psk" MUST NOT be sent alongside the "early_data" extension." - - - "However, TLS 1.3 does not permit an external PSK to be used in the same fashion as a resumption PSK, and this extension does not alter those restrictions" I don't know what these restrictions on external PSK are and I could not find them in RFC 8446. - - - "For protection against the future invention of a CRQC, the symmetric key needs to be at least 128 bits It needs to be at least 128 bits to protect against classic computers as well. The sentence is also duplicated in the following paragraph. Suggestion: NEW "For protection against the future attacks, the symmetric key needs to be at least 128 bits" - - - "the advantage of Grover’s algorithm will be smaller." I don't think Grover's will ever have any practical advantage. In addition to cost and parallelization, two additional factors mentioned in footnote 18 of [1] are: "large-scale fault-tolerant quantum computers as currently envisaged are very slow compared to classical computers" "The overheads incurred by the need to employ quantum error correction to achieve fault tolerance are furthermore substantial." - - - - "If the external PSK is known to any party other than the client and the server, then the external PSK MUST NOT be the sole basis for authentication. I think certificate-based server authentication SHALL be used even if the external PSK is known only be the client and the server. - - - "In addition, clients MAY also include psk_ke mode to support a subsequent NewSessionTicket." I think this draft focusing on hybrid keying in high-security systems should forbid psk_ke. - - - Cheers, John [1] Ekerå, "On factoring integers, and computing discrete logarithms and orders, quantumly" http://kth.diva-portal.org/smash/get/diva2:1902626/FULLTEXT01.pdf ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
