[TLS]Re: I-D Action: draft-ietf-tls-hybrid-design-10.txt

[Peter C]

Felix,

I'm not completely sure I understand what you are suggesting,
but I think it might not be quite as straightforward as that.

In general, if the PQ KEM is not secure then the HS can fail to be
indistinguishable from random: fixing the ECDH components of
the hybrid key shares and choosing distinct PQ KEM component
ciphertexts that encapsulate the same PQ shared secret will give the
same HS.  As an example, consider ML-KEM where the re-encryption
check is skipped and malformed ciphertexts are never (implicitly)
rejected.  In that case, it is trivial to modify ciphertexts without
changing the encapsulated shared secret, but I suspect it would be
hard to reliably detect equivalent ciphertexts without having access
to the ML-KEM private key.

My guess is that this can be avoided if you assume that the PQ KEM
satisfies something along the lines of ciphertext second preimage
resistance from the X-Wing paper (https://ia.cr/2024/039).  It is also
entirely possible that I'm missing something obvious and a different
part of the proof rules this out.

Best,

Peter

> -Original Message-
> From: Felix Günther 
> Sent: Friday, August 2, 2024 2:05 PM
> To: Peter C ; Marc Fischlin  darmstadt.de>
> Cc: tls@ietf.org
> Subject: Re: [TLS]Re: I-D Action: draft-ietf-tls-hybrid-design-10.txt
>
> [You don't often get email from m...@felixguenther.info. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Hi Peter,
>
> If your question is about what assumption the PQ KEM you still need to
> make in case it's not IND-CCA secure anymore and you want to fall back
> to [DOWLING] for the (EC)DH result, I think the answer is: none.
> (Beyond ensuring unambiguous encoding of KDF inputs, as the draft
> mandates through fixed-length shared secrets etc.)
>
> You would then be treating HKDF.Extract as a random oracle (which for
> PRF-ODH security is the take-away from [
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fia.cr%252
> F2017%2F517&data=05%7C02%7CPeter.C%40ncsc.gov.uk%7C56886bf3e45f4c
> 711da808dcb2f3c83a%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%
> 7C638582007420625450%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C6%7C%7
> C%7C&sdata=%2BRlEU5oghUgBNo4lKyP5qIjVaARVHCq69n2P%2B50ZDMo%3
> D&reserved=0 ]),
> where the IKM input is augmented with the (possibly
> adversary-controlled) KEM shared secret. But the encoding would ensure
> that the argument wrt. ECDH would still apply.
>
> Cheers,
> Felix
>
>
> PS: Sorry for the prior double posting; we were under the impression
> that Marc's first email didn't get delivered to the list.
>
> On 2024-08-01 11:38 +0200, Peter C  wrote:
> > Marc and Felix,
> >
> > Thank you both for your replies.
> >
> > I can see how this will work for NIST P-256 and X25519 - it is
> > straightforward to detect the equivalent public and adjust the
> > output of the simulator accordingly - and I also agree that it is
> > not a significant change to the PRF-ODH assumption.
> >
> > Have you thought how this transfers across to the hybrid key
> > exchange in draft-ietf-tls-hybrid-design?  Do you know what
> > assumption, if any, you need to make on the PQ KEM to be
> > able to reuse the argument in [DOWLING]?
> >
> > Thanks,
> >
> > Peter
> >
> >> -Original Message-
> >> From: Marc Fischlin 
> >> Sent: Monday, July 29, 2024 4:40 PM
> >> To: tls@ietf.org
> >> Subject: [TLS]Re: I-D Action: draft-ietf-tls-hybrid-design-10.txt
> >>
> >> [You don't often get email from marc.fisch...@tu-darmstadt.de. Learn why
> >> this is important at https://aka.ms/LearnAboutSenderIdentification ]
> >>
> >> Dear all,
> >>
> >> Douglas and the other "TLS co-authors" discussed this briefly, but I
> >> think that Douglas is offline for the next couple of days and asked me
> >> if I could answer on behalf of the authors.
> >>
> >> It is indeed true that the PRF-ODH assumption, as stated, wouldn't be
> >> comaptible with the usage of the x-coordinate. One needs to be a little
> >> bit more careful in this case, disallowing the adversary to flip signs
> >> of curve points. This has been done for example in a paper about the
> >> security of Bluetooth which I co-authored, where the x-coordinate is
> >> also used to derive keys. There we adapted the definition accordingly
> >> (Section 4.1 in
> https://eprint.i/
> acr.org%2F2021%2F1597.pdf&data=05%7C02%7CPeter.C%40ncsc.gov.uk%7C5
> 6886bf3e45f4c711da808dcb2f3c83a%7C14aa5744ece1474ea2d734f46dda64a
> 1%7C0%7C0%7C638582007420635222%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C6%7C%7C%7C&sdata=JMYMT3Tf5UyBBAFiV9fIQB3KKfMbmtBlubkPItW
> YTZY%3D&reserved=0 of this Asiacrypt
> >> 2021 paper). I don't think that this makes the assumption less
> >> plausible, only more annoying to deal with in the proofs.
> >>
> >> We have also checked that with the modifcation above the TLS proofs goes
> >> through as before, one only n

[TLS]Meta deploying -hybrid-design

[Deirdre Connolly]

Starting with internal connections:

https://engineering.fb.com/2024/05/22/security/post-quantum-readiness-tls-pqr-meta/

> For our deployment, we have chosen Kyber with X25519 in a hybrid setting.
Kyber is the only key encapsulation mechanism selected by NIST for
standardization so far. Kyber comes in different parameterizations:
Kyber512, Kyber768, and Kyber1024. Larger parameterizations provide
stronger security but also require more computational resources and
communication bandwidth. We aim to use Kyber768 by default, while using
Kyber512 in some cases where larger parameterizations lead to prohibitive
performance impact, to accelerate the deployment of PQC hybrid key exchange.

Challenges include large packet sizes:

> After evaluating various alternatives and workarounds, and given the
prohibitive key size of Kyber768, we opted to use Kyber512 in internal
communications affected by this problem for now, allowing us to accelerate
the PQC deployment. Kyber512’s 800-bytes-long public keys help with fitting
the ClientHello into a single TCP packet, while still being considered
secure by NIST. This choice ensures both security and efficient
communication. In the future, an increase in MTU, or utilizing QUIC, which
allows for multiple initial packets, may allow for larger ClientHellos
without an additional round trip.


and cross-domain session resumption handshake thrashing:

> As previously mentioned, we do Ephemeral Diffie-Hellman key exchange on
resumption. To facilitate efficient use of computation resources, the
client will send only the minimally required default keyshares, which in
the resumption case means the keyshare for the previously negotiated named
group. This means that when a client connects to a particular server and
negotiates a classical named group, then subsequently resumes on a server
with which the client should use a hybrid named group, the client would
advertise the hybrid named group but send only the keyshare for the
classical named group. This leads to the server negotiating the hybrid
named group and replying with a HelloRetryRequest to ask the client for the
hybrid keyshare, resulting in an additional 1-RTT to perform the key
exchange.

> To address this, we had the client split each service into different TLS
session scopes – one using classical key exchange, and one using hybrid key
exchange. Each session scope thus uses only one named group each, avoiding
the keyshare thrashing behavior described above. The tradeoff is space
consumption due to having to store more session tickets, but this has been
acceptable given the small size of each session ticket (a few hundred
bytes).

They also included more in-the-wild data on Kyber768 computational costs:

> Meta currently uses X25519 in Elliptic Curve Diffie-Hellman key exchange.
During the initial rollout of hybrid key exchange with the hybrid named
group X25519_kyber768, we observed a roughly 40 percent increase in CPU
cycles. Although this may seem like an undesirable result, it actually
indicates that Kyber768 standalone key exchange is faster than x25519,
which lines up with results others have found.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Working Group Last Call for "Hybrid key exchange in TLS 1.3"

[Deirdre Connolly]

This email starts the working group last call for the Internet-Draft
"Hybrid key exchange in TLS 1.3", located here:

https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/

The WG last call will end 26th August 2024 @ 2359 UTC.

Please review the draft and submit issues and pull requests via the GitHub
repository that can be found at:

https://github.com/dstebila/draft-ietf-tls-hybrid-design

You can also send comments and feedback to tls@ietf.org.

Cheers and thank you,
Deirdre
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org