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

[loic.ferreira]

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 : John Mattsson ; Mike Ounsworth 
; p...@ietf.org; tls@ietf.org
Objet : Re: [Pqc] [TLS] Did TLS AuthKEM die?



How would you compare CAKE-HI and cTLS?



Loïc, an excellent question. Naturally, there are similarities and differences.



Similarities:

*   Both strive to reduce unnecessary communications;
*   Both strive to avoid unnecessary negotiations;
*   Both embrace "template-based specialization" that allows avoiding 
negotiations altogether (if I understood this part of cTLS correctly).



Differences:

*   Different purpose:

   *cTLS is a compact Transport Layer Security that protects user data, and 
includes key exchange (as one of the mechanisms it utilizes to achieve its 
goal).
   *CAKE-HI is a Key Exchange protocol that provides session keys (shared 
secret(s)) to other protocols that handle user data.

*   Different degree of "minimization", as CAKE-HI is much more 
minimalistic than cTLS:

   *cTLS tries to create a "leaner TLS" by paring the "fat" of TLS, 
backward-compatibility with TLS 1.2, etc. But quite a bit of TLS details 
remains there.
   *CAKE-HI has nothing in common with the TLS handshaking, options, 
syntax, fields, and such. It has a set of cryptographic primitives that it 
employs to generate symmetric shared secret and satisfy security properties 
listed below.

*   Thus, CAKE-HI cannot replace cTLS, (among other reasons) because by 
itself it does not provide user data protection (and requires another protocol, 
like SCIP to handle that), nor can cTLS "replace" CAKE-HI because it does a lot 
of things unnecessary for "pure" key exchange and carries more overhead than a 
truly minimalistic AKE needs.



On the sad part, CAKE-HI specification (actually, we'll most likely present 
CHAKE-HI, aka - Compact Hybrid Authenticated Key Exchange Hiding Identities) 
lags behind in details that have been provided in cTLS ID 
(https://www.ietf.org/archive/id/draft-ietf-tls-ctls-07.html). But we'll get 
there. ;-)



I realize the above is rather sketchy - please feel free to ask more questions, 
and I'll do my best to answer them.



Thanks!







Orange Restricted

De : Pqc mailto:pqc-boun...@ietf.org>> De la part de 
Blumenthal, Uri - 0553 - MITLL
Envoyé : mercredi 25 janvier 2023 22:49
À : Thom Wiggers mailto:t...@thomwiggers.nl>>
Cc : John Mattsson 
mailto:john.matts...@ericsson.com>>; Mike Ounsworth 
mailto:Mike.Ounsworth=40entrust@dmarc.ietf.org>>;
 p...@ietf.org; tls@ietf.org
Objet : Re: [Pqc] [TLS] Did TLS AuthKEM die?



I'll first ask the first question, and then try to clarify a few of the other 
things raised in this thread.



> Is AuthKEM dead?



I'd say it's hibernating. The draft has indeed expired: there was nothing 
significant to add since the last time we edited/updated it. I also couldn't 
make it to the last two IETF meetings (and due to conflict with Real World 
Crypto, I will most likely not be able to make IETF116 either). The TLS working 
group has seemed to want to focus on getting PQ key exchange out of the door, 
but if it's ready to continue the discussion on post-quantum authentication 
(which should include some other things like OCSP and CT), I'd be very happy to 
continue the discussion and work on AuthKEM.



We have a simplified protocol (CAKE-HI) inspired by and based on AuthKEM. Being 
simplified, CAKE is not really suitable for TLS. Thus, we'd like to see AuthKEM 
progressing within the TLS WG.



One change that we'd probably like to make soon is to include Kyber-based 
(hybrid / PQ/T) KEMs -- once those KEMs have been hammered out for the 
ephemeral key exchange.



Yes, something worth discussing.



I am currently working hard on wrapping up my PhD thesis* (which is largely on 
post-quantum TLS and KEMTLS in particular). This is another reason why the 
draft has been sitting there for a while. To me, right now, most of the 
"homework" behind the AuthKEM/KEMTLS proposal feels pretty "finished"; I'd 
argue we have some form of running code (as in the various KEMTLS experimental 
implementations we did for the academic work are pretty close to AuthKEM). We 
also have proofs, both pen-and-paper and two Tamarin models. If anyone has 
suggestions for concrete next steps, perhaps in which AuthKEM solves a problem 
that they're seeing, let us know.



But in the end, AuthKEM, as any IETF WG proposal, can't get pushed over the 
line by some ivory tower academic like myself --- we will need people coming 
out and saying they want to have this.



For TLS we want AuthKEM. For other protocols - we have a similar alternative. 
;-)



By the way, if anyone wants to discuss KEM-base

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

[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-11.txt
  Pages   : 9
  Date: 2023-01-27

Abstract:
   A number of extensions are proposed in the TLS working group that
   carry no interesting information except the 1-bit indication that a
   certain optional feature is supported.  Such extensions take 4 octets
   each.  This document defines a flags extension that can provide such
   indications at an average marginal cost of 1 bit each.  More
   precisely, it provides as many flag extensions as needed at 4 + the
   order of the last set bit divided by 8.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-11

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-tlsflags-11


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[John Mattsson]

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.

- NIST is expected to exclusively use SHA3 in the lattice-based PQC algorithms. 
I think it would make very much sense to include SHA3 (the SHAKE variants) at 
the same time as the standardized NIST PQC algorithms.

- TLS 1.3 hardcodes use of the quite outdated HMAC and HDKF constructions that 
only exists because SHA2 is fixed-length and suffers badly from 
length-extension attacks. Modern hash algorithm like SHAKE/KMAC are 
variable-length and does not suffer from length-extension attacks. If SHA3 is 
added in the future, I think it would make sense to use KMAC instead of HMAC 
and HKDF. Might also be nice to use the duplex construction whose security can 
be shown to be equivalent to the sponge construction.

Cheers,
John

From: TLS  on behalf of Salz, Rich 

Date: Thursday, 26 January 2023 at 20:42
To: hojarasca2022 , tls@ietf.org 

Subject: Re: [TLS] about hash and post-quantum ciphers
In TLS 1.3, AES256-SHA384 is not mandatory to implement.

If there is a freely available published specification of BLAKE3, you can 
request an assigned number for it in the TLS registry [1].


  *   Furthermore, NIST selected some post-quantum ciphers: 
https://nist.gov/pqcrypto

Hm, are you new here?  The archives have a couple hundred messages about 
post-quantum.

[1] 
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

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 are no obvious deficiencies.


 -  C. A. R. Hoare

 

 

From: TLS  on behalf of John Mattsson 

Date: Friday, January 27, 2023 at 06:26
To: "tls@ietf.org" 
Cc: hojarasca2022 , "Salz, Rich" 

Subject: 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.

 

- NIST is expected to exclusively use SHA3 in the lattice-based PQC algorithms. 
I think it would make very much sense to include SHA3 (the SHAKE variants) at 
the same time as the standardized NIST PQC algorithms.

 

- TLS 1.3 hardcodes use of the quite outdated HMAC and HDKF constructions that 
only exists because SHA2 is fixed-length and suffers badly from 
length-extension attacks. Modern hash algorithm like SHAKE/KMAC are 
variable-length and does not suffer from length-extension attacks. If SHA3 is 
added in the future, I think it would make sense to use KMAC instead of HMAC 
and HKDF. Might also be nice to use the duplex construction whose security can 
be shown to be equivalent to the sponge construction.

 

Cheers,

John

From: TLS  on behalf of Salz, Rich 

Date: Thursday, 26 January 2023 at 20:42
To: hojarasca2022 , tls@ietf.org 

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

In TLS 1.3, AES256-SHA384 is not mandatory to implement.

 

If there is a freely available published specification of BLAKE3, you can 
request an assigned number for it in the TLS registry [1]. 

 

Ø  Furthermore, NIST selected some post-quantum ciphers: 
https://nist.gov/pqcrypto 

 

Hm, are you new here?  The archives have a couple hundred messages about 
post-quantum.

 

[1] 
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kampanakis, Panos]

+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


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 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.

- NIST is expected to exclusively use SHA3 in the lattice-based PQC algorithms. 
I think it would make very much sense to include SHA3 (the SHAKE variants) at 
the same time as the standardized NIST PQC algorithms.

- TLS 1.3 hardcodes use of the quite outdated HMAC and HDKF constructions that 
only exists because SHA2 is fixed-length and suffers badly from 
length-extension attacks. Modern hash algorithm like SHAKE/KMAC are 
variable-length and does not suffer from length-extension attacks. If SHA3 is 
added in the future, I think it would make sense to use KMAC instead of HMAC 
and HKDF. Might also be nice to use the duplex construction whose security can 
be shown to be equivalent to the sponge construction.

Cheers,
John
From: TLS mailto:tls-boun...@ietf.org>> on behalf of 
Salz, Rich 
mailto:rsalz=40akamai@dmarc.ietf.org>>
Date: Thursday, 26 January 2023 at 20:42
To: hojarasca2022 
mailto:hojarasca2022=40proton...@dmarc.ietf.org>>,
 tls@ietf.org mailto:tls@ietf.org>>
Subject: Re: [TLS] about hash and post-quantum ciphers
In TLS 1.3, AES256-SHA384 is not mandatory to implement.

If there is a freely available published specification of BLAKE3, you can 
request an assigned number for it in the TLS registry [1].


  *   Furthermore, NIST selected some post-quantum ciphers: 
https://nist.gov/pqcrypto

Hm, are you new here?  The archives have a couple hundred messages about 
post-quantum.

[1] 
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

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 PQ, which precludes it from being evaluated and considered in our use 
cases. If DH in EDHOC is replaced by a PQ KEM – the numbers will start favoring 
CAKE-HI, but at this time is doesn’t look like there’s interest to make EDHOC 
Quantum-Resistant.

 

I’d say CAKE-HI could replace EDHOC, if and when Quantum Resistance is needed 
(and the channel can tolerate larger packet/message sizes), and when 
template-based approach is preferred to online negotiations.

 

By the way is there any specification of CAKE-HI available?

 

In the process of “release review”. ;-)

 

Thanks!

 

 

Orange Restricted

De : Blumenthal, Uri - 0553 - MITLL  
Envoyé : jeudi 26 janvier 2023 21:08
À : FERREIRA Loïc INNOV/IT-S ; Thom Wiggers 

Cc : John Mattsson ; Mike Ounsworth 
; p...@ietf.org; tls@ietf.org
Objet : Re: [Pqc] [TLS] Did TLS AuthKEM die?

 

How would you compare CAKE-HI and cTLS?

 

Loïc, an excellent question. Naturally, there are similarities and differences. 

 

Similarities: 

-  Both strive to reduce unnecessary communications;

-  Both strive to avoid unnecessary negotiations;

-  Both embrace “template-based specialization” that allows avoiding 
negotiations altogether (if I understood this part of cTLS correctly).

 

Differences:

-  Different purpose: 

o   cTLS is a compact Transport Layer Security that protects user data, and 
includes key exchange (as one of the mechanisms it utilizes to achieve its 
goal).

o   CAKE-HI is a Key Exchange protocol that provides session keys (shared 
secret(s)) to other protocols that handle user data.

-  Different degree of “minimization”, as CAKE-HI is much more 
minimalistic than cTLS: 

o   cTLS tries to create a “leaner TLS” by paring the “fat” of TLS, 
backward-compatibility with TLS 1.2, etc. But quite a bit of TLS details 
remains there.

o   CAKE-HI has nothing in common with the TLS handshaking, options, syntax, 
fields, and such. It has a set of cryptographic primitives that it employs to 
generate symmetric shared secret and satisfy security properties listed below.

-  Thus, CAKE-HI cannot replace cTLS, (among other reasons) because by 
itself it does not provide user data protection (and requires another protocol, 
like SCIP to handle that), nor can cTLS “replace” CAKE-HI because it does a lot 
of things unnecessary for “pure” key exchange and carries more overhead than a 
truly minimalistic AKE needs.

 

On the sad part, CAKE-HI specification (actually, we’ll most likely present 
CHAKE-HI, aka – Compact Hybrid Authenticated Key Exchange Hiding Identities) 
lags behind in details that have been provided in cTLS ID 
(https://www.ietf.org/archive/id/draft-ietf-tls-ctls-07.html). But we’ll get 
there. ;-)

 

I realize the above is rather sketchy – please feel free to ask more questions, 
and I’ll do my best to answer them.

 

Thanks!

 

 

 

Orange Restricted

De : Pqc  De la part de Blumenthal, Uri - 0553 - MITLL
Envoyé : mercredi 25 janvier 2023 22:49
À : Thom Wiggers 
Cc : John Mattsson ; Mike Ounsworth 
; p...@ietf.org; tls@ietf.org
Objet : Re: [Pqc] [TLS] Did TLS AuthKEM die?

 

I'll first ask the first question, and then try to clarify a few of the other 
things raised in this thread.

 

> Is AuthKEM dead?

 

I'd say it's hibernating. The draft has indeed expired: there was nothing 
significant to add since the last time we edited/updated it. I also couldn't 
make it to the last two IETF meetings (and due to conflict with Real World 
Crypto, I will most likely not be able to make IETF116 either). The TLS working 
group has seemed to want to focus on getting PQ key exchange out of the door, 
but if it's ready to continue the discussion on post-quantum authentication 
(which should include some other things like OCSP and CT), I'd be very happy to 
continue the discussion and work on AuthKEM.

 

We have a simplified protocol (CAKE-HI) inspired by and based on AuthKEM. Being 
simplified, CAKE is not really suitable for TLS. Thus, we’d like to see AuthKEM 
progressing within the TLS WG.

 

One change that we'd probably like to make soon is to include Kyber-based 
(hybrid / PQ/T) KEMs -- once those KEMs have been hammered out for the 
ephemeral key exchange.

 

Yes, something worth discussing.

 

I am currently working hard on wrapping up my PhD thesis* (which is largely on 
post-quantum TLS and KEMTLS in particular). This is another reason why the 
draft has been sitting there for a while. To me, right now, most of the 
"homework" behind the AuthKEM/KEMTLS proposal feels pretty "finished"; I'd 
argue we have some form of running code (as in the various KEMTLS experimental 
implementations we did for 

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

[John Mattsson]

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 large public keys and 
encapsulation sizes, I have a hard time to see that this “verbosity” (EDHOC has 
type and length for all fields so that it can be parsed without an agreed 
template) would matter much in practice :)

John 

From: Blumenthal, Uri - 0553 - MITLL 
Date: Friday, 27 January 2023 at 16:09
To: loic.ferre...@orange.com , Thom Wiggers 

Cc: John Mattsson , Mike Ounsworth 
, p...@ietf.org , 
tls@ietf.org 
Subject: Re: [Pqc] [TLS] 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 PQ, which precludes it from being evaluated and considered in our use 
cases. If DH in EDHOC is replaced by a PQ KEM – the numbers will start favoring 
CAKE-HI, but at this time is doesn’t look like there’s interest to make EDHOC 
Quantum-Resistant. 

I’d say CAKE-HI could replace EDHOC, if and when Quantum Resistance is needed 
(and the channel can tolerate larger packet/message sizes), and when 
template-based approach is preferred to online negotiations. 

By the way is there any specification of CAKE-HI available? 

In the process of “release review”. ;-) 

Thanks! 


Orange Restricted 
De : Blumenthal, Uri - 0553 - MITLL  
Envoyé : jeudi 26 janvier 2023 21:08
À : FERREIRA Loïc INNOV/IT-S ; Thom Wiggers 

Cc : John Mattsson ; Mike Ounsworth 
; p...@ietf.org; tls@ietf.org
Objet : Re: [Pqc] [TLS] Did TLS AuthKEM die? 



How would you compare CAKE-HI and cTLS? 

Loïc, an excellent question. Naturally, there are similarities and differences. 

Similarities: 
1. Both strive to reduce unnecessary communications; 
2. Both strive to avoid unnecessary negotiations; 
3. Both embrace “template-based specialization” that allows avoiding 
negotiations altogether (if I understood this part of cTLS correctly). 

Differences: 
4. Different purpose: 
1. cTLS is a compact Transport Layer Security that protects user data , and 
includes key exchange (as one of the mechanisms it utilizes to achieve its 
goal). 
2. CAKE-HI is a Key Exchange protocol that provides session keys (shared 
secret(s)) to other protocols that handle user data. 
5. Different degree of “minimization”, as CAKE-HI is much more minimalistic 
than cTLS: 
1. cTLS tries to create a “leaner TLS” by paring the “fat” of TLS, 
backward-compatibility with TLS 1.2, etc. But quite a bit of TLS details 
remains there. 
2. CAKE-HI has nothing in common with the TLS handshaking, options, syntax, 
fields, and such. It has a set of cryptographic primitives that it employs to 
generate symmetric shared secret and satisfy security properties listed below. 
6. Thus, CAKE-HI cannot replace cTLS, (among other reasons) because by itself 
it does not provide user data protection (and requires another protocol, like 
SCIP to handle that), nor can cTLS “replace” CAKE-HI because it does a lot of 
things unnecessary for “pure” key exchange and carries more overhead than a 
truly minimalistic AKE needs. 

On the sad part, CAKE-HI specification (actually, we’ll most likely present 
CHAKE-HI, aka – Compact Hybrid Authenticated Key Exchange Hiding Identities) 
lags behind in details that have been provided in cTLS ID 
(https://www.ietf.org/archive/id/draft-ietf-tls-ctls-07.html 
). But we’ll get 
there. ;-) 

I realize the above is rather sketchy – please feel free to ask more questions, 
and I’ll do my best to answer them. 

Thanks! 



Orange Restricted 
De : Pqc mailto:pqc-boun...@ietf.org>> De la part de 
Blumenthal, Uri - 0553 - MITLL
Envoyé : mercredi 25 janvier 2023 22:49
À : Thom Wiggers mailto:t...@thomwiggers.nl>>
Cc : John Mattsson mailto:john.matts...@ericsson.com>>; Mike Ounsworth 
mailto:Mike.Ounsworth=40entrust@dmarc.ietf.org>>; p...@ietf.org 
; tls@ietf.org 
Objet : Re: [Pqc] [TLS] Did TLS AuthKEM die? 



I'll first ask the first question, and then try to clarify a few of the other 
things raised in this thread. 



> Is AuthKEM dead? 



I'd say it's hibernating. The draft has indeed expired: there was nothing 
significant to add since the last time we edited/updated it. I also couldn't 
make it to the last two IETF meetings (and due to conflict with Real World 
Crypto, I will most likely not be able to make IETF116 either). The TLS working 
group has seemed to want to focus on getting PQ key exchange out of the door, 
but if it's ready to continue the discussion on post-quantum authentication 
(which should include 

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

[Blumenthal, Uri - 0553 - MITLL]

>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 
encapsulation sizes, I have a hard time to see that this “verbosity” (EDHOC has 
type and length for all fields so that it can be parsed without an agreed 
template) would matter much in practice :)

 

Overhead – compared to what? 

 

Re. agreed templates: it is about avoiding [the need to communicate and select] 
options.

 

 

From: Blumenthal, Uri - 0553 - MITLL 
Date: Friday, 27 January 2023 at 16:09
To: loic.ferre...@orange.com , Thom Wiggers 

Cc: John Mattsson , Mike Ounsworth 
, p...@ietf.org , 
tls@ietf.org 
Subject: Re: [Pqc] [TLS] 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 PQ, which precludes it from being evaluated and considered in our use 
cases. If DH in EDHOC is replaced by a PQ KEM – the numbers will start favoring 
CAKE-HI, but at this time is doesn’t look like there’s interest to make EDHOC 
Quantum-Resistant.

 

I’d say CAKE-HI could replace EDHOC, if and when Quantum Resistance is needed 
(and the channel can tolerate larger packet/message sizes), and when 
template-based approach is preferred to online negotiations.

 

By the way is there any specification of CAKE-HI available?

 

In the process of “release review”. ;-)

 

Thanks!

 

 

Orange Restricted

De : Blumenthal, Uri - 0553 - MITLL  
Envoyé : jeudi 26 janvier 2023 21:08
À : FERREIRA Loïc INNOV/IT-S ; Thom Wiggers 

Cc : John Mattsson ; Mike Ounsworth 
; p...@ietf.org; tls@ietf.org
Objet : Re: [Pqc] [TLS] Did TLS AuthKEM die?

 

How would you compare CAKE-HI and cTLS?

 

Loïc, an excellent question. Naturally, there are similarities and differences. 

 

Similarities: 

1.   Both strive to reduce unnecessary communications;

2.   Both strive to avoid unnecessary negotiations;

3.   Both embrace “template-based specialization” that allows avoiding 
negotiations altogether (if I understood this part of cTLS correctly).

 

Differences:

4.   Different purpose: 

1.   cTLS is a compact Transport Layer Security that protects user data, 
and includes key exchange (as one of the mechanisms it utilizes to achieve its 
goal).

2.   CAKE-HI is a Key Exchange protocol that provides session keys (shared 
secret(s)) to other protocols that handle user data.

5.   Different degree of “minimization”, as CAKE-HI is much more 
minimalistic than cTLS: 

1.   cTLS tries to create a “leaner TLS” by paring the “fat” of TLS, 
backward-compatibility with TLS 1.2, etc. But quite a bit of TLS details 
remains there.

2.   CAKE-HI has nothing in common with the TLS handshaking, options, 
syntax, fields, and such. It has a set of cryptographic primitives that it 
employs to generate symmetric shared secret and satisfy security properties 
listed below.

6.   Thus, CAKE-HI cannot replace cTLS, (among other reasons) because by 
itself it does not provide user data protection (and requires another protocol, 
like SCIP to handle that), nor can cTLS “replace” CAKE-HI because it does a lot 
of things unnecessary for “pure” key exchange and carries more overhead than a 
truly minimalistic AKE needs.

 

On the sad part, CAKE-HI specification (actually, we’ll most likely present 
CHAKE-HI, aka – Compact Hybrid Authenticated Key Exchange Hiding Identities) 
lags behind in details that have been provided in cTLS ID 
(https://www.ietf.org/archive/id/draft-ietf-tls-ctls-07.html). But we’ll get 
there. ;-)

 

I realize the above is rather sketchy – please feel free to ask more questions, 
and I’ll do my best to answer them.

 

Thanks!

 

 

 

Orange Restricted

De : Pqc  De la part de Blumenthal, Uri - 0553 - MITLL
Envoyé : mercredi 25 janvier 2023 22:49
À : Thom Wiggers 
Cc : John Mattsson ; Mike Ounsworth 
; p...@ietf.org; tls@ietf.org
Objet : Re: [Pqc] [TLS] Did TLS AuthKEM die?

 

I'll first ask the first question, and then try to clarify a few of the other 
things raised in this thread.

 

> Is AuthKEM dead?

 

I'd say it's hibernating. The draft has indeed expired: there was nothing 
significant to add since the last time we edited/updated it. I also couldn't 
make it to the last two IETF meetings (and due to conflict with Real World 
Crypto, I will most likely not be able to make IETF116 either). The TLS working 
group has seemed to want to focus on getting PQ key exchange out of the door, 
but if it's ready to continue the discussion on post-quantum authentication 
(which should include some other things like OCSP and CT), I'd be very

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

[John Mattsson]

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 another protocol (JOSE, COSE, 
SMIME, IKE, etc, ….)
  *   Using the external PSK for TLS and another protocol.

I think it should.

- 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.

- Did any of the formal analysis prove that using the same key for TLS client 
and server is secure? It is quite common that the same node is a TLS server and 
client.

Cheers,
John
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

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 number... There is expert review process as well.

I think it might be time for experimental PQC codepoints for final
round of testing before the final PQC algorithms. Recommended=N of
course.


> But this mail got me thinking:
> 
> - NIST is expected to exclusively use SHA3 in the lattice-based PQC
>   algorithms. I think it would make very much sense to include SHA3
>   (the SHAKE variants) at the same time as the standardized NIST PQC
>   algorithms.

Why wait for those? It seems to me that one could add the SHA-3
ciphersuites already, as SHA-3 has been standardized years ago.

- TLS_AES_128_GCM_SHA3_32
- TLS_AES_256_GCM_SHA3_48
- TLS_CHACHA20_POLY1305_SHA3_32
- TLS_KECCAK_DUPLEX_SHA3_48

I think all could use 256-level SHA-3, I don't think dropping to
128-level for AES-128 is worth it.


> - TLS 1.3 hardcodes use of the quite outdated HMAC and HDKF
>   constructions that only exists because SHA2 is fixed-length and
>   suffers badly from length-extension attacks. Modern hash algorithm
>   like SHAKE/KMAC are variable-length and does not suffer from
>   length-extension attacks. If SHA3 is added in the future, I think
>   it would make sense to use KMAC instead of HMAC and HKDF. Might also
>   be nice to use the duplex construction whose security can be shown
>   to be equivalent to the sponge construction.

Well, duplex mode is a bit special-purpose thing, for cases where one
wants to reduce number of primitives to reduce code size, or has
hardware acceleration to make it much faster than AES-GCM. 

One might want to design padding in duplex mode so that each data block
is 128 octets... And another trick is only supporting plaintext sizes
multiple of 8 octets (TLS 1.3 record layer can pad to it anyway).


And TLS 1.3 uses hash function in four ways:

- Raw hash (Transcript-Hash).
- Raw HMAC (verify_data).
- KDF extraction (HKDF-Extract). Which actually turns out to be raw
  HMAC under the hood.
- KDF expansion (HKDF-Expand-Label).

To actually use SHA3 to full capacity, one would have to weird stuff
by redefining HKDF-Extract and HKDF-Expand-Label to be something else
than HKDF.

One could optimize a bit by using SHAKE256 instead of KMAC256 for the
last three. I think all the standard stuff would then be doable with
only one Keccak-F per MAC/KDF (maximum 135 octets in, 136 out). This
would save a few Keccak-F computations.



-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

>> 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 for assigning a number are defined in RFC 5226 (section 3). 
The TLS registries are "designated expert" and Yoav Nir, Nick Sullivan, and I 
are the current designees. The structure (columns) of the registries are 
defined in RFC 8447 (and its predecessors), and are being updated in 
draft-ietf-tls-rfc8446bis [1]

The number space for ciphers is not small. Multi-party experimentation is 
probably desirable, which makes using the "private use" space, where possible, 
not appropriate. I would be inclined to approve any algorithm that appears to 
be in NISTs plans.  But two DE's have to approve.

Hope this helps.
/r$

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

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:

- TLS 1.2 client signatures start with 0x01 (client hello message
  type).
- TLS 1.2 server signatures are messy, as the first 32 octets are
  from client (client random)!
- TLS 1.3 signatures start with 0x20 (explicit padding).
- JOSE signatures start with 0x65 (base64url of '{').
- COSE signatures start with 0x84 or 0x85 (Countersignatures can
  also start with 0x86); (Array of 4, 5 or 6 elements).
- X.509 signatures (S/MIME, PKIX, etc...) typically start with 0x30
  (SEQUENCE type).
- SSH pubkey signatures start with 0x00 (session id is <16MB).
- SSH hostkey signatures are a bit messy, as those seem to be over a
  raw hash.
- SSH signatures start with 0x53 (explicit magic).


So looks like none of those can interact badly with others, except
for TLS 1.2 server signatures and SSH hostkey signatures (and even
those probably don't interact badly in practice)


> - Did any of the formal analysis prove that using the same key for
>   TLS client and server is secure? It is quite common that the same
>   node is a TLS server and client.

For TLS 1.3, it is secure (the signatures have context). For TLS 1.2,
things are more complicated (but it is probably still secure).



-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls