> 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> wrote:

>
>
> On Wed, Mar 6, 2024 at 8:49 AM Deirdre Connolly <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> 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> 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
>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>
>>>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to