Thanks John. Good points about draft-ietf-tls-subcerts. I am tracking it in git and will update.
Before bringing the draft up for discussion again, we are trying to quantify the "stale ICA cache causing TLS connection failures for the web", as this was a concern the group brought up. Getting this data is not straightforward, I must say. From: John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org> Sent: Thursday, November 24, 2022 6:04 AM To: Kampanakis, Panos <kpa...@amazon.com>; tls@ietf.org Cc: Bytheway, Cameron <byth...@amazon.com> Subject: [EXTERNAL] [UNVERIFIED SENDER] Re: New Version Notification for draft-kampanakis-tls-scas-latest-01.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. Hi, I think this is great work and something the TLS WG should adopt and work on. Reducing the total number of bytes is very important not only in constrained IoT, but also in TLS based EAP methods, and in applications where handshake time to completion is important. I quicky read the -02 draft. It seems to be in a good shape. Some comments: - I think it would be good if the draft described how it works with draft-ietf-tls-subcerts. While the latest version of draft-ietf-tls-subcerts talks about "delegated credential" and not certifcates, they are commonly refered to as subcerts. - I think draft-kampanakis-tls-scas-latest could considered allowing suppressing also the end-entity certificate for use cases when draft-ietf-tls-subcerts is used. Cheers, John From: TLS <tls-boun...@ietf.org<mailto:tls-boun...@ietf.org>> on behalf of Kampanakis, Panos <kpanos=40amazon....@dmarc.ietf.org<mailto:kpanos=40amazon....@dmarc.ietf.org>> Date: Friday, 4 March 2022 at 16:42 To: tls@ietf.org<mailto:tls@ietf.org> <tls@ietf.org<mailto:tls@ietf.org>> Cc: Bytheway, Cameron <byth...@amazon.com<mailto:byth...@amazon.com>> Subject: Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-01.txt Hi all, The updated -01 version fixes a couple of nits identified by Ilari, removes the needs for two different tlsflags, one each direction, and does not require an acknowledgement of the ICA suppression tlsflag based on discussions about the tlsflags draft https://mailarchive.ietf.org/arch/msg/tls/SIvCO_ZFmNfTEeyiuZOcdBzTdAo/ There are more issues we are tracking based on discussions in this list https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-24c7ac234ac8e19f&q=1&e=76ac0dba-b0c6-4ac8-9538-5faabd060cb2&u=https%3A%2F%2Fgithub.com%2Fcsosto-pk%2Ftls-suppress-intermediates%2Fissues -----Original Message----- From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> Sent: Friday, March 4, 2022 10:34 AM To: Bas Westerbaan <b...@cloudflare.com<mailto:b...@cloudflare.com>>; Bytheway, Cameron <byth...@amazon.com<mailto:byth...@amazon.com>>; Martin Thomson <m...@lowentropy.net<mailto:m...@lowentropy.net>>; Kampanakis, Panos <kpa...@amazon.com<mailto:kpa...@amazon.com>> Subject: [EXTERNAL] New Version Notification for draft-kampanakis-tls-scas-latest-01.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-01.txt has been successfully submitted by Panos Kampanakis and posted to the IETF repository. Name: draft-kampanakis-tls-scas-latest Revision: 01 Title: Suppressing CA Certificates in TLS 1.3 Document date: 2022-03-04 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/archive/id/draft-kampanakis-tls-scas-latest-01.txt Status: https://datatracker.ietf.org/doc/draft-kampanakis-tls-scas-latest/ Htmlized: https://datatracker.ietf.org/doc/html/draft-kampanakis-tls-scas-latest Diff: https://www.ietf.org/rfcdiff?url2=draft-kampanakis-tls-scas-latest-01 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<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
