Re: Review of draft-manral-ipsec-rfc4305-bis-errata-02.txt

[Vishwas Manral <[e-mail]>]

Hi Nicolas,

I agree with a lot of the comments. Some minor doubts are in-lined:
Nicolas Williams wrote:
> - A section was added on application-specific ESP/AH algorithm
>    implementation requirements.  The text allows application protocols
>    to add algorithm implementation requirements or to upgrade MAY/SHOULD
>    requirements in RFC4305/RFC4305bis to SHOULD/MUST, but it does not
>    allow relaxing MUST implement algorithms.
>
>    Nothing is said as to whether applications can relax SHOULD NOT
>    implement requirements.  Specifically DES-CBC is a SHOULD NOT
>    implement algorithm.  Perhaps text should be added forbidding the
>    relaxation of SHOULD NOT requirements; certainly the issue should be
>    clarified.
>
>   
Its an interesting note and I understand the concern. Would adding text 
like "Similarly SHOULD-NOT and MUST-NOT cannot be made a MAY either" help?
> The security considerations section appears to be unchanged, and by and
> large the other changes made in this I-D should not require security
> section changes.  However, I find it odd that the body of the RFC and
> I-D says that the NULL algorithms MUST NOT be used in AH and ESP at once
> but no text explains why (besides there may be security considerations
> about using certain ESP algorithms with the NULL AH algorithm).  If this
> is explained in some other RFC then a reference to it would be useful;
> if not then please add security considerations text explaining the
> matter.
>   
I hope I understand what you are pointing to. Though the text has been 
carried from RFC4305, I feel it is an obvious requirement for the use of 
IPsec (at least one of the crypto algorithm needs to be enabled). Or are 
you looking for the rationale of making the NULL Authentication 
algorithm from a MUST to a MAY? I guess RFC4301 talks about that clearly.
> Also, I'm not sure that the use of "MUST-" and "SHOULD+" is actually
> useful.  In this update no algorithms previously classified as MUST-
> have been downgraded, and no algorithms previously classified as SHOULD+
> have been upgraded.  It seems likely to me some AES cipher mode will
> eventually become a MUST, but it's not clear to me that AES-CBC, for
> example, which is marked SHOULD+, will be it.  Therefore I would argue
> that these designations should be changed to MUST and SHOULD,
> respectively.  Or perhaps this I-D is a good opportunity to downgrade
> TripleDES-CBC to SHOULD or MAY and upgrade either AES-CBC and/or AES-CTR
> to MUST?
>   
I agree with Steven here, for CTR mode one of the security consideration 
is that the same starting point should never be used twice. I am ok, 
making the CBC as well as CTR mode a SHOULD+. The couple of IPsec 
implementations I have worked on, we have got the requirement for 
AES-CBC as well as AES-CTR modes.
>  - Appendix B should be integrated into the "Changes from RFC 2402 and
>    2406" section (which should now be titled "Changes from RFCs 2402,
>    2406 and 4305").
>   
I have this doubt. Should we check the changes from RFC2402 and RFC2406 
to the new draft, or should we make the changes in two steps i.e. from 
RFC2402 and RFC2406 to RFC4305 and then from RFC4305 to the new draft. I 
thought the latter approach was better?

Thanks,
Vishwas



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