Re: [TLS] Transcript ambiguity in cTLS

2022-07-26 Thread Ilari Liusvaara
On Mon, Jul 25, 2022 at 06:47:53PM -0400, Ben Schwartz wrote: > I noticed some confusion today about the topic of ambiguous > transcripts in cTLS. My claim was not that any single cTLS profile > has an ambiguous transcript. If such a thing were true, I believe > that would be a bug in the cTLS sp

[TLS] PQC key exchange sizes

2022-07-26 Thread Thom Wiggers
Hi all, In yesterday’s working group meeting we had a bit of a discussion of the impact of the sizes of post-quantum key exchange on TLS and related protocols like QUIC. As we neglected to put Kyber’s key sizes in our slide deck (unlike the signature schemes), I thought it would be a good idea to

Re: [TLS] PQC key exchange sizes

2022-07-26 Thread Ilari Liusvaara
On Tue, Jul 26, 2022 at 02:15:34PM +0200, Thom Wiggers wrote: > > In yesterday’s working group meeting we had a bit of a discussion of the > impact of the sizes of post-quantum key exchange on TLS and related > protocols like QUIC. As we neglected to put Kyber’s key sizes in our slide > deck (unli

[TLS] I-D Action: draft-ietf-tls-tlsflags-10.txt

2022-07-26 Thread internet-drafts
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 : A Flags Extension for TLS 1.3 Author : Yoav Nir Filename: draft-ietf-tls-tlsflags-10.txt

Re: [TLS] PQC key exchange sizes

2022-07-26 Thread Stephen Farrell
On 26/07/2022 13:15, Thom Wiggers wrote: Hi all, In yesterday’s working group meeting we had a bit of a discussion of the impact of the sizes of post-quantum key exchange on TLS and related protocols like QUIC. As we neglected to put Kyber’s key sizes in our slide deck (unlike the signature sc

Re: [TLS] PQC key exchange sizes

2022-07-26 Thread Martin Thomson
On Tue, Jul 26, 2022, at 11:21, Stephen Farrell wrote: > Be interested in how that'd change the CH if ECH is used too. > I guess the answer mightn't make us happy;-) PQ HPKE would not fit, but the Kyber-512 numbers mean that we should be OK for ECH if we stuck with classical security. For obviou

Re: [TLS] PQC key exchange sizes

2022-07-26 Thread Blumenthal, Uri - 0553 - MITLL
What are the implications for environments that require NIST Sec Level 3 or 5? Regards, Uri > On Jul 26, 2022, at 11:33, Martin Thomson wrote: > > On Tue, Jul 26, 2022, at 11:21, Stephen Farrell wrote: >> Be interested in how that'd change the CH if ECH is used too. >> I guess the answer might

Re: [TLS] PQC key exchange sizes

2022-07-26 Thread Martin Thomson
On Tue, Jul 26, 2022, at 11:42, Blumenthal, Uri - 0553 - MITLL wrote: > What are the implications for environments that require NIST Sec Level 3 or 5? Poor performance. By which I mean increased exposure to packet loss and additional round trips. For instance, in QUIC servers might be forced to

Re: [TLS] Extensibility in SCVP draft

2022-07-26 Thread Ashley Kopman
Rob, I apologize, I am not sure that I fully understand your question. I originally created the structure of path_validation_type to make it easier in the future to potentially expand the extension to use other protocols for path validation. But Martin, Rich and Russ pointed out that this likel

Re: [TLS] Extensibility in SCVP draft

2022-07-26 Thread Rob Sayre
On Tue, Jul 26, 2022 at 9:08 AM Ashley Kopman wrote: > > Are you concerned that if additional validation extensions were added it > could lead to multiple validations for the same handshake? If that is the > case, I believe that this is somewhat mitigated by it being optional for > the server to

Re: [TLS] Extensibility in SCVP draft

2022-07-26 Thread Ashley Kopman
That is a good suggestion. I will look into expanding on the text to address this concern. Thank you, Ashley > On Jul 26, 2022, at 1:33 PM, Rob Sayre wrote: > > On Tue, Jul 26, 2022 at 9:08 AM Ashley Kopman > wrote: > > Are you concerned that if additional

Re: [TLS] PQC key exchange sizes

2022-07-26 Thread Kampanakis, Panos
Hi Ilari, > - DTLS-level fragmentation. There are buggy implementations that break if one > tries this. DTLS servers have been fragmenting and sending cert chains that don’t fit in the MTU for a long time. Is this buggy on the TLS client side? Any public info you can share about these buggy im