> -----Original Message----- > From: Tero Kivinen <[email protected]> > Sent: Wednesday, October 31, 2018 7:04 PM > To: Scott Fluhrer (sfluhrer) <[email protected]> > Cc: Valery Smyslov <[email protected]>; IPsecME WG > <[email protected]>; [email protected] > Subject: Re: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske- > ikev2-02 > > Scott Fluhrer (sfluhrer) writes: > > My issue with this general idea is backwards compatibility; if we > > issue a transform of type 5 to an old IKEv2 system, it may reject the > > entire exchange with an "unrecognized transform type" error (and yes, > > there are real systems that behave this way). > > That implementation is broken, and needs to be fixed.
I can easily see a manufacturer claiming "my implementation has been working without a problem for 13 years; why does it need to be fixed?" Ultimately, it's the working group that needs to decide whether we need to respect the (to the implementors) apparently valid assumption as de facto, or whether we feel we can break them. > > > Valery: > > > For these reasons I think a different approach is more > > > convenient: we define new transform types as follows: > > > > > > Transform Type 6: Additional QSKE performed in 1st IKE_AUX > > > Transform Type 7: Additional QSKE performed in 2nd IKE_AUX > > > Transform Type 8: Additional QSKE performed in 3rd IKE_AUX > > > etc. (How many do we want to combine?) > > > > > > The same list of possible Transform IDs representing QSKE > > > methods will be defined for each of these new Transform Types. In > > > addition these QSKE Transform IDs (or some of them with a small > > > enough public key) will also be added to the list of possible > > > Transform IDs for Transform Type 4. > > > > Why not make them all a possible transform id for type 4? After all, > > there are scenarios where fragmentation is not an issue (e.g. TCP > > encaps) > > If all of them are Transform Type 4, i.e. D-H, then responder MUST pick > exactly one that is the only one to be used. Responder is not allowed return > more than one Transform ID for each Transform Type there is in proposal. I believe that you misinterpreted my question. This comment was in the context of Valery's proposal; in his last sentence "In addition these QSKE Transform IDs (or some of them with a small enough public keys)..." Valery suggested that some of the new QSKE transform id's were also to be added to the supported type 4 list. My query is "why not include all of them in the list of valid type 4 transform types?" For that matter (I didn't express this earlier, but I'll do it now) why not make the acceptable transform types for type 4, 6, 7, 8, etc to be exactly the same? It would appear to me that mandating they be different (but have common entries) actually adds complexity for no good reason. > > > Now, one thing that had been bothering me with our proposal is that > > there is no way to include attributes along with the transform id. > > Now, the existing DH/ECDH transforms do not have any attributes > > defined; however some of the NIST submissions have a large number of > > variations (Round2 had 30 different ones), and while we could make > > each variation a different transform id (which is effectively what we > > did with DH and ECDH; there really is only one DH algorithm; the exact > > transform id selected which parameters were used with that algorithm), > > however it's not clear if that's the approach we want to mandate with > > the newer postquantum transforms. > > Each Transform ID can also have arbitrary number of attributes inside, and > the as you can have multiple entries with same Transform Type, but either > different Transform ID or different Attributes inside, the responder can pick > exactly one of the Transform Type of that type, and include all attributes > unmodified. Actually, I was making this comment in the context of "our proposal" (draft-tjhai-ipsece-hybrid-qske-ikev2-02), which negotiates the additional KE groups not within the IKE transform structure, but as 16 bit integers, and noting that the structure doesn't allow us to pass attributes along with the transform types (which the IKE transform structure does); I was wondering out loud if we would need to support attributes (which haven't been used in the context up until now). _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
