Subject: [IPsec] Clarification on my comments during the WG about possible KE payloads > 64k

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Sun, 25 Mar 2018 17:36:05 +0000

During the WG meeting in London, somebody (I forget who) asked me whether KE payloads larger than 64k.  I thought I ought to clarify matters (as they are more complex than the brief answer I gave indicated).

Of the proposed postquantum key exchange (and public key encryption algorithms, which can be used to transport keys) submitted to NIST, the majority of them have key shares (or public keys/ciphertexts) smaller than 64k; there are a handful that are larger.  Now, it is possible (albeit unlikely) that all the algorithms with key shares < 64k will be broken; unless this happens, it would be reasonable (IMHO) that we mandate that any algorithm he allow have a KE payload that fits within 64k.  Now, in the event that we feel the need to support larger key shares, there are possible ways to support that; I don't feel that we need to talk about those options now.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 25 Mar 2018 23:00:12 +0300

Hi, Scott.

That was me. When they started talking about about PQC a decade ago, they mentioned algorithms like McEliece with public keys around 1MB.

Not that this is a deal-killer. If necessary, we would come up with an IKE extension to have “jumbo-sized payloads” that had 24-bit lengths. IKE over TCP (RFC 8229) can handle this easily.

But anyway, since the current state of the art seems to not need such an extension, I guess there’s no point it bringing this up now.

Yoav

> On 25 Mar 2018, at 20:36, Scott Fluhrer (sfluhrer) <[email-masked]> wrote:
> 
> Of the proposed postquantum key exchange (and public key encryption algorithms, which can be used to transport keys) submitted to NIST, the majority of them have key shares (or public keys/ciphertexts) smaller than 64k; there are a handful that are larger.  Now, it is possible (albeit unlikely) that all the algorithms with key shares < 64k will be broken; unless this happens, it would be reasonable (IMHO) that we mandate that any algorithm he allow have a KE payload that fits within 64k.  Now, in the event that we feel the need to support larger key shares, there are possible ways to support that; I don’t feel that we need to talk about those options now.
> _______________________________________________
> IPsec mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 26 Mar 2018 10:27:45 +0300

Hi Yoav,

just for clarification:

          Actually, not so easily. Despite the fact that IKE Message header has a length field of 32 bits, 

          the message prefix in RFC 8229 is only 16 bits in size, so no single IKE message transferred

          over TCP can be greater than 64K. IKE fragmentation could help in this case,

              but RFC 8229 says that “implementation SHOULD NOT send fragments when going over a TCP”.

          However the good news is that “it MUST support receiving fragments.” So we just need to violate that SHOULD.

          Regards,

          Valery.

Yoav

_______________________________________________
IPsec mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/ipsec> https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Garcia-Morchon O, Oscar" <[email-masked]>
Date: Mon, 26 Mar 2018 07:58:20 +0000

Hi Scott,

I see your point.

But I can imagine that very conservative users (critical applications) might want to use some of the schemes that have been out there for a longer period of time (e.g., McEliece). This can be specially true at the beginning, while other more efficient schemes get more verification.

>From this point, I think that if the requirements (>64k) of those schemes need to be taken into account, then those should be taken into account now.

Regards, Oscar.

From: IPsec [mailto:[email-masked]] On Behalf Of Scott Fluhrer (sfluhrer)
Sent: Sunday, March 25, 2018 7:36 PM
To: IPsecme WG ([email-masked]) <[email-masked]>
Subject: [IPsec] Clarification on my comments during the WG about possible KE payloads > 64k

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 26 Mar 2018 22:05:00 +0300

Garcia-Morchon O, Oscar writes:
> From this point, I think that if the requirements (>64k) of those
> schemes need to be taken into account, then those should be taken
> into account now.

I think the best way to make them work is to keep the individual
payload length less than 64k, but QSKE (or whatever the new payload is
called) so that it can provide separate pieces of actual KE payload.
This way we also get acks etc for each piece, and if there is errors
we do not need to resend the whole n MB message, but instead we resend
(and reassemble and buffer) <64kB piece of the KE inside one
fragmented ike exchange.

I.e. instead of having:

Original Message:

   HDR(MID=n), SK(NextPld=PLD) {PLD(2MB)}

Fragmented Message:

   HDR(MID=n), SKF(NextPld=PLD, Frag#=1, TotalFrags=128)
   	       {first 16kB of PLD} -->
   HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=128)
   	       {next 16kB of PLD } -->
   ...
   HDR(MID=n), SKF(NextPld=0, Frag#=128, TotalFrags=128)
   	       {last 16kB of PLD}  -->

	       <-- HDR(MID=n) response ack

(and here would need to assume that 16kB UDP packet would get properly
IP-fragmented as IKE fragmentation supports only at maximum of 255
fragments).

We could do something like this:

   HDR(MID=n), SKF(NextPld=PLD, Frag#=1, TotalFrags=16)
   	       {first 1kB of PLD(0/128, first 16kB of PLD)} -->
   HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=16)
   	       {next 1kB of PLD(0/128, first 16kB of PLD)} -->
   ...
   HDR(MID=n), SKF(NextPld=0, Frag#=16, TotalFrags=16)
   	       {last 1kB of PLD(0/128, first 16kB of PLD)} -->

	       <-- HDR(MID=n) ACK

   HDR(MID=n+1), SKF(NextPld=PLD, Frag#=1, TotalFrags=16)
   	       {first 1kB of PLD(1/128, next 16kB of PLD)} -->
   HDR(MID=n+1), SKF(NextPld=0, Frag#=2, TotalFrags=16)
   	       {next 1kB of PLD(1/128, next 16kB of PLD)} -->
   ...
   HDR(MID=n+1), SKF(NextPld=0, Frag#=16, TotalFrags=16)
   	       {last 1kB of PLD(1/128, next 16kB of PLD)} -->

	       <-- HDR(MID=n+1) response ack
   ...
   HDR(MID=n+128), SKF(NextPld=PLD, Frag#=1, TotalFrags=16)
   	       {first 1kB of PLD(128/128, last 16kB of PLD)} -->
   HDR(MID=n+128), SKF(NextPld=0, Frag#=2, TotalFrags=16)
   	       {next 1kB of PLD(128/128, last 16kB of PLD)} -->
   ...
   HDR(MID=n+128), SKF(NextPld=0, Frag#=16, TotalFrags=16)
   	       {last 1kB of PLD(128/128, last 16kB of PLD)} -->

	       <-- HDR(MID=n+128) response ack

I.e., we use normal IKEv2 fragmentation and send for example 16kB
pieces in each of the IKE_AUX exchange, but we have multiple IKE_AUX
exchanges, and each of them will deliver one piece of the full QSKE to
the other end, so if each piece is 16 kB, we will have 128 of those
16kB pieces.

The normal fragmentation code will not be changed and IKEv2 exchanges
are still processed normally without any special handling, only think
that requires special handling is the QSKE payloads which can contain
multiple pieces where each piece is delivered in separate exchange.

There are some other complications if responder also needs to send
large things back, thus the initiator needs to know to do empty
requests to responder until final pieces of the responders QSKE
arrives (in case responders QSKE was bigger than initiators). 
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 27 Mar 2018 10:48:50 +0300

Hi,

> called) so that it can provide separate pieces of actual KE payload.

That's exactly what I suggested in https://mailarchive.ietf.org/arch/msg/ipsec/jahWqh_dvPkqAXnA4-C9LndtWWk

> IP-fragmented as IKE fragmentation supports only at maximum of 255

No, IKE fragmentation allows to have up to 2^16 fragments, so it possible to transfer
up to ~60MB of key data with no IP fragmentation (assuming each IKE fragment
contains ~1000 bytes of key data).

> arrives (in case responders QSKE was bigger than initiators).

Or probably change roles for a while and make the responder to initiate 
a reverse requests to transfer its large KE to initiator. Not sure
it is better though...

If the particular QSKE is DH-like (assuming that initiator's and responder's 
public keys are of the same size and are computed independently), then
the much better approach is possible:

   HDR (IKE_AUX, MID = 1), SK {KE(1st piece of initiator's public key)}  -->
                                     <--  HDR (IKE_AUX, MID = 1), SK {KE(1st piece of responder's public key)}

   HDR (IKE_AUX, MID = 2), SK { KE(2nd piece of initiator's public key)}  -->
                                     <--  HDR (IKE_AUX, MID = 2), SK {KE(2nd piece of responder's public key)}

   HDR (IKE_AUX, MID = 3), SK {KE(3rd piece of initiator's public key)}  -->
                                     <--  HDR (IKE_AUX, MID = 3), SK { KE(3rd piece of responder's public key)}

...

   HDR (IKE_AUX, MID = 3), SK {KE(last piece of initiator's public key)}  -->
                                     <--  HDR (IKE_AUX, MID = 3), SK { KE(last piece of responder's public key)}

Pieces can be made very small to avoid fragmentation at all, or larger, so that 
IKE fragmentation will take place, but the number of fragments each message is divided
info is small, so that the initiator would not need to resend large amount of data
in case of packet loss.

Regards,
Valery.