Hi Paul,
there is no heuristics in my proposal. The initiator's SA payload contains
all PRFs it supports. The responder can pick up any of them and be sure that
the chosen PRF is supported by initiator. It is a native negotiation mechanism
of IKEv2.
And note that DDoS protection draft uses exactly the same mechanism.
And I never said that support for AES will be removed. I meant that there are
some alternatives for AES (like Chacha20), which are not supported in hardware.
Moreover, if (for example) SHA2 is supported in hardware tomorrow, then
there will be no perfirmance advantages in using AES.
What about the registries - I just follow Occam's razor principle.
Regards,
Valery.
-----Original Message-----
From: Paul Hoffman
Date: 20 февраля 2016 г. 18:12
To: Valery Smyslov
Cc: ipsec@ietf.org
Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01
<no hat>
Your proposal of using heuristics from the SA payload instead of using a
new registry seems like a bad tradeoff. It costs nothing to create a new
registry. Further, the code that implementers need to write to use the
new registered value is smaller *and more definitive* than the code
needed to use your proposed heuristics.
As for your prediction that AES support might be removed from some CPUs
in the future: that seems particularly unlikely. Basically, you never
see CPU features removed from a product line. You sometimes see new
families of low-end CPUs designed without all the features of current
CPUs, but even that would not be a negative here. Further, if we need
algorithms beyond AES in the future, it seems really likely that a
competition for a replacement would favor one that could re-use the AES
support in current chips.
I think a small registry for the (hopefully) few developers who care
about QR a decade before anyone thinks there is any possibility of its
use is a reasonable way forward.
--Paul Hoffman
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
