2009/10/23 Alfred HÎnes
<ah at tr-sys.de>
Sean Shen wrote:
> Section 2.2 says that "AES MUST use different rounds for each of the
> key sizes: ...".
> The draft is not trying to say that IKEv2 requires 10/12/14 rounds for
> 128/192/256 key lengths. The draft is not trying to say that AES-CTR
> requires 10/12/14 rounds for 128/192/256 key lengths.
>
> Sean
>
> ...
The "MUST" still makes the difference! That is normative and does
NOT belong into this draft. Although that would still be regarded
out of scope of your draft, I would be more willing to accept an
_informative_ statement like:
"Note: AES uses different rounds for each of the key sizes: ...".
^^^^^^ ^^^^
[Sean] Correct, "MUST" is defined in key words conventions and should not be used here. I will dropt it.
But the most important topic remains: The draft is ill-advised in
pretending that the interface of AES -- or, btw, *any* currently
sensibly used block cipher primitive of reasonable strength --
had an _external_ parameter "number of rounds" that upper protocol
(sub-)layers would need to have to deal with.
Otherwise, the "IKEv2 Transform Attribute Types" would have to
include an entry for "number of rounds", which it doesn't, and
you also do not aim at establishing such entry.
[Sean] The IKEv2 requirement in the draft is only about key lengths. I never pretended that the AES standard allows arbitary conbinations of key lengths and rounds.
I checked the document again and noticed that in the second paragraph of section 2:
"... The choices of Key Size, Rounds and Block Size are defined as following which are compatible with [RFC3686]."
If this sentense misleads readers to think that users can choose all conbinations, I will rewrite it as:
"... The choices of Key Size are defined as following which are compatible with [RFC3686]."
Best Regards,
Sean
