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

[Michael Richardson <[e-mail]>]

Tero Kivinen <[e-mail]> wrote:
    > Daniel Van Geest writes:
    >> 1) QS SA Negotiation
    >>
    >> When negotiating a QS SA, it’s not enough to negotiate QS key
    >> agreement algorithm(s), one also has to ensure that the algorithms
    >> selected by the other transform types are also QS.

    > All of these kind of issues are really policy matters, thus outside
    > the PROTOCOL work. I.e., we can add security considerations section

I agree.

    > On the other hand this is ONLY needed if the initiator DOES NOT know
    > whether other end supports QS or not. Usually initiator can be
    > configured to assume either way, it is more important to configure the
    > responder so it will accept either QS or non-QS...

I think that one goes around and enables the new QS policy in nodes as one
upgrades them to have QS.  An implementation could have a policy knob like:
         QS=forbid,accept,propose,insist
         (a bit like MUSTNOT,MAY,SHOULD,MUST)

which would add the extra proposals.  One starts with "QS=accept" or
"QS=propose", which so that one can interoperate with nodes which have not
yet been upgraded, and then perhaps moves to QS=insist.

I think we are in agreement here, just want to be clear I'm not disagreeing.
One only needs the huge SA_INIT during the transition period between
QS=propose to QS=insist.  Still that could be many months to even years.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-