[Gen-art] Re: Gen art review: draft-maino-fcsp-02.txt (resend)

[Elwyn Davies <[e-mail]>]

Resending as David said he got an empty message.

Regards,
Elwyn

====================================

Hi, David.

In this case, the review *really* was my pleasure!

It wasn't totally obvious that FC-SP is going to specify the list of
current algorithms.  A comment added to each of 4.1 and 4.2 to the
effect that 'The recommended and required algorithms are specified in
[FC-SP], and [FC-SP] allows for additional future transforms to be
standardized and used.'  would certainly cover my concerns.  The ESP
draft/RFC ref (the old one if you are in a hurry I guess) is a nice to
have.  In 4.2 s/defined/defined initially/.

I guess Russ could get RFC Editor instructions for the changes to keep
things moving along.

Regards,
Elwyn

[e-mail] wrote:

>Elwyn,
>
>Thanks for the review.  I don't think any significant changes are
>needed:
>
>  
>
>>s4.1, last para: It might be good to cite 
>>RFC2402RFC2406/draft-ietf-ipsec-esp-ah-algorithms-02.txt to cover all 
>>the 'standard' algorithms rather than one specific algorithm 
>>(RFC3602).
>>    
>>
>
>Not exactly.  RFC 3602 is correctly cited as an example in a sentence
>saying that all algorithms for ESP are applicable.  It would be wrong
>to cite anything related to AH, as there will be no support for any form
>of AH in Fibre Channel.  A reference to the ESP RFC would be reasonable
>to add.
>
>The recommended and required algorithms for ESP in FC will be specified
>in the FC-SP standard, and a number of existing IPsec algorithms are
>likely to be required.  OTOH, it would be wrong to reference even the
>ESP portion of the algorithms draft, as the FC algorithm requirements
>are likely to be different (e.g., FC has a strong interest in AES-GCM).
>
>  
>
>>s4.2, last para: Nothing is said here about alternative future integrity 
>>algorithms. Given recent discussion about attacks on MD5 and SHA1, and 
>>general views about the need for security algorithms to be replaceable 
>>limiting integrity protection to just two current algorithms is not a 
>>good idea.
>>    
>>
>
>The "attacks on MD5 and SHA1" do not work on the keyed HMAC-based
>integrity algorithms used here.  The integrity algorithms are replaceable,
>as the SAID functions similarly to an IPsec SPI in selecting the algorithms
>to apply and I could see adding a sentence to say that.  In fact one of
>the reasons for having IANA allocate values for these algorithms is
>to make it easier to replace them, and I could see adding a sentence
>to say that.
>
>The suggested reclassifications of references are reasonable, although
>the IANA allocations that result from this draft becoming an RFC are
>necessary to complete the FC-SP standard.
>
>The editorial suggestions can be handled between the RFC Editor and
>Authors 48 hours.
>
>Thanks,
>--David
>----------------------------------------------------
>David L. Black, Senior Technologist
>EMC Corporation, 176 South St., Hopkinton, MA  01748
>[phone]             FAX: [phone]
>[e-mail]        Mobile: [phone]
>----------------------------------------------------
>  
>
>>-----Original Message-----
>>From: Elwyn Davies [mailto:[e-mail]] 
>>Sent: Tuesday, September 27, 2005 4:29 AM
>>To: [e-mail]; Mary Barnes; Russ Hously; 
>>[e-mail]; Black, David
>>Subject: Gen art review: draft-maino-fcsp-02.txt
>>
>>Background for those on the CC list, who may be unaware of GenART:
>>GenART is the Area Review Team for the General Area of the IETF.  We
>>advise the General Area Director (i.e. the IETF/IESG chair) by providing
>>more in depth reviews than he could do himself of documents that come up
>>for final decision in IESG telechat.  I was selected as the GenART
>>member to review this document.  Below is my review, which was written
>>specifically with an eye to the GenART process, but since I believe that
>>it will be useful to have these comments more widely distributed, others
>>outside the GenART group are being copied.
>>
>>Document: draft-maino-fcsp-02.txt
>>Intended Status: Informational (individual submission via AD)
>>Shepherding AD: Russ Housley
>>Review Trigger: IESG Telechat 29/9/05
>>
>>Summary:
>>An excellent document IMO - easy to read and with excellent balance 
>>between motivation, explanation and technical detail! Kudos to the 
>>authors.  Given this document is informing the IETF about what Fibre 
>>Channel is doing, there is no obligation to fix up the couple of issues 
>>relating to extensibility/future proofing but given IETF experience, it 
>>might be appropriate to consider remedying them.  There are also some 
>>editorial nits.
>>
>>Review:
>>Generally an excellent document.  Given recent IETF experience and the 
>>general degradation over time of the value of security algorithms, I 
>>think it would be appropriate to provide very explicitly for algorithm 
>>replacement, especially as regards the integrity algrithms which are (as 
>>I read the document) currently fixed.  The first two issues give the 
>>details:
>>
>>s4.1, last para: It might be good to cite 
>>RFC2402RFC2406/draft-ietf-ipsec-esp-ah-algorithms-02.txt to cover all 
>>the 'standard' algorithms rather than one specific algorithm (RFC3602).  
>>Also it would probably be good to make it crystal clear that any future 
>>transforms that might be invented to go with ESP would be available for 
>>use for Fibre Channel.
>>
>>s4.2, last para: Nothing is said here about alternative future integrity 
>>algorithms.  Given recent discussion about attacks on MD5 and SHA1, and 
>>general views about the need for security algorithms to be replaceable 
>>limiting integrity protection to just two current algorithms is not a 
>>good idea.
>>
>>s8.1: I would consider refs FC-FS, FC-GS and FC-SP as normative.
>>
>>s8.2: I think RFCs 2625, 3643 and 3821 are informative as the various 
>>payloads are not IP encapsulated.
>>
>>Editorial nits:
>>s4, para 3: s/Preambol/Preamble/
>>
>>s4, last para: s/Security Association for/Security Associations for/
>>
>>s4.1: Fields are 'normalized before computation': presumably this is 
>>clear to somebody skilled in the Fibre Channel arts but a ref to the 
>>appropriate piece of specification or an inline description 
>>would help 
>>for the unenlightened.
>>
>>s4.1, Figure 1: Technically the 'Auth' coverage should be 'Integrity' 
>>coverage (and this would match with the corresponding figure in 
>>draft-ietf-ipsec-esp-v3-10.txt).
>>
>> s5.2, para 2: s/protocol ID/protocol IDs/
>>
>>s5.4, para 5 (next to last): s/he function/the function/
>>
>>s5.4, last para: s/Associaton/Association/
>>
>>s6, para 2: s/then there are no theoretical limitations/so that there 
>>are no a priori limitations/ (the previous phrase gives the 
>>theoretical 
>>limit of 4GB!)
>>
>>s8.2: Should be entitled Normative References
>>
>>    
>>


_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art