Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

[Daniel Van Geest <[e-mail]>]

On Aug 9, 2017, at 2:12 PM, Michael Richardson <[e-mail]<mailto:[e-mail]>> wrote:
I don’t find the re-use of transform 4 in this proposal, and the
implicit combination of QS + non-QS algorithms, to be the most elegant,
though I can understand it in the context of not wanting to add a new
transform type.

So you are suggesting that the QR mechanism be a new transform type then?
I could live with that actually since it make the combinatorics easier to manage.

Yes, I’m suggesting reconsidering putting the QR key agreement algorithms in a new transform type. This is part of CJ’s & co's suggestion from the original draft, but this was rejected in Prague. Their transform type was added to the proposals in the SA payload, while I’m suggesting only using it in a new QS_SA payload. (Perhaps eventually it could migrate to the SA payload in future drafts if non-QR connections ever need to be removed from IKEv2).

The idea is to add the new transform type 6 (Q-S-Group) like CJ’s
proposal, but don’t include it in the SA payload. Rather, introduce a
new QS_SA payload which would be identical in structure to the SA
payload except that it would also include the Q-S-Group transform
type. An endpoint could configure the proposals in this payload to

I don't think we need to do this.
I think that unknown transform types will be ignored by compliant
implementations.

The reason why the original suggestion was rejected in Prague was because of backwards compatibility issues with non-compliant implementations. From experience, StrongSwan is non-compliant in this regard. If it receives a proposal with a transform type that it doesn’t understand it will pretend that the transform type isn’t there rather than rejecting the proposal and moving on to the next one. Thus it can end up responding with a proposal which the initiator didn’t suggest.

For example, if the initiator is configured to send:

ike=aes256-sha512-modp3072-newhope128,aes128-sha256-modp2048!

A non-upgraded StrongSwan will reply with:

aes256-sha512-modp3072

which from the initiator’s perspective is not one of its suggestions. The initiator will then error out and fail to establish the connection. We could define this new transform type as optional and hope that other implementations don’t behave even more poorly than this. But maybe an initiator doesn’t want to use aes256-sha512-modp3072 if it’s not talking to an upgraded responder, maybe for performance reasons it would prefer using weaker primitives with them.

Putting the QS proposals in a separate QS_SA payload would also allow an initiator to mark the payload as critical if it wants to require QS connections.

Something to keep in mind is that many QS key agreement algorithms
don’t have exactly the same message flow as Diffie Hellman. With DH,
each endpoint’s public/private keys can be generated independently of
each other. But many QS algorithms have an initiator-responder flow, so
the responder can only generate its public key once it has processed
the initiator’s public key. We just need to keep this in mind when
designing the flow of the PRE_AUTH messages. An initiator can’t send
the first chunk of a public key, and the responder reply with the first
chunk of their public key, the responder would need to process all
initiator chunks for that key first. This means the initiator would
have to send a special acknowledgement response for chunks that don’t
complete a public key rather than responding with a partial key when
receiving a partial key.

Would the initiator know how much data to expect from the responder?
If so, the initiator can just keep sending query messages to get new blocks
of data back.

I’d answer that with a tentative yes. From the algorithms I’ve seen that’s the case, though one could imagine an algorithm where some (possibly non-deterministic amount of?) padding is added for some reason or other? Regardless, even if the initiator doesn’t know the amount of data to expect, it can keep querying and the responder payload could include a terminator flag indicating it is the last chunk of data.

If we decide that we want to be able break up the QR public key payloads across multiple message exchanges, then do we have to add some mechanism for the endpoints to agree on the maximum size of each message? Declaring a chunk size as part of the spec may not be a good idea because some QR public keys are ~1.5Kb while others are >64Kb. So picking a small chunk size to avoid IKEv2 fragmentation means many message exchanges when using large key sizes, but picking large chunk sizes increases the changes of dropping IKEv2 fragments and having to retransmit entire messages.

—
Daniel Van Geest ([e-mail]<mailto:[e-mail]>)
https://www.isara.com/