[TLS] I-D Action: draft-ietf-tls-esni-14.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : TLS Encrypted Client Hello Authors : Eric Rescorla Kazuho Oku Nick Sullivan Christopher A. Wood Filename: draft-ietf-tls-esni-14.txt Pages : 48 Date: 2022-02-13 Abstract: This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tlswg/draft-ietf-tls-esni (https://github.com/tlswg/draft-ietf-tls-esni). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-tls-esni-14.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-esni-14 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)
Hi TLS WG, This draft draft-kampanakis-tls-scas-latest is attempting to resurrect Martin’s original draft-thomson-tls-sic. It proposes using two new TLS 1.3 flags (draft-ietf-tls-tlsflags ) to signal to the TLS server or client to not send its Intermediate CA (ICA) certificates. It assumes that we can pre-cache or load all the necessary intermediate CAs in order to build the cert chains to authenticate peers. As a data point, the size of a full ICA cache for the web would be 1-2MB (1-2 thousand ICAs) based on testing and 3rd party data [7][8]. 1-2MB is trivial for most usecases. When it is not, other caching mechanisms can be used. The main usecases that would benefit from this would be - post-quantum (D)TLS (PQ certs are going to be big and thus introduce issues for (D)TLS and QUIC [1][2][3][4]). - EAP-TLS in cases with big cert chains [5][6] - constrained environments where even a few KB in a (D)TLS handshake matter We believe we have addressed the comments regarding the original draft https://mailarchive.ietf.org/arch/browse/tls/?q=draft-thomson-tls-sic Feedback and discussion are welcome. Rgs, Panos [1] https://blog.cloudflare.com/sizing-up-post-quantum-signatures/ [2] https://www.ndss-symposium.org/ndss-paper/post-quantum-authentication-in-tls-1-3-a-performance-study/ [3] https://dl.acm.org/doi/10.1145/3386367.3431305 [4] https://assets.amazon.science/00/f8/aa76ff93472d9b55b6a84716e34c/speeding-up-post-quantum-tls-handshakes-by-suppressing-intermediate-ca-certificates.pdf [5] https://datatracker.ietf.org/doc/html/draft-ietf-emu-eaptlscert [6] https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13 [7] https://github.com/FiloSottile/intermediates [8] https://ccadb-public.secure.force.com/mozilla/MozillaIntermediateCertsCSVReport -Original Message- From: internet-dra...@ietf.org Sent: Sunday, February 13, 2022 2:34 PM To: Bas Westerbaan ; Bytheway, Cameron ; Martin Thomson ; Kampanakis, Panos Subject: [EXTERNAL] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. A new version of I-D, draft-kampanakis-tls-scas-latest-00.txt has been successfully submitted by Panos Kampanakis and posted to the IETF repository. Name: draft-kampanakis-tls-scas-latest Revision: 00 Title: Suppressing CA Certificates in TLS 1.3 Document date: 2022-02-13 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/archive/id/draft-kampanakis-tls-scas-latest-00.txt Status: https://datatracker.ietf.org/doc/draft-kampanakis-tls-scas-latest/ Htmlized: https://datatracker.ietf.org/doc/html/draft-kampanakis-tls-scas-latest Abstract: A TLS client or server that has access to the complete set of published intermediate certificates can inform its peer to avoid sending certificate authority certificates, thus reducing the size of the TLS handshake. The IETF Secretariat ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)
On Mon, Feb 14, 2022 at 03:33:05AM +, Kampanakis, Panos wrote: > Hi TLS WG, > > This draft draft-kampanakis-tls-scas-latest is attempting to resurrect > Martin’s original draft-thomson-tls-sic. It proposes using two new TLS > 1.3 flags (draft-ietf-tls-tlsflags ) to signal to the TLS server or > client to not send its Intermediate CA (ICA) certificates. > > Feedback and discussion are welcome. > > -Original Message- > From: internet-dra...@ietf.org > Sent: Sunday, February 13, 2022 2:34 PM > To: Bas Westerbaan ; Bytheway, Cameron > ; Martin Thomson ; Kampanakis, Panos > > Subject: [EXTERNAL] New Version Notification for > draft-kampanakis-tls-scas-latest-00.txt > > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you can confirm the sender and know the > content is safe. > > > > A new version of I-D, draft-kampanakis-tls-scas-latest-00.txt > has been successfully submitted by Panos Kampanakis and posted to the IETF > repository. > > Name: draft-kampanakis-tls-scas-latest > Revision: 00 > Title: Suppressing CA Certificates in TLS 1.3 > Document date: 2022-02-13 > Group: Individual Submission > Pages: 10 > URL: > https://www.ietf.org/archive/id/draft-kampanakis-tls-scas-latest-00.txt > Status: > https://datatracker.ietf.org/doc/draft-kampanakis-tls-scas-latest/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-kampanakis-tls-scas-latest > Some quick comments: 1) There are a few "shall" in the text. Should those be "SHALL"? 2) Section 3.2: "To prevent a failed TLS connection, a client could chose to not send its intermediates regardless of the flag from the server, if it has a reason to believe the issuing CAs do not exist in the server ICA list." ... Shouldn't the client send its intermediates if it thinks the server does not have them. 3) Why there are two flags? I do not see a case where both would be sent in the same message. 4) In WebPKI, there are some cornercases (constrained ICAs) where the client might be missing a certificate or certificates in the chain. Currently the WebPKI root program rules allow not disclosing "technically constrained" certificates (but there are plans to change this). 5) In the client auth scenario, the server might have exhaustive list of all issuing ICAs it accepts, so including any ICAs is never necressary. However, this might be handled even currently by not giving the client a chain. However, doing this in other direction can be quite dangerous without prior agreement. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
