[Gen-art] Genart last call review of draft-ietf-perc-double-10

Russ Housley <housley@vigilsec.com> Sat, 20 October 2018 08:24 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Russ Housley <housley@vigilsec.com>
To: gen-art@ietf.org
Cc: perc@ietf.org, ietf@ietf.org, draft-ietf-perc-double.all@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154002385712.13693.18098361756799542976@ietfa.amsl.com>
Date: Sat, 20 Oct 2018 01:24:17 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/OPEvP7EOg97XpMN05CiJR2NXW4g>
Subject: [Gen-art] Genart last call review of draft-ietf-perc-double-10

Reviewer: Russ Housley
Review result: Almost Ready

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
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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_outer_(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) ||
                                    PRF_(n/2)(outer(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.


Nits:

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/

[Gen-art] Genart last call review of draft-ietf-p… Russ Housley
Re: [Gen-art] Genart last call review of draft-ie… Richard Barnes
Re: [Gen-art] [Perc] Genart last call review of d… Alissa Cooper