Last Call Review of draft-ietf-ipsecme-rfc4307bis-15
review-ietf-ipsecme-rfc4307bis-15-opsdir-lc-hares-2017-02-01-00
| Request | Review of | draft-ietf-ipsecme-rfc4307bis |
|---|---|---|
| Requested revision | No specific revision (document currently at 18) | |
| Type | Last Call Review | |
| Team | Ops Directorate (opsdir) | |
| Deadline | 2016-12-30 | |
| Requested | 2016-12-16 | |
| Authors | Yoav Nir , Tero Kivinen , Paul Wouters , Daniel Migault | |
| Draft last updated | 2017-02-01 | |
| Completed reviews |
Genart Last Call review of -15
by
Pete Resnick
(diff)
Secdir Last Call review of -15 by Phillip Hallam-Baker (diff) Opsdir Last Call review of -15 by Susan Hares (diff) Genart Telechat review of -17 by Pete Resnick (diff) |
|
| Assignment | Reviewer | Susan Hares |
| State | Completed | |
| Review |
review-ietf-ipsecme-rfc4307bis-15-opsdir-lc-hares-2017-02-01
|
|
| Reviewed revision | 15 (document currently at 18) | |
| Result | Ready | |
| Completed | 2017-02-01 |
review-ietf-ipsecme-rfc4307bis-15-opsdir-lc-hares-2017-02-01-00
Yaov, Tero, Paul and Daniel
I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review. Document editors and WG chairs should
treat these comments just like any other last call comments.
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./