I support those choices, but would also add P256+Kyber512.
* (1) same reason as below (by Scott)
* (2) to be able to declare security of generated keys in FIPS-mode for
_both_ - classical and post-quantum schemes (once Kyber is standardized).
After double-checking with NIST today, currently there is no clear plan for
updating SP 800-56A with X25519 (opposite to SP 800-186).
Kind regards,
Kris
On 8/17/22 20:06, Scott Fluhrer (sfluhrer) wrote:
So that we get an initial answer to this (so we can put it into the draft - of
course, we can debate what's in the draft...)
Illari suggested:
X25519+Kyber768
P384+Kyber768
Well, I would suggest adding in
X25519+Kyber512
For those situations where we need to limit the message size (perhaps DTLS and
QUIC).
Is the working group happy with that?
-----Original Message-----
From: TLS<tls-boun...@ietf.org> On Behalf Of Ilari Liusvaara
Sent: Saturday, August 13, 2022 11:12 AM
To:TLS@ietf.org
Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
On Fri, Aug 12, 2022 at 06:13:38PM +0000, Scott Fluhrer (sfluhrer) wrote:
Again, this is late, however Stephen did ask this to be discussed in the
working group, so here we go:
-----Original Message-----
From: TLS<tls-boun...@ietf.org> On Behalf Of Stephen Farrell
Sent: Saturday, April 30, 2022 11:49 AM
To: Ilari Liusvaara<ilariliusva...@welho.com>;TLS@ietf.org
Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
Hiya,
On 30/04/2022 10:05, Ilari Liusvaara wrote:
On Sat, Apr 30, 2022 at 01:24:58AM +0100, Stephen Farrell wrote:
- section 5: IMO all combined values here need to have
recommended == "N" in IANA registries for a while and that needs
to be in this draft before it even gets parked. Regardless of
whether or not the WG agree with me on that, I think the current
text is missing stuff in this section and don't recall the WG
discussing that
I think that having recommended = Y for any combined algorithm
requires NIST final spec PQ part and recommended = Y for the
classical part (which allows things like x25519 to be the classical part).
That is, using latest spec for NISTPQC winner is not enough. This
impiles recommended = Y for combined algorithm is some years out
at the very least.
I agree, and something like the above points ought be stated in the
draft after discussion in the WG.
Section 5 is 'IANA considerations', and would be where we would list
the various supported hybrids, which we don’t at the moment.
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
I would take:
X25519+Kyber768
P384+Kyber768
The reason for taking Kyber768 is because the CRYSTALS team recommends
it. The reason for taking P384 is because it is CNSA-approved, so folks that
need CNSA can use that.
Of course, that is likely to bust packet size limits. I do not think that is an
issue in TLS, but DTLS and QUIC might be another matter entierely (in theory
DTLS and QUIC can handle it just fine, practice might be another matter
entierely. And if such problems are there, it is good to know about those...
This stuff is experimental).
Of course, it's possible that NIST will tweak the definition of Kyber;
that's just a possibility we'll need to live with (and wouldn't change
what hybrid combinations we would initially define)
I would think such changes would just mean the interim post-quantum kex is
not compatible with the final one. Not that big of deal, there are tens of
thoursands of free codepoints. If an implementation needs both, it can
probably share vast majority of the code.
-Ilari
_______________________________________________
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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
