On Mon, Feb 14, 2022 at 03:33:05AM +0000, 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 <internet-dra...@ietf.org> > Sent: Sunday, February 13, 2022 2:34 PM > To: Bas Westerbaan <b...@cloudflare.com>; Bytheway, Cameron > <byth...@amazon.com>; Martin Thomson <m...@lowentropy.net>; Kampanakis, Panos > <kpa...@amazon.com> > 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
