[Gen-art] Genart telechat review of draft-ietf-perc-srtp-ekt-diet-11

Christer Holmberg via Datatracker <noreply@ietf.org> Fri, 31 January 2020 11:48 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: gen-art@ietf.org
Delivered-To: gen-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 099F612081E; Fri, 31 Jan 2020 03:48:17 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Christer Holmberg via Datatracker <noreply@ietf.org>
To: gen-art@ietf.org
Cc: last-call@ietf.org, draft-ietf-perc-srtp-ekt-diet.all@ietf.org, perc@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.116.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Christer Holmberg <christer.holmberg@ericsson.com>
Message-ID: <158047129698.21175.5113712510703403314@ietfa.amsl.com>
Date: Fri, 31 Jan 2020 03:48:17 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/leV-v09Mq4Pah9CzmTMDtZ1YGII>
Subject: [Gen-art] Genart telechat review of draft-ietf-perc-srtp-ekt-diet-11
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jan 2020 11:48:17 -0000

Reviewer: Christer Holmberg
Review result: Ready with Issues

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 wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-perc-srtp-ekt-diet-11
Reviewer: Christer Holmberg
Review Date: 2020-01-31
IETF LC End Date: None
IESG Telechat date: 2020-02-06

Summary:

I took a long time before I got a reply to my original review comments, and now
I realize that I never addressed that reply. Sorry for that.

In my previous review, I had a number of editorial suggestions (Minor Issues),
and in many cases the author did not agree to those. I will not pursue those,
but leave it to the IESG to decide whether something needs to be done.

Many of my issues have been addressed in the latest version. However, I do
still have a couple of issues. One of them (Q1_1) is a follow-up from my
previous review, and for convenience I will include the discussion content in
this review.

Major issues:

Q1_1:

>> The text in section 1 says that EKT removes the need for coordinating
>> SSRCs,and that an endpoint can choose whatever value it wants.
>>
>> However, I can't find any explanation on how EKT removes that need.
>
> The answer is toward the end of the introduction: "EKT does not control the
> manner in which the SSRC is generated..." -- it just makes the distribution
> of security information easier.  I extended that paragraph to clarify.

As far as I understand, SSRC collisions can still occur. But, if that occurs,
endpoints can provide the new SSRC using EKT – without the need for OOB
solutions or signaling – and that is the reason EKT removes the need for
coordinating SSRCs. I think it would be good to clarify that.

Q_1_2:

Section 5.3 reference RFC 3264 for the Offer/Answer procedures. However, since
the text is specific to DTLS-SRTP, I think the reference should be to RFC 5763
and draft-ietf-mmusic-dtls-sdp.

I assume this also applies to the RFC 3264 reference in Section 4.1
(SRTPMasterKeyLength definition).

Minor issues:

N/A

Nits/editorial comments:

N/A