I do agree with Eric on that hybrid solutions may live for a very long term.
Moreover, IMO, it could even become a popular way to increase crypto-agility as this can tolerate weak or seroius security flaws which may be introduced from algorithm design, key size selection, and or software coding, under the assumption that at least one of the two or more component algorithms in the hybrided solution is still secure. Performance downgrade may be the cost we have to pay for the above higher security assurance. So, plenty discussions shall be very helpful. On the other hand, if it is hard to make decision, specifying both hybrid and pure ML-KEM could be good as well. Namely, we are going to offer several choices so that the users in the whole world will gradually select what they like. Time will tell the truth. Guilin ________________________________ Wang Guilin Mobile: +65-86920345 Email: wang.gui...@huawei.com From:tls-request <tls-requ...@ietf.org<mailto:tls-requ...@ietf.org>> To:tls <tls@ietf.org<mailto:tls@ietf.org>> Date:2024-03-07 01:35:03 Subject:TLS Digest, Vol 236, Issue 15 Send TLS mailing list submissions to tls@ietf.org<mailto:tls@ietf.org> To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/tls or, via email, send a message with subject or body 'help' to tls-requ...@ietf.org<mailto:tls-requ...@ietf.org> You can reach the person managing the list at tls-ow...@ietf.org<mailto:tls-ow...@ietf.org> When replying, please edit your Subject line so it is more specific than "Re: Contents of TLS digest..." Today's Topics: 1. Re: ML-KEM key agreement for TLS 1.3 (Eric Rescorla) 2. Re: ML-KEM key agreement for TLS 1.3 (Deirdre Connolly) ________________________________ Message: 1 Date: Wed, 6 Mar 2024 09:20:20 -0800 From: Eric Rescorla <e...@rtfm.com<mailto:e...@rtfm.com>> To: Deirdre Connolly <durumcrustu...@gmail.com<mailto:durumcrustu...@gmail.com>> Cc: "TLS@ietf.org<mailto:TLS@ietf.org>" <tls@ietf.org<mailto:tls@ietf.org>> Subject: Re: [TLS] ML-KEM key agreement for TLS 1.3 Message-ID: <CABcZeBNth=9q9cyxZD96Ywsw5k0nRk4GbeZA38=p9nmuoc6...@mail.gmail.com<mailto:p9nmuoc6...@mail.gmail.com>> Content-Type: text/plain; charset="utf-8" On Wed, Mar 6, 2024 at 8:49?AM Deirdre Connolly <durumcrustu...@gmail.com<mailto:durumcrustu...@gmail.com>> wrote: > > Can you say what the motivation is for being "fully post-quantum" rather > than hybrid? > > Sure: in the broad scope, hybrid introduces complexity in the short-term > that we would like to move off of in the long-term - for TLS 1.3 key > agreement this is not the worst thing in the world and we can afford it, > but hybrid is by design a hedge, and theoretically a temporary one. > My view is that this is likely to be the *very* long term. I'm open to being persuaded, but at the moment, I don't think there is anywhere near enough confidence in any of the PQ algorithms to confidently use it standalone, which means we're going to see a lot of hybrid deployment sooner rather than later. This also means that we're going to have a long tail of clients and servers which only do hybrid and not PQ-only, so that complexity is baked in for quite some time to come. > In the more concrete scope, FIPS / CNSA 2.0 compliance guidelines > <https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF> > currently are a big 'maybe' at best for 'hybrid solutions', and the > timetables for compliant browsers, servers, and services are to exclusively > use FIPS 203 at level V (ML-KEM-1024) by 2033. I figure there will be > demand for pure ML-KEM key agreement, not hybrid (with no questions that > come along with it of whether it's actually allowed or not). > I'm honestly not moved by this very much. IETF should form its own opinion about the security of algorithms, not just take whatever opinions are handed down from NIST. If that means that IETF doesn't standardize what NIST wants, then NIST is free to register its own codepoints and try to persuade implementors to take them. So I think the question here should be focused on "what level of confidence would IETF need to specify ML-KEM standalone at Proposed Standard with Recommended=Y". -Ekr > Relatedly, the currently adopted -hybrid-design > <https://dstebila.github.io/draft-ietf-tls-hybrid-design/draft-ietf-tls-hybrid-design.html> > outlines several combinations of ECDH and KEM, and allows computing the > ECDH share once and sharing it between an ECDH share and a hybrid ECDH+KEM > share, but there is no equivalent for just using a KEM on its own, and > computing its shared secret once and advertising it as both standalone and > in a hybrid share. So I think defining these standalone ML-KEM > `NamedGroup`s also 'draws the rest of the owl' implied by -hybrid-design. > > On Wed, Mar 6, 2024 at 10:12?AM Eric Rescorla > <e...@rtfm.com<mailto:e...@rtfm.com>> wrote: > >> Deirdre, thanks for submitting this. Can you say what the motivation is >> for being "fully post-quantum" rather than hybrid? >> >> Thanks, >> -Ekr >> >> >> >> On Tue, Mar 5, 2024 at 6:16?PM Deirdre Connolly >> <durumcrustu...@gmail.com<mailto:durumcrustu...@gmail.com>> >> wrote: >> >>> I have uploaded a preliminary version of ML-KEM for TLS 1.3 >>> <https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/> >>> and have a more fleshed out >>> <https://github.com/dconnolly/draft-tls-mlkem-key-agreement> version to >>> be uploaded when datatracker opens. It is a straightforward new >>> `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a >>> very similar style to -hybrid-design >>> <https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/>. >>> >>> It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0 >>> compatible) ready to go when users are ready to use them. >>> >>> Cheers, >>> Deirdre >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org<mailto:TLS@ietf.org> >>> https://www.ietf.org/mailman/listinfo/tls >>> >> ________________________________ next part ________________________________ An HTML attachment was scrubbed... URL: <https://mailarchive.ietf.org/arch/browse/tls/attachments/20240306/acaa488a/attachment.htm> ________________________________ ________________________________ -- Message: 2 Date: Wed, 6 Mar 2024 12:32:39 -0500 From: Deirdre Connolly <durumcrustu...@gmail.com<mailto:durumcrustu...@gmail.com>> To: Eric Rescorla <e...@rtfm.com<mailto:e...@rtfm.com>> Cc: "TLS@ietf.org<mailto:TLS@ietf.org>" <tls@ietf.org<mailto:tls@ietf.org>> Subject: Re: [TLS] ML-KEM key agreement for TLS 1.3 Message-ID: <cafr824z0zjo0vbpt-vtc2fzwjcrlj-zaselfo27hg_rih_k...@mail.gmail.com<mailto:cafr824z0zjo0vbpt-vtc2fzwjcrlj-zaselfo27hg_rih_k...@mail.gmail.com>> Content-Type: text/plain; charset="utf-8" > So I think the question here should be focused on "what level of confidence would IETF need to specify ML-KEM standalone at Proposed Standard with Recommended=Y". On 'Recommended=Y' I figured it would not be for a while, but it is available. > I don't think there is anywhere near enough confidence in any of the PQ algorithms to confidently use it standalone, Crystals-Kyber was introduced in at least 2017, it has gone through many rounds of analysis, and is now over 7 years old, close to the '10 years' I often hear quoted as a benchmark for new crypto to marinate I guess. I understand caution but having the option (not the recommendation) to support pure-PQ seems reasonable to sort out sooner than later, both to face the complexity of managing pure traditional, hybrid, and pure PQ negotiation now, but also to keep the eventual goal of pure PQ clear in mind, and taken seriously. On Wed, Mar 6, 2024 at 12:21?PM Eric Rescorla <e...@rtfm.com<mailto:e...@rtfm.com>> wrote: > > > On Wed, Mar 6, 2024 at 8:49?AM Deirdre Connolly > <durumcrustu...@gmail.com<mailto:durumcrustu...@gmail.com>> > wrote: > >> > Can you say what the motivation is for being "fully post-quantum" >> rather than hybrid? >> >> Sure: in the broad scope, hybrid introduces complexity in the short-term >> that we would like to move off of in the long-term - for TLS 1.3 key >> agreement this is not the worst thing in the world and we can afford it, >> but hybrid is by design a hedge, and theoretically a temporary one. >> > > My view is that this is likely to be the *very* long term. > > I'm open to being persuaded, but at the moment, I don't think there is > anywhere near enough confidence in any of the PQ algorithms to confidently > use it standalone, which means we're going to see a lot of hybrid > deployment sooner rather than later. This also means that we're going to > have a long tail of clients and servers which only do hybrid and not > PQ-only, so that complexity is baked in for quite some time to come. > > >> In the more concrete scope, FIPS / CNSA 2.0 compliance guidelines >> <https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF> >> currently are a big 'maybe' at best for 'hybrid solutions', and the >> timetables for compliant browsers, servers, and services are to exclusively >> use FIPS 203 at level V (ML-KEM-1024) by 2033. I figure there will be >> demand for pure ML-KEM key agreement, not hybrid (with no questions that >> come along with it of whether it's actually allowed or not). >> > > I'm honestly not moved by this very much. IETF should form its own opinion > about the security of algorithms, not just take whatever opinions are > handed down from NIST. If that means that IETF doesn't standardize what > NIST wants, then NIST is free to register its own codepoints and try to > persuade implementors to take them. > > So I think the question here should be focused on "what level of > confidence would IETF need to specify ML-KEM standalone at Proposed > Standard with Recommended=Y". > > -Ekr > > >> Relatedly, the currently adopted -hybrid-design >> <https://dstebila.github.io/draft-ietf-tls-hybrid-design/draft-ietf-tls-hybrid-design.html> >> outlines several combinations of ECDH and KEM, and allows computing the >> ECDH share once and sharing it between an ECDH share and a hybrid ECDH+KEM >> share, but there is no equivalent for just using a KEM on its own, and >> computing its shared secret once and advertising it as both standalone and >> in a hybrid share. So I think defining these standalone ML-KEM >> `NamedGroup`s also 'draws the rest of the owl' implied by -hybrid-design. >> >> On Wed, Mar 6, 2024 at 10:12?AM Eric Rescorla >> <e...@rtfm.com<mailto:e...@rtfm.com>> wrote: >> >>> Deirdre, thanks for submitting this. Can you say what the motivation is >>> for being "fully post-quantum" rather than hybrid? >>> >>> Thanks, >>> -Ekr >>> >>> >>> >>> On Tue, Mar 5, 2024 at 6:16?PM Deirdre Connolly < >>> durumcrustu...@gmail.com<mailto:durumcrustu...@gmail.com>> wrote: >>> >>>> I have uploaded a preliminary version of ML-KEM for TLS 1.3 >>>> <https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/> >>>> and have a more fleshed out >>>> <https://github.com/dconnolly/draft-tls-mlkem-key-agreement> version >>>> to be uploaded when datatracker opens. It is a straightforward new >>>> `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a >>>> very similar style to -hybrid-design >>>> <https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/>. >>>> >>>> It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0 >>>> compatible) ready to go when users are ready to use them. >>>> >>>> Cheers, >>>> Deirdre >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org<mailto:TLS@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/tls >>>> >>> ________________________________ next part ________________________________ An HTML attachment was scrubbed... URL: <https://mailarchive.ietf.org/arch/browse/tls/attachments/20240306/c796999e/attachment.htm> ________________________________ ________________________________ -- Subject: Digest Footer _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls ________________________________ ________________________________ -- End of TLS Digest, Vol 236, Issue 15 ************************************
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
