[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AES cipher suites
Under some circumstances, I would agree with you regarding the risks of
deploying products based on ID's. And I should make clear that I am not
opposed to advancing AES-CTR, as it is faster for some applications.
However, I think your comment misses some important points. Firstly,
nothing has been found to be *wrong* with AES-CBC. Rather, it has been
pointed out that CTR mode can be parallelized in hardware, making it
faster at very high data rates.
Secondly, while an idealized scenario might entail standardization
followed by deployment, strictly in that order, the reality is that
vendors must invest resources in order to move this process forward, and
they are unlikely to do so if there is high risk of resets everytime the
next attractive algorithm shows up. And in this case (cryptographic
algorithm, as opposed to protocol, standardization), there are hardware
vendors to consider. They require significant lead times to lay out
products which the market begins clamoring for at the first hint of the
IETF. Like it or not, we cannot ignore these factors.
Given the market realities, we must be responsible in how we go about
creating standards. Creating documents with MUSTs in them, advancing
them to the end of the wg process, and creating IANA registry numbers,
when taken together, give the impression that we are on the horse at
midstream. Suddenly changing direction because another algorithm looks
attractive ignores these factors. Again, I am not advocating that we not
advance ctr mode - it is not necessary to dump one for the other - I am
saying that we should add both.
David Waitzman wrote:
> Scott G. Kelly wrote:
> > Well, maybe I'm misunderstanding, but I have the impression that the
> > general thrust of this thread has been to *replace* AES-CBC with
> > AES-CTR. There is currently an AES-CBC document in the IESG's doc queue
> > that is a product of this wg, and based on that doc, hardware has been
> > released and products have been shipped. That means that if we toss it
> > out now, lots of time and money has been wasted. I hope that I really
> > have misunderstood.
> I think you misunderstand the IETF standardization process.
> I thought the way it worked is that if you ship a product based upon just
> an I-D you are taking a big gamble. Even after DRAFT Standard things could
> change if there's a big problem.
> This should be a motivation for IETF working groups to test
> interoperability and standardize *quickly*. Yes, the RFC standardization
> process has long hold times in it, to give time for feedback. But this
> should level the playing field.