[IPsec] Benoit Claise's No Objection on draft-ietf-ipsecme-rfc4307bis-15: (with COMMENT)

["Benoit Claise" <[e-mail]>]

Benoit Claise has entered the following ballot position for
draft-ietf-ipsecme-rfc4307bis-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Here is Sue Hares' OPS DIR feedback:
Status:  Read for publication with editorial nits (see below)

 

General Comment:  Thank you for this interesting, informative, and
well-written draft.  My editorial nits are just places you might improve
the clarity of the draft.

 

 

Sue Hares

 

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

 

Editorial Nits:

 

#1 – Section 1.3, p 4, paragraph 1

 

Old/The recommendations of this document mostly target IKEv2
implementers

   as implementations need to meet both high security expectations as

   well as high interoperability between various vendors and with

   different versions.  /

 

New: /The recommendations of this document mostly target IKEv2
implementation 

   as implementations need to meet both high security expectations as

   well as high interoperability between various vendors and with

   different versions.  /

 

Note: Either implementation as implementations

         Or  implementers as implementers need to create
implementations

 

 

#2 – section 1.3, p. 4,paragraph 2 

 

 

3) Old/ This document does not give any recommendations for the use of

   algorithms, it only gives implementation recommendations for

   implementations./

 

   New /   This document does not give any recommendations for the use
of

   algorithms, it only gives implementation recommendations regarding

   implementations./

 

#3 section 3.1, p. 6 , paragraph 2, starting with
“ENCR_CHACHA20_POLY1305”

 

   Please expand the abbreviation CRFG.  I believe this this is the first
use of the abbreviation. 

 

#4 section 3.4, p 9-10,  several paragraphs in here did not provide the
final status

 

4.a p9, last paragraph on page 


old/  Group 14 or 2048-bit MODP Group is raised from SHOULD+ in RFC4307
as

   a replacement for 1024-bit MODP Group. / 

 

new/ Group 14 or 2048-bit MODP Group is raised from SHOULD+ in RFC4307 to
MUST as

   a replacement for 1024-bit MODP Group. / 

 

 

4.b p. 9, first paragraph on page, line 1

 

 Old/  Group 19 or 256-bit random ECP group was not specified in RFC4307,
as

   this group were not defined at that time.  Group 19 is widely

   implemented and considered secure./

 

New /  Group 19 or 256-bit random ECP group was not specified in RFC4307,
as

   this group were not defined at that time.  Group 19 is widely

   implemented and considered secure so Group 19’s status is SHOULD.

 

4.c p.9, paragraph 4, line 

Old/   Group 1 or 768-bit MODP Group was not mentioned in RFC4307 and so
its

   status was MAY.  It can be broken within hours using cheap of-the-

   shelves hardware.  It provides no security whatsoever./ 

 

New/ Group 1 or 768-bit MODP Group was not mentioned in RFC4307 and so
its

   status was MAY.  It can be broken within hours using cheap of-the-

   shelves hardware.  It provides no security whatsoever. Therefore, its


   current stsatus is MUST not. 

 

#5 section 4.1, p 12, paragraph 2-4: Final status not indicatd

 

5.a: paragraph 2 

 

Old/   Shared Key Message Integrity Code is widely deployed and mandatory
to

   implement in the IKEv2 in the RFC7296./

 

  New:/ Shared Key Message Integrity Code is widely deployed and
mandatory to

   implement in the IKEv2 in the RFC7296. The status is MUST. /

 

5.b paragraph 3

 

  Old/ 

   ECDSA based Authentication Methods are also expected to be
downgraded

   as it does not provide hash function agility.  Instead, ECDSA (like

   RSA) is expected to be performed using the generic Digital Signature

   method. / 

 

  New/ 

   ECDSA based Authentication Methods are also expected to be
downgraded

   as it does not provide hash function agility.  Instead, ECDSA (like

   RSA) is expected to be performed using the generic Digital Signature

   method. ECADSA-based Authentication Methods status is “SHOULD”. /

 

 

 

5.c. paragraph 4 

 

Old:/  DSS Digital Signature is bound to SHA-1 and has the same level
of

   security as 1024-bit RSA.  It is expected to be downgraded to MUST

   NOT in the future./ 

 

 

New/ 

   DSS Digital Signature is bound to SHA-1 and has the same level of

   security as 1024-bit RSA.  It is currently at SHOULD NOT, but 

   it is expected to be downgraded to MUST

   NOT in the future./

 

 

5.d paragraph 5 

 

Old/  Digital Signature [RFC7427] is expected to be promoted as it
provides

   hash function, signature format and algorithm agility./

 

New/  Digital Signature [RFC7427] is expected to be promoted as it
provides

   hash function, signature format and algorithm agility. Its current
status is SHOULD.