I personally do not find the proposed approach appealing (or even useful).

There are three possibilities.

a. Quantum computers capable of breaking crypto (QC) become practical *and* 
NIST PQC winner(s) resist both quantum and classic attacks;
b. QC become practical, and NIST PQC candidates fail (doesn't matter whether 
they fall to classic or quantum attack!);
c. QC do *not* materialize, *and* PQC candidates fail to classic attacks.

The only possibility justifying the hybrid exchange is (c), which I personally 
find the least probable. In both (a) and (b) addition of ECC does not make the 
KE any more secure than without it.
--
Regards,
Uri
 
There are two ways to design a system. One is to make is so simple there are 
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
                                                                                
                                                     -  C. A. R. Hoare
 

On 7/6/21, 21:19, "TLS on behalf of Douglas Stebila" <tls-boun...@ietf.org on 
behalf of dsteb...@gmail.com> wrote:

    Dear TLS working group,

    We wanted to see if there is any further feedback on our draft "Hybrid key 
exchange in TLS 1.3" 
(https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/) and what steps 
are required for it to advance further.  We have not received any new feedback 
from the working group since we posted our last non-trivial update in October 
2020.

    The draft as written does not actually specify any post-quantum algorithms 
nor give identifiers for specific algorithm combinations, only the formats for 
hybrid key exchange messages and key derivation.  We have received a suggestion 
that the draft be updated to include identifiers for hybrid key exchange 
combining elliptic curve groups and the KEMs currently in Round 3 of the NIST 
PQC standardization process, so that implementations can begin testing 
interoperability using numbers listed in the draft, rather than relying on ad 
hoc lists for such purposes.  Is that something the working group would like to 
see, or would you prefer to leave it as it currently stands, without any 
specific algorithm identifiers?

    Douglas, Scott, and Shay
    _______________________________________________
    TLS mailing list
    TLS@ietf.org
    https://www.ietf.org/mailman/listinfo/tls

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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

Reply via email to