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

> -----Original Message-----
> From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen
> Sent: Monday, August 14, 2017 9:05 AM
> To: Michael Richardson
> Cc: ipsec@ietf.org; Daniel Van Geest; Graham Bartlett (grbartle)
> Subject: Re: [IPsec] Proposed method to achieve quantum resistant IKEv2
> 
> Michael Richardson writes:
> > I don't think we need to do this.
> > I think that unknown transform types will be ignored by compliant
> > implementations.
> 
> Nope. It will ignore unknown transform IDs for each known transform type,
> but it MUST understand each transform type, and if it does not understand it
> cannot pick one value for it, thus it must ignore the whole proposal, and try
> to use other proposals which might work better.

Actually, where in RFC5996 (or 4301) does it say that it must go on to the next proposal , rather than (say) silently rejecting the entire negotiation?  I searched through the text, and cannot find a MUST (or even a SHOULD) statement...

And, in the 11+ years since IKEv2 has been defined, we haven't added a single transform type.  I would suspect that most implementations have never tested out the scenario where they've seen an unexpected transform type (but which is followed by another proposal which is acceptable).  How certain are we that implementations will process the request as we hope?

After all, a large point of this exercise is backwards compability; if a QR IKEv2 initiator tries to talk to a nonupgraded IKEv2 responder, it works as we expect (that is, depends on the initiator's security policy, they either downgrade to a non-QR key exchange, or they abort the exchange as they had no mutually acceptable policy).  Hence, the actual behavior of real nonupgraded responders is important.

> --
> kivinen@iki.fi
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec