Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT)

[Tero Kivinen <[e-mail]>]

Paul Wouters writes:
> > -3: I wonder why "... is not to be used..." is not "... MUST NOT be
> > used...". But the section goes on to say if you do it anyway, you MUST
> > NOT use certain cryptosuites. So, does "... is not to be used..." mean
> > "SHOULD NOT"? Or is this one of those "MUST NOT BUT WE KNOW YOU WILL"
> > sort of requirements?
> 
> It is indeed. I think a SHOULD NOT would actually be appropriate ?

We do not want to make the implementation of the manual keying MUST
NOT, as it is still useful in testing and similar situations, but we
do not want anybody using it in any real world use cases. As this
document is mostly about the implementation and tries to stay out from
the issues about what should be used (as explained in the 2nd
paragraph of the section 1.3).

On the other hand section 1.3 is really about the use of the manual
keying, not about the implementation of manual keying, so that
confuses things (we do have some other cases were we say things DES
MUST NOT be used).

I think the text needs to be clarified about this bit more, especially
we do not want to say that ENCR_AES_CBC MUST be used, as there are
other algorithms which can also be used (MUST be used would indicate
no other algorithm is possible).

> > - Table in section 6:
> > I'm boggled by the first entry being labeled "MUST/MUST NOT". I don't see
> > anything in the text to explain the "MUST" part--did I miss something?
> 
> 
> First paragraph under the table:
> 
>     AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT.  The
>     only reason NULL is acceptable is when authenticated encryption
>     algorithms are selected from Section 5.  In all other cases, NULL
>     MUST NOT be selected.

It does not make it easier that there is typo in that paragraph, and
it talks about NULL, when it should be talking about AUTH_NONE... 
-- 
[e-mail]