Re: [TLS] [Pqc] Did TLS AuthKEM die?

Thank you Uri. Then what about CAKE-HI vs. EDHOC? By the way is there any specification of CAKE-HI available? Best regards, Loïc Ferreira Orange Restricted De : Blumenthal, Uri - 0553 - MITLL Envoyé : jeudi 26 janvier 2023 21:08 À : FERREIRA Loïc INNOV/IT-S ; Thom Wiggers Cc : Jo

[TLS] I-D Action: draft-ietf-tls-tlsflags-11.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 : A Flags Extension for TLS 1.3 Author : Yoav Nir Filename: draft-ietf-tls-tlsflags-11.txt

Re: [TLS] about hash and post-quantum ciphers

Hi, I don't think non-standardized algorithms should be adopted by the WG. Even for just assigning a number, a good first step would be CFRG. But this mail got me thinking: - I think the lack of hash algorithm crypto agility in TLS 1.3 is unsatisfactory. The _only_ option in TLS 1.3 is SHA2.

Re: [TLS] about hash and post-quantum ciphers

John, I agree with all of your points. TNX P.S. Maybe it would be good for NIST to standardize BLAKE3. But until it does – … -- V/R, Uri There are two ways to design a system. One is to make it so simple there are obviously no deficiencies. The other is to make it so complex there

Re: [TLS] about hash and post-quantum ciphers

+1 on starting to see a little SHA-3 trickle down to TLS, IPsec, SSH and more common protocols. From: TLS On Behalf Of John Mattsson Sent: Friday, January 27, 2023 6:25 AM To: tls@ietf.org Cc: hojarasca2022 ; Salz, Rich Subject: RE: [EXTERNAL][TLS] about hash and post-quantum ciphers CAUTIO

Re: [TLS] [Pqc] Did TLS AuthKEM die?

Thank you Uri. My pleasure. Then what about CAKE-HI vs. EDHOC? Ah, a good question – with a less-technical answer. Without getting into details – EDHOC is still more “verbose” than CAKE-HI, thus – not “minimalistic” (which was one of our design goals). At this point, EDHOC is not

Re: [TLS] [Pqc] Did TLS AuthKEM die?

Blumenthal, Uri wrote: >Without getting into details – EDHOC is still more “verbose” than CAKE-HI, >thus – not >“minimalistic” (which was one of our design goals). The overhead except key shares and MACs in EDHOC is typically 21 bytes. If your protocol uses the NIST PQC algorithms with their

Re: [TLS] [Pqc] Did TLS AuthKEM die?

>Without getting into details – EDHOC is still more “verbose” than CAKE-HI, >thus – not >“minimalistic” (which was one of our design goals). The overhead except key shares and MACs in EDHOC is typically 21 bytes. If your protocol uses the NIST PQC algorithms with their large public keys and

[TLS] Security of using same cert for TLS client and server

Hi, TLS WG went through a lot of work (RFC 9258) to make sure that PSKs only be used with a single hash function. But as far as I can see the RFC8446(bis) does not say anything about: * Using the same cert for TLS client and TLS server * Using the same public key cert for TLS and anoth

Re: [TLS] about hash and post-quantum ciphers

On Fri, Jan 27, 2023 at 11:24:59AM +, John Mattsson wrote: > Hi, > > I don't think non-standardized algorithms should be adopted by the > WG. Even for just assigning a number, a good first step would be CFRG. Well, getting adopted by the WG isn't a requirement for those to wind up with a numb

Re: [TLS] about hash and post-quantum ciphers

>> I don't think non-standardized algorithms should be adopted by the >> WG. Even for just assigning a number, a good first step would be CFRG. > Well, getting adopted by the WG isn't a requirement for those to wind up > with a number... There is expert review process as well. The requirements fo

Re: [TLS] Security of using same cert for TLS client and server

On Fri, Jan 27, 2023 at 06:01:04PM +, John Mattsson wrote: > Hi, > > - Using the same signature key or PSK for TLS and another protocol is > obviously unsecure in the worst case. But probably practically > secure in many cases even if nobody has proved it. Well, looking at the signatures: