Fwd: Cloudflare public comments on FIPS IPD 203, 204, and 205.
Jordi Mur work
Bas Westerbaan
Could you comment on the range of values on the x-axis (handshake time) graph showing the cumulative distribution function of TLS handshake times of PQ and non-PQ connections?
bruno
Hi Bas, Thanks for the work
1) Would you mind to provide more inputs in the light of the
interesting percentage in the note as it is quiet unclear to me of
the impact of the current implementation ", is used by 1.7% of
all our inbound TLS 1.3" and "At the time of writing, 7%
of all Chrome 118+ TLS 1.3". This is an interesting topic
for end-user to understand the fingerprint/measurements of
Cloudflare as well as other massive providers...I understand you
are writing some paper so that's not urgent but i have not been
able to understand the adoption overall.
2) I noticed in the draft RFC (X25519Kyber768Draft00
that you are proposing a concatenation of the 32 bytes shared
secrets. It sounds to me not really aligned with NIST SP 800-56C
REV. 2 which mandates a KDF of both PQC and non PQC. I guess it
will be interesting to clarify this point for compliance and
security reasons.
3) In regard of the work on X25519Kyber768Draft00, I had in mind that QUIC is having some traction so it might be good to understand what could be re-used. I put it here since I have not looked at Quic so far so may be this is remark can be discarded?.
Thanks
Regards
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMjbhoXFOCTExeDg9mHC_AGUqgvF6ieZ7DD5%3D8N9RtDdRD4H6A%40mail.gmail.com.
Bas Westerbaan
1) Would you mind to provide more inputs in the light of the interesting percentage in the note as it is quiet unclear to me of the impact of the current implementation
2) I noticed in the draft RFC (X25519Kyber768Draft00 that you are proposing a concatenation of the 32 bytes shared secrets. It sounds to me not really aligned with NIST SP 800-56C REV. 2 which mandates a KDF of both PQC and non PQC. I guess it will be interesting to clarify this point for compliance and security reasons.
3) In regard of the work on X25519Kyber768Draft00, I had in mind that QUIC is having some traction so it might be good to understand what could be re-used. I put it here since I have not looked at Quic so far so may be this is remark can be discarded?.
Mike Ounsworth
> See the "hybrid" variety. (Second paragraph of §2 of SP 800-56C rev 2.)
Although, as Scott Fluhrer so eloquently put during the last IETF PQUIP; a lot of this is at the discretion of the FIPS lab, so let's not count our chickens until they've been certified. The more obviously it matches SP 800-56Cr2, the less trouble we expect at certification time, even if it's "cryptographically equivalent".
---
Mike Ounsworth
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To view this discussion on the web visit https://urldefense.com/v3/__https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMjbhoWSwmw_DPZeEzMfXOcbGy61i0tg24Qyb1xkK0aQsrOVzw*40mail.gmail.com?utm_medium=email&utm_source=footer__;JQ!!FJ-Y8qCqXTj2!Zicvkom3eyLVSNJy5IyyVuq33cKGo0NhK8c1nF_je1fsQrGIOE-Mnh7aUi5zXh_Dx2jkgGgkmDXwEmUGUg2av5wr0yXn$.
Sophie Schmieg
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CH0PR11MB5739239CCB440E71EE5A31A29FBDA%40CH0PR11MB5739.namprd11.prod.outlook.com.
Mike Ounsworth
Hi Sophie,
I’m not a great expert here, but I thought that X25519Kyber768Draft00 was an HPKE algorithm – therefore only applicable to the EncryptedClientHello, and not a general TLS KeyEx algorithm?
Genuine question: does the ECH need to be cryptographically self-contained, or is it ok for the security of ECH to depend on the TLS transcript check at the very end?
---
Mike Ounsworth
Bas Westerbaan
Hi Sophie,
I’m not a great expert here, but I thought that X25519Kyber768Draft00 was an HPKE algorithm – therefore only applicable to the EncryptedClientHello, and not a general TLS KeyEx algorithm?
Genuine question: does the ECH need to be cryptographically self-contained, or is it ok for the security of ECH to depend on the TLS transcript check at the very end?
Mike Ounsworth
Oh I see,
https://datatracker.ietf.org/doc/draft-tls-westerbaan-xyber768d00/
is a dependency of – and fits inside the cryptographic construct of --
https://datatracker.ietf.org/doc/html/draft-ietf-tls-hybrid-design
whereas
https://datatracker.ietf.org/doc/draft-westerbaan-cfrg-hpke-xyber768d00/
fits inside HPKE (RFC9180).
---
Mike Ounsworth
From: 'Bas Westerbaan' via pqc-forum <pqc-...@list.nist.gov>
Sent: Monday, November 27, 2023 3:39 PM
To: Mike Ounsworth <Mike.Ou...@entrust.com>
Cc: Sophie Schmieg <ssch...@google.com>; bruno <bruno.p...@gmail.com>; pqc-...@list.nist.gov
Subject: Re: [EXTERNAL] Re: [pqc-forum] Fwd: Cloudflare public comments on FIPS IPD 203, 204, and 205.
On Mon, Nov 27, 2023 at 9: 57 PM Mike Ounsworth <Mike. Ounsworth@ entrust. com> wrote: Hi Sophie, I’m not a great expert here, but I thought that X25519Kyber768Draft00 was an HPKE algorithm – therefore only applicable to the EncryptedClientHello,
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMjbhoWgMYfRPHybxVOOSzxoF%2BcCCMkduzfatkNLboPktnu_jA%40mail.gmail.com.