Hi CJ, > > That implementation is broken, and needs to be fixed. > > What's the procedure on this? Is there a need to publish a document or > some test vectors that all implementations can validate against? > > Personally, it is more logical to introduce new transform types for > QSKEs, but one of my concerns is how can we guarantee that all broken > implementations are fixed?
Of course there is no guarantee... However, as we repeated several times, this solution is not intended to be deployed in a nearest future. We don't yet even have QSKE methods that are more or less trusted by the majority of cryptographers (as far as I understand). So, vendors have plenty of time to fix their implementations and to align there with RFC. And yes, I do understand, that it doesn't mean that all customers will upgrade to a new version... On the other hand, some broken implementations can be dealt with. Just add an additional checks on initiator. > Consider the following simplified proposal: > > SA Payload > | > +--- Proposal #1 ( Proto ID = IKE(1), SPI size = 0, > | | 6 transforms) > +-- Transform ENCR ( Name = ENCR_AES_CBC ) > | +-- Attribute ( Key Length = 256 ) > +-- Transform PRF ( Name = PRF_HMAC_SHA2_512 ) > +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 ) > +-- Transform D-H ( Name = Curve25519 ) > +-- Transform QSKE1 ( Name = Foobar ) > +-- Transform QSKE2 ( Name = Zappa ) > > At the moment, some broken implementations may abort the exchange > entirely and in some way, this helps as we may want to establish a > connection with a broken implementation. On the other hand, there > could be other implementations that ignore both QSKE1 and QSKE2 and > return a response as if there is an implicit second proposal: > | > +--- Proposal #2 ( Proto ID = IKE(1), SPI size = 0, > | 4 transforms) > | > +-- Transform ENCR ( Name = ENCR_AES_CBC ) > | +-- Attribute ( Key Length = 256 ) > +-- Transform PRF ( Name = PRF_HMAC_SHA2_512 ) > +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 ) > +-- Transform D-H ( Name = Curve25519 ) > > So more complex checks will be required to cater for all broken cases. > I have no idea what response we will get from other broken > implementations. Yes, we can develop some checks against most obvious types of brokenness. > Or alternatively, do we have to rely on another Notification payload > to check for potential backward compatibility issues? Implementations can rely on AUX_EXCHANGE_SUPPORTED. If responder doesn't return it, then it might be broken, so restart the exchange with only classical KE methods included. > I think it would be great to also get some thoughts from VPN > manufacturers on this point. Sure. Regards, Valery. > Cheers, > CJ _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
