Telechat Review of draft-ietf-perc-srtp-ekt-diet-11

Request Review of draft-ietf-perc-srtp-ekt-diet
Requested rev. no specific revision (document currently at 11)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2020-02-04
Requested 2020-01-30
Authors Cullen Jennings, John Mattsson, David McGrew, Dan Wing, Flemming Andreasen
Draft last updated 2020-01-31
Completed reviews Secdir Last Call review of -08 by Hilarie Orman (diff)
Genart Last Call review of -09 by Christer Holmberg (diff)
Genart Telechat review of -11 by Christer Holmberg
Assignment Reviewer Christer Holmberg
State Completed
Review review-ietf-perc-srtp-ekt-diet-11-genart-telechat-holmberg-2020-01-31
Posted at
Reviewed rev. 11
Review result Ready with Issues
Review completed: 2020-01-31


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


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


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:


>> 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.


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:


Nits/editorial comments: