On Mon, Dec 11, 2006 at 12:38:58PM -0800, Vishwas Manral wrote:
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?
Yes, something like that would be fine. My suggestion:
Similarly SHOULD-NOT implement algorithms cannot be recommended or
required by applications.
There's no need to say anything about MUST-NOT algorithms since there
aren't any.
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.
I don't think it's entirely obvious, and I think I may be missing some
historical background.
Use of the NULL ESP algorithm implies no confidentiality protection,
while use of the NULL AH algorithm implies no integrity protection
(unless combined mode ESP algorithms are used). And in general we want
IPsec used to provide integrity or confidentiality+integrity protection,
but not really just confidentiality protection.
So it makes sense to recommend against use of the NULL AH algorithm
generally.
But I suspect that confidentiality without integrity protection was once
somewhat common, thus the NULL AH. My guess is that the requirement
that NULL ESP and NULL AH not be used together comes from such a time.
But what really should be said is that NULL AH should not be used,
period.
This should be explained. It's not your fault that RFC4305 didn't
explain it.
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.
Steven answered my concern. Perhaps the MUST-/SHOULD+ isn't all that
useful in terms of predicing what those requirements/recommendations
will be in the future. Oh well. I withdraw my comment.
- 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?
What I meant is that the changes made to RFC4305 should be listed in the
same section as (or sub-section of) the section that lists changes since
earlier RFCs.
I guess two tables, or multiple additional rows in the existing table in
that section, will do. I don't care which it is. And perhaps the
RFC-Editor would do that work anyways(?).
Nico
--
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf