Subject: [MSEC] Fwd: draft-ietf-msec-ipsec-group-counter-modes-04

From: Brian Weis <[email-masked]>
Date: Tue, 12 Jan 2010 14:35:58 -0800

Alfred HÎnes reviewed this MSEC WG draft, but had trouble posting to  
the list. His comments are attached.

Brian

Begin forwarded message:

> From: Alfred HÎnes <[email-masked]>
> Date: January 12, 2010 1:05:19 PM PST
> To: [email-masked], [email-masked]
> Cc: [email-masked]
> Subject: draft-ietf-msec-ipsec-group-counter-modes-04
>
> Hello,
> one nit and one DISCUSS for draft-ietf-msec-ipsec-group-counter- 
> modes-04:
>
>
> The easy one first:  In the last paragraph of Section 2,
> an indefinite article is missing; please insert it:
>
>   [...], where single IPsec Security Association (SA) is used [...]
> ---            vvv
>   [...], where a single IPsec Security Association (SA) is used [...]
>
>
> DISCUSS:
>
> There's a proliferation of documents that specify black-box exchanges
> of the AES with other block ciphers with compatible interface for all
> security protocols standardized in the IETF.
>
> In the interest of proper layering in the "crypto-toolbox",
> simplifying the expected document set, and reducing the load on the
> I-D approval and RFC publication processes, I strongly suggest to
> immediately generalize your memo to <any> "AES-like" block cipher.
>
> If that strategy is not followed, you can expect to have to deal with
> follow-up documents for Camellia, SEED, ..., that do not add any new
> information to the present draft.
>
> The document title already raises this expectation.
>
> The Abstract needlessly specializes to AES.
>
> In Section 1, some of the references to given are already neutral
> regarding the cipher, inparticular RFC 2386 is that for CTR mode.
>
> I suggest to outline the general framework of using counter modes
> with a block cipher primitive and instantiate that with the AES
> examples and related references.
>
> Every detail given in subsequent sections is not specific to the AES
> but immediately generalizes to any block cipher with a 128-bit block
> size.  That should be made explicit, IMO.
>
> In Section 2, it almost suffices to simply  s/AES/block cipher/g .
> In Sections 3..6 and Appendix A, "AES" does not even appear in the  
> text.
>
> Appendix B with AES-GCM as an example is perfectly ok.
>
>
> Kind regards,
>  Alfred HÎnes.
>
> -- 
>
> +------------------------ 
> +--------------------------------------------+
> | TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.- 
> Phys.  |
> | Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax:  
> -18         |
> | D-71254  Ditzingen     |  E-Mail:  ah@TR- 
> Sys.de                     |
> +------------------------ 
> +--------------------------------------------+
>

-- 
Brian Weis
Router/Switch Security Group, ARTG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]