Last Call Review of draft-ietf-perc-double-10

Request Review of draft-ietf-perc-double
Requested rev. no specific revision (document currently at 12)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-11-01
Requested 2018-10-18
Authors Cullen Jennings, Paul Jones, Richard Barnes, Adam Roach
Draft last updated 2018-10-20
Completed reviews Secdir Last Call review of -10 by Radia Perlman (diff)
Genart Last Call review of -10 by Russ Housley (diff)
Assignment Reviewer Russ Housley 
State Completed
Review review-ietf-perc-double-10-genart-lc-housley-2018-10-20
Reviewed rev. 10 (document currently at 12)
Review result Almost Ready
Review completed: 2018-10-20


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

Document: draft-ietf-perc-double-10
Reviewer: Russ Housley
Review Date: 2018-10-20
IETF LC End Date: 2018-11-01 
IESG Telechat date: unknown

Summary: Almost Ready

Major Concerns:

Section 10: Doesn't the IANA registry needs to specify the PRF to be
used with the ciphersuite as well?

Minor Concerns:

Section 3: It would be useful to explain the Master Key before the
reader gets to Section 3.1.

Section 3.1: It is unclear what assistance is provided by the
additional level of indirection:

         PRF_double_n(k_master,x) = PRF_inner_(n/2)(k_master,x) ||

         PRF_inner_n(k_master,x)  = PRF_n(inner(k_master),x)
         PRF_outer_n(k_master,x)  = PRF_n(outer(k_master),x)

It could just say:

         PRF_double_n(k_master,x) = PRF_(n/2)(inner(k_master),x) ||

Section 4: I suggest:

	If the marker bit is not present, then B MUST be set to zero.

Section 5, 1st paragraph: and endpoint cannot verify confidentiality.


The document uses "encryption" and "confidentiality" interchanagably.
Encryption is a mechanism or algorithm.  Confidentiality is a security
service.  While I do not think that the reader will be confused by the
current wording, it would be better to use the terms properly.  In
addition, it is misleading to say:

   ... the receiving endpoint that can encrypt and authenticate ...

because the sending endpoint encrypts, and the recieving endpoints
decrypts.  Also, the receiving endpoints check the authentication tag.

Abstract: s/authenticated encryption with associated data/
           /authenticated encryption with associated data (AEAD)/

Abstract: s/scheme/algorithm/

Section 5.2: s/GCM/AES-GCM/

Section 7: s/HBH/hop-by-hop/

Section 7: s/E2E/end-to-end/

Section 7.1: s/HBH/hop-by-hop/

Section 7.2: The text is redundant.  I suggest "etc" be dropped from
"such as SSRC, SEQ, CSRC, etc"

Section 7.2: s/non primary/non-primary/

Section 7.3: s/HBH/hop-by-hop/

Appendix A: s/HBH/hop-by-hop/

Appendix A: s/E2E/end-to-end/