Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev2-multiple-ke

From: "[email-masked]" <[email-masked]>
Date: Mon, 9 Aug 2021 19:05:03 +0000

Good afternoon,

Has there been any thought on whether to include more information on KEMs specifically, with regard to the KeyGen, Encaps, and Decaps algorithms? It is my understanding that a public key (pk) will be sent in the KEi payload and that a ciphertext (ct) will be sent in the KEr payload. The hybrid draft for TLS 1.3 does provide this info and gives a brief explanation of how the KEM data maps to TLS, included below:

"For the client's share, the "key_exchange" are the "pk" outputs of the corresponding KEMs' "KeyGen" algorithms, if that algorithm corresponds to a KEM; or the (EC)DH ephemeral key share, if that algorithm corresponds to an (EC)DH group.  For the server's share, the "key_exchange" values are the "ct" outputs of the corresponding KEMs' "Encaps" algorithms, if that algorithm corresponds to a KEM; or the (EC)DH ephemeral key share, if that algorithm corresponds to an (EC)DH group."

Thanks,

Rebecca Guthrie
NSA’s Center for Cybersecurity Standards

---

From: CJ Tjhai <[email-masked]>
Date: Tue, 10 Aug 2021 14:52:24 +0100

Hi Rebecca,

The draft document aims to be as generic as possible, treating the KE
payload as opaque. It should cater for cases such as:
- multiple key exchanges involving more than one (EC)DH groups (perhaps due
to policy requirements);
- combinations of (EC)DH and KEM;
- KEM only, either single or multiple key-exchanges;
- or perhaps future post-quantum key-exchange that is analogous to DH
key-exchange;

I expect that, as in the case of RFC8031 describing how to use Curve25519
and Curve448 on IKEv2, there will be specific documents on how to use a
post-quantum key-establishment algorithm that follows this draft. So if the
algorithm is a KEM, I expect the detail of the KEi and KEr to be described
there.

Best regards,
CJ

On Mon, 9 Aug 2021 at 20:05, [email-masked] <rmguthr=
[email-masked]> wrote:

>
>
> Good afternoon,
>
>
>
> Has there been any thought on whether to include more information on KEMs
> specifically, with regard to the KeyGen, Encaps, and Decaps algorithms? It
> is my understanding that a public key (pk) will be sent in the KEi payload
> and that a ciphertext (ct) will be sent in the KEr payload. The hybrid
> draft for TLS 1.3 does provide this info and gives a brief explanation of
> how the KEM data maps to TLS, included below:
>
>
>
> "For the client's share, the "key_exchange" are the "pk" outputs of the
> corresponding KEMs' "KeyGen" algorithms, if that algorithm corresponds to a
> KEM; or the (EC)DH ephemeral key share, if that algorithm corresponds to an
> (EC)DH group.  For the server's share, the "key_exchange" values are the
> "ct" outputs of the corresponding KEMs' "Encaps" algorithms, if that
> algorithm corresponds to a KEM; or the (EC)DH ephemeral key share, if that
> algorithm corresponds to an (EC)DH group."
>
>
>
> Thanks,
>
>
>
> Rebecca Guthrie
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

-- 

PQ Solutions Limited (trading as ‘Post-Quantum’) is a private limited 
company incorporated in England and Wales with registered number 06808505.

This email is meant only for the intended recipient. If you have received 
this email in error, any review, use, dissemination, distribution, or 
copying of this email is strictly prohibited. Please notify us immediately 
of the error by return email and please delete this message from your 
system. Thank you in advance for your cooperation.

For more information 
about Post-Quantum, please visit www.post-quantum.com 
<http://www.post-quantum.com>.

In the course of our business relationship, 
we may collect, store and transfer information about you. Please see our 
privacy notice at www.post-quantum.com/privacy-notice 
<http://www.post-quantum.com/privacy-notice> to learn about how we use this 
information.