Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

[Bas Westerbaan <[e-mail]>]

>
> Ultimately, I want fewer choices, but the direction the discussion is
> headed seems about right.  At least in the short term, I think we need to
> eschew compression and only include one offer.


I also prefer fewer choices initially.

The only reason we're testing both X25519+Kyber512 and X25519+Kyber768 is
that there is a possibility that Kyber768 becomes the default [1] and
because of its size, X25519+Kyber768 causes fragmentation in some cases
where X25519+Kyber512 doesn't.

* (2) to be able to declare security of generated keys in FIPS-mode for
>       _both_ - classical and post-quantum schemes (once Kyber is
> standardized).—


Why is this required? NIST writes

Current NIST standards, which were not necessarily designed to provide
post-quantum security, can accommodate several hybrid key establishment
constructions in “FIPS mode,” as defined in FIPS 140. For example, assume
that the value Z is a shared secret that was generated within a
NIST-approved cryptographic scheme, and that a value T is generated or
distributed through other scheme(s), which could be the output of a key
encapsulation method (KEM). The following are the different ways to
incorporate the value T in the key derivation procedure to achieve a hybrid
mode which is permitted by current standards: [...]

Here they're speaking about adding non-FIPS PQ to a non-PQ FIPS kex,[2] but
the other way around is also ok — what am I missing?

Best,

 Bas

[1] Not expressing an opinion on whether that's good or not.
[2] https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs




On Thu, Aug 18, 2022 at 1:05 AM Martin Thomson <[e-mail]> wrote:

> On Sat, Aug 13, 2022, at 04:13, Scott Fluhrer (sfluhrer) wrote:
> > Well, if we were to discuss some suggested hybrids (and we now know the
> > NIST selection), I would suggest these possibilities:
> >
> > - X25519 + Kyber512
> > - P256 + Kyber512
> > - X448 + Kyber768
> > - P384 + Kyber768
>
> Any specific pairs of primitives should be specified in a different
> document to this one.
>
> Ultimately, I want fewer choices, but the direction the discussion is
> headed seems about right.  At least in the short term, I think we need to
> eschew compression and only include one offer.  Partly because I think that
> there might be better options available to us than compression, partly
> because compression will be annoying to implement correctly, and partly
> because we're still in the phase where this is being trialed.
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>