[TLS] I-D Action: draft-ietf-tls-deprecate-obsolete-kex-05.txt
Internet-Draft draft-ietf-tls-deprecate-obsolete-kex-05.txt is now available. It is a work item of the Transport Layer Security (TLS) WG of the IETF. Title: Deprecating Obsolete Key Exchange Methods in TLS 1.2 Authors: Carrick Bartle Nimrod Aviram Name:draft-ietf-tls-deprecate-obsolete-kex-05.txt Pages: 21 Dates: 2024-09-03 Abstract: This document deprecates the use of RSA key exchange and Diffie Hellman over a finite field in TLS 1.2, and discourages the use of static elliptic curve Diffie Hellman cipher suites. Note that these prescriptions apply only to TLS 1.2 since TLS 1.0 and 1.1 are deprecated by RFC 8996 and TLS 1.3 either does not use the affected algorithm or does not share the relevant configuration options. This document updates RFCs 9325, 4346, 5246, 4162, 6347, 5932, 5288, 6209, 6367, 8422, 5289, 5469, 4785, 4279, 5487, 6655, and 7905. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-tls-deprecate-obsolete-kex-05.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-deprecate-obsolete-kex-05 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] ECH Proxy Mode
Hi, In the split mode of the current draft of ECH, both the client-facing server and the backend server are needed to be ECH-aware. As upon the client-facing server decrypted the ClientHelloOut, it will forward the ClientHelloInner to the backend server, and waiting the backend's ServerHello with random embed with the accept_confirmation. If you want to deploy ECH, you have to upgrade both the client-facing server and the backend server. However, it is not an easy task to upgrade all the backend server in one day. So I am wondering if it is possible to adjust the design to allow the deployment without altering the backend server. Suppose we use the following topology: browser <-> ECH-aware Client-facing server <--> normal TLS backend server For any TLS backend server, for example, https://example.com, We only upgrade the browser and the client-facing server. The browser fetch the ECH config from DNS, and encrypt the ClientHello according the current draft design. The client-facing decrypt the ClientHelloInner and use it as the normal ClientHello to do the TLS handshake to the normal TLS backend server without any ECH extension. Upon the normal TLS backend server receive the decrypted ClientHello, it response the normal ServerHello to the client-facing server. After receiving the ServerHello from the backend server, the client-facing server need to response the accept_confirmation to the browser. This is the design changes I propose to change. Because the current draft requires the backed server generate the accept_confirmation bytes and embed it into the random of ServerHello, which can not be changed by the client-facing server. In order to support ECH for normal existing TLS server, we may let the client-facing response the accept_confirmation on behalf of the backend server, which means we can not use the random field of ServerHello to store the accept_confirmation, because changing it will abort the TLS handshake. So is it possible to transfer the accept_confirmation in some plain text extensions like Key Share, or other dedicated extension? If it is possible, we can deploy ECH by only upgrading the browser and client-facing server without require change all the existing backend server. This idea was derived from my attempt to implement encrypted TLS SNI Proxy. The SNI does not only expose privacy information, many ISP use it to block certain web site. Even though the current draft of ECH works to protect the ClientHello, it can only protect the sites that deployed the ECH. If we can adjust the current design and let the client-facing generate and response the accept_confirmation signal, we can make ECH everywhere without upgrading any of current TLS backend server. Which means the client-facing can work as an encrypted TLS SNI Proxy. Please consider my proposal and give your comments Thanks. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Consensus Call: -rfc8446bis PRs #1360
Hi! Reminder that this consensus call is still ongoing. spt > On Aug 26, 2024, at 09:23, Sean Turner wrote: > > Hi! Loganaden submitted a PR to add x25519 as an MTI in TLS 1.3 that > addresses an Issue submitted by Stephen; links to both follow: > Issue: https://github.com/tlswg/tls13-spec/issues/1359 > PR: https://github.com/tlswg/tls13-spec/pull/1360 > > As this has been suggested post WGLC, we need to ensure we have consensus to > merge this PR. We did spend some time on this (and other -rfc8446bis) PRs at > IETF 120. At the session, we did a poll to 1st determine whether it is > appropriate to make this change in this I-D, which > was supposed to be just for clarifications. The result of the poll was to not > make this change. To verify this, please review the PR in its entirety and > indicate whether you support not merging this PR by 9 September 23:59 UTC. > > Cheers, > spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] PAVeTrust @ FM24 call for (virtual) participation: Formal methods for standardization
Dear all, I thought PAVeTrust [1], co-located with FM24 [2], might be of interest to some of you to see how formal methods are shaping some of the standardization efforts in RATS, TLS and OAuth WGs. Invited talks are: * Secure Authentication in the Era of Confidential Computing: Insights from the Formal Analysis of OAuth by *Hannes Tschofenig* (University of Applied Sciences Bonn-Rhein-Sieg/Siemens, Germany) * Remote Attestation and Formal Methods - the bigger picture by *Ian Oliver* (University of Oulu, Finland) * Formal Verification of the Realm Management Monitor (RMM) by *Eleni Vafeiadi Bila* (Arm) * Beyond the Surface: Validation Challenges and Opportunities for Confidential Computing by *Jo Van Bulck* (KU Leuven, Belgium) Additionally, I will present ongoing formalization of attested TLS. See the complete program and abstracts of talks at [3]. In case you cannot attend PAVeTrust in person, we have negotiated a registration fees of only 50 Euros for virtual attendance. To get the discount code, please contact the FM co-chairs Matteo G. Rossi and Matteo Pradella and register [4] using that code. The workshop has no formal proceedings. It aims to initiate the much-needed discussions between the different communities. We have, therefore, requested the invited speakers to leave 15 minutes for Q&A and discussion. Workshop material (slides and papers) will only be available to registered attendees. If you have questions, please do not hesitate to contact us. Best Regards, Usama and Pedro Organizers PAVeTrust'24 [1] https://pavetrust.github.io/ [2] https://www.fm24.polimi.it/ [3] https://pavetrust.github.io/program/ [4] https://www.fm24.polimi.it/?page_id=559 ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] I-D Action: draft-ietf-tls-svcb-ech-05.txt
Internet-Draft draft-ietf-tls-svcb-ech-05.txt is now available. It is a work item of the Transport Layer Security (TLS) WG of the IETF. Title: Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings Authors: Ben Schwartz Mike Bishop Erik Nygren Name:draft-ietf-tls-svcb-ech-05.txt Pages: 7 Dates: 2024-09-03 Abstract: To use TLS Encrypted ClientHello (ECH) the client needs to learn the ECH configuration for a server before it attempts a connection to the server. This specification provides a mechanism for conveying the ECH configuration information via DNS, using a SVCB or HTTPS record. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-tls-svcb-ech-05.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-svcb-ech-05 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: I-D Action: draft-ietf-tls-deprecate-obsolete-kex-05.txt
I will be hitting the button to submit this to the IESG next week. The revisions based on the earlier consensus calls have been made and references to updated RFCs have been cleaned up. You can use the diffi tool to see the comparison with the -03 version - https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-deprecate-obsolete-kex-03&url2=draft-ietf-tls-deprecate-obsolete-kex-05&difftype=--html. Let me know if you spot any concerns with the document. Thanks, Joe On Tue, Sep 3, 2024 at 2:13 AM wrote: > Internet-Draft draft-ietf-tls-deprecate-obsolete-kex-05.txt is now > available. > It is a work item of the Transport Layer Security (TLS) WG of the IETF. > >Title: Deprecating Obsolete Key Exchange Methods in TLS 1.2 >Authors: Carrick Bartle > Nimrod Aviram >Name:draft-ietf-tls-deprecate-obsolete-kex-05.txt >Pages: 21 >Dates: 2024-09-03 > > Abstract: > >This document deprecates the use of RSA key exchange and Diffie >Hellman over a finite field in TLS 1.2, and discourages the use of >static elliptic curve Diffie Hellman cipher suites. > >Note that these prescriptions apply only to TLS 1.2 since TLS 1.0 and >1.1 are deprecated by RFC 8996 and TLS 1.3 either does not use the >affected algorithm or does not share the relevant configuration >options. > >This document updates RFCs 9325, 4346, 5246, 4162, 6347, 5932, 5288, >6209, 6367, 8422, 5289, 5469, 4785, 4279, 5487, 6655, and 7905. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/ > > There is also an HTML version available at: > > https://www.ietf.org/archive/id/draft-ietf-tls-deprecate-obsolete-kex-05.html > > A diff from the previous version is available at: > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-deprecate-obsolete-kex-05 > > 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 mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: ECH Proxy Mode
Hi, On 9/3/24 10:52 PM, 涛叔 wrote: This idea was derived from my attempt to implement encrypted TLS SNI Proxy. The SNI does not only expose privacy information, many ISP use it to block certain web site. Even though the current draft of ECH works to protect the ClientHello, it can only protect the sites that deployed the ECH. If we can adjust the current design and let the client-facing generate and response the accept_confirmation signal, we can make ECH everywhere without upgrading any of current TLS backend server. Which means the client-facing can work as an encrypted TLS SNI Proxy. I'm trying to understand what exactly your use-case here is. Wouldn't a naive HTTPS Proxy w/ CONNECT be sufficient? E.g. if we have the proxy domain `https://myproxy.com` , and the website we want to connect to is `https://supersecret.com`, then assuming a classic HTTPS Proxy running on `myproxy.com`, the Client would make a TLS handshake to `myproxy.com` and reveal the Proxy SNI, however once the TLS handshake with the proxy is complete, the `CONNECT` to `supersecret.com` will be inside the TLS tunnel, so it will be private. I think this would be sufficient, since even in the split-example with ECH you mention, the `public_name` of the first client-facing server will be visible anyway. Regards, Raghu Saxena OpenPGP_0xA1E21ED06A67D28A.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
