[TLS] Adoption call for draft-salowey-tls-rfc8447bis
Hi folks, Following up on the TLS WG meeting in IETF 112 and draft update in December, this email begins an adoption call for draft-salowey-tls-rfc8447bis, located here: https://datatracker.ietf.org/doc/draft-salowey-tls-rfc8447bis/ This adoption call will last for two weeks. Please reply to this email by March 4 indicating whether you think this document should be adopted and worked on by the WG. Thanks, Chris ___ 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 Fri, Feb 18, 2022 at 04:47:09AM +, Kampanakis, Panos wrote: > > About the tlsflags, make sense. It would simplify things too. The > impression I got from the old draft-thomson-tls-sic thread and the > tlsflags draft was that it mandates an acknowledgement. I will > confirm with Yoav. The text in tlsflags looks like it mandates an acknowledgement, but I think it might be just confusing text. Regarding actual need for acknowledgement for this flag, I think that server acknowledging it could be useful so client knows if retrying without flag could be useful or not. For the client acknowledging it, I find that much less useful. If server proposes the extension, it better have exhaustive issuer list, be using certificates as just holders for raw public keys, or using certificate fingerprints for identification. Anything else looks like it is asking for trouble. -Ilari ___ 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)
> > I'm not sure I would agree that a 3-8 MB handshake to preserve the status > quo is exactly low hanging fruit. > If we use Dilithium2 for every signature, we're looking at about 17kB extra — not 3-8MB. ICA suppression removes one public key and signature, so 3.7kB. This is where looking to see what can be done to remove the necessity of > those SCTs and OCSPs, rather than trying to patch them into a PQ world. > If Rainbow or GeMMS doesn't make the cut, then replacing SCTs by inclusion proofs (to some daily picked side-loaded STHs) could be interesting (as they're ~1kB each), but that's not low hanging fruit. > The viability of CT itself becomes more suspect in a world of ginormous > signatures, > Dilithium2 and Falcon signatures+public keys are 2.4+1.3kB and 666+897B respectively. That won't cause trouble for CT. Best, Bas ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
