Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67BD912D84D for ; Thu, 7 Feb 2019 12:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fil4fEbq0Ic for ; Thu, 7 Feb 2019 12:18:41 -0800 (PST) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5333312F1AC for ; Thu, 7 Feb 2019 12:18:41 -0800 (PST) Received: by mail-ot1-x32c.google.com with SMTP id t5so2147073otk.1 for ; Thu, 07 Feb 2019 12:18:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZwclM8kDVtJzbS73vmgrHuBWF3GchFjMbAWvwjl1n/4=; b=wnE3/Wm4QK4p8KydZO8N2L5vfD6zKimvoButc40CSDCLm6jQOy4K7HM0vw8i732Ab3 qIBoVKJIbyxt+fOXBkZ1GJYRE8ssYv/l6W2jNQGyj7EVAiHStSkrJJuK8eO/ZZnX05CN iJHS6ji2+IwIpZwNEGTGyRFJTv6VbsGysw0Y0Fc0WGtj/in95NGnX7LHmxwGL80Rp9X1 3A66gLp/ajWWMntOZ/DDQpqqC83+vyPEAr0V/Q+gKCIM90XbkO+6g/n2+kEL+cjMIcAF cyUX/KCVJn4Fi4IBQeSJuOFve0B9vsHQJNxMzsJBy6jDY7yPIKQsahDuXhgaah61Rcim TKTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZwclM8kDVtJzbS73vmgrHuBWF3GchFjMbAWvwjl1n/4=; b=elTMGcdZU/p1g/bfK+53DZkHuNp8ESpvo3bjXwkQXzXOB7zAHylTHMeF+ayVFtgN6f oaISEHD8SgDQW5oDSpFyQDtL6Lc+00dnzTqQjgxJ2df0LVFMiyX/jhygJAqcLbEWjesh t81+z4ScGAUjCDClM1GtcdO4AqPlPSi4MZp9Fh8ctWWiRRp7ZX/lt2WuB9wmXr6OqWc4 2WXnVPEYxmagSRvKkGoR6CfltvxSsyADbWTn5oV24qiXEwMG5s6OgYmv38sCktOOgTrd CRi4Sgf5ePjr3YHzqPAA2PhPWLdI7Q/qVPC95sM6GA8LV0tN0q+e8PE4q6+AUKDo86A1 M+jw== X-Gm-Message-State: AHQUAuZ5jXjl0dMnIl5f2pN9t4y39OQ+dL22iNA9F8FypdVBoo0XmZR6 mA7GH8hDrI/x2Nb0wU3EtLLFctAvvGGF9oHyf3yF6g== X-Google-Smtp-Source: AHgI3IZ6j5GUbtsmwP6Dcv316uztRjkE/DeWZXAXmT7YoJY47k8zeq0G0aIRTGRDn++UW+QjvFjaVY4RBDKYtAkAG6s= X-Received: by 2002:a9d:3424:: with SMTP id v33mr9389766otb.167.1549570720331; Thu, 07 Feb 2019 12:18:40 -0800 (PST) MIME-Version: 1.0 References: <154007316490.13794.11476150183128445420@ietfa.amsl.com> In-Reply-To: <154007316490.13794.11476150183128445420@ietfa.amsl.com> From: Richard Barnes Date: Thu, 7 Feb 2019 15:18:18 -0500 Message-ID: To: Christer Holmberg Cc: gen-art@ietf.org, draft-ietf-perc-srtp-ekt-diet.all@ietf.org, IETF discussion list , perc@ietf.org Content-Type: multipart/alternative; boundary="000000000000570fe00581538c96" Archived-At: Subject: Re: [Gen-art] [Perc] Genart last call review of draft-ietf-perc-srtp-ekt-diet-09 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 20:18:45 -0000 --000000000000570fe00581538c96 Content-Type: text/plain; charset="UTF-8" Hi Christer, Sorry, just now seeing this. Responses inline. PR here: https://github.com/ietf/perc-wg/pull/165 --RLB On Sat, Oct 20, 2018 at 6:06 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > 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 treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-perc-srtp-ekt-diet-09 > Reviewer: Christer Holmberg > Review Date: 2018-10-20 > IETF LC End Date: 2018-11-01 > IESG Telechat date: Not scheduled for a telechat > > Summary: The document is well written, and easy to read. But, I think some > things still need to be clarified. I also have some editorial modification > suggestions. > > Major issues: > -------------- > > Q1_1: > > The text in section 1 says that EKT removes the need for co-ordinating > 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. > Q1_3: > > The text in section 1 says that EKT is not intended to replace key > establishment mechanisms, but to "be used in conjunction". > > However, there is no description on how that works in conjunction with > existing > mechanisms (e.g., together with SDP Offer/Answer), and whether existing > mechanisms need to be modified in order to work in conjunction with EKT. > > Section 5.3 does say that the SDP O/A exchange is not affected. If that is > true, then you need to describe how SSRC values etc signalled in SDP > relate to > values signalled using EKT, what happens if there are mismatches etc. > This document only defines one such augmentation -- the integration with DTLS-SRTP. I extended the relevant part of the introduction to say this. > Minor issues: > -------------- > > Q1_2: > > The text in section 1 says: > > "However, there are several cases in which conventional signaling > systems > cannot easily provide all of the coordination required." > > I think some examples would be useful. > Disagree. > Q1_4: > > The text in section 1 says that providing SSRCs etc using signaling systems > cause layer violations. > > Is this layer violation described somewhere? If so, I think a reference > would > be useful. > I just deleted this sentence. It wasn't adding much. > Q4-2_1: > > The text in section 4.2 says: > > "All of the received EKT parameter sets SHOULD be stored by all of the > participants in an SRTP session, for use in processing inbound SRTP > and SRTCP traffic." > > What is the reason for SHOULD, instead of MUST? What happens if an endpoint > does NOT store the EKT parameter sets? > I think the SHOULD here is to allow, e.g., cache management. Clarified the consequences. > Q4-2-1_2: > > The text in section 4.2.1 says: > > "Outbound packets SHOULD continue to use the old SRTP Master Key for > 250 ms after sending any new key." > > What is the reason for SHOULD, instead of MUST? > I don't think this should be a MUST. For example, how accurately are you going to measure compliance? If the change-over is 10ms short 10% of the time, is the endpoint out of compliance. Plus, there's minimal interop impact; this just helps things go smoothly. > Q4-3_2: > > The text in section 4.3 says: > > "Section 4.2.1 recommends that SRTP senders continue using an old key > for some time after sending a new key in an EKT tag." > > The text in section 4.2.1 contains a SHOULD, so it is more than a > recommendation. > According to RFC 2119, a SHOULD is precisely a recommendation: """ 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. """ https://tools.ietf.org/html/rfc2119#section-3 > Nits/editorial comments: > -------------------------- > > Q1_5: > > I think Section 1 should also indicate that EKT is an DTLS extension, > similar > to the Abstract. Otherwise, when you say that EKT is a way to distribute > information, it is unclear why EKT doesn't violate layers. > Done. > I think that Section 2 (Overview) could be combined with Section 1 > (Introduction). Introduction sections in RFCs typically provide both > background, problem statement and an overview of the mechanism - and > sometimes > also the document structure. > Disagree. > Q4_1: > > The text in section 4.1 says: > > "EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key > Identifier) or with SRTP's [RFC3711], as those SRTP > features duplicate some of the functions of EKT. Senders MUST NOT > include MKI when using EKT. Receivers SHOULD simply ignore any MKI > field received if EKT is in use." > > I suggest to put this text in a dedicated Applicability section. > Disagree. > Q4-1_1: > > The text in section 4.1 says: > > "Together, these data elements are called an EKT parameter set. Each > distinct EKT parameter set that is used MUST be associated with a > distinct SPI value to avoid ambiguity." > > I suggest to defined "EKT parameter set" in the same way as the other > terminology. I.e., > > "EKT parameter set: The parameters indicated by the SPI" > > ....or something like that. > There's not a terminology section, so I didn't do exactly what you say. But I pulled this out into a separate section so that it doesn't interrupt the flow, and clarified that the SPI-params association is set up by the DTLS-SRTP extension. Q4-2-1_1: > > For the section names of sections 4.2.1 and 4.2.2, I suggest to talk about > sending/transmitting and receiving instead of inbound and outbound. > Disagree > Q4-3_1: > > In section 4.3, I think the name of the section ("Implementation Notes") > is a > little confusing. Also, is there a reason why the text is not in section > 4.2.1 > and/or 4.2.2? > Just folded this into section 4.2.2. > Q4-4_1: > > Sections 4.4 and 4.4.1 have the same section names. Please change one of > them > (e.g., change 4.4.1 to "Default Cipher"). > Changed to "AES Key Wrap" > Q4-6_1: > > I think the text in section 4.6 should be placed in the Applicability > section I > suggested earlier (Q4_1). > Merged it into section 4. > Q5_1: > > In section 5, I suggest to change the section name to "DTLS-SRTP > Considerations". > Disagree. > > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --000000000000570fe00581538c96 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Christer,
Sorry, just now seeing this.=C2=A0 Responses inline.=C2=A0 PR h= ere:


--RLB

On Sat, Oct 20, 2018 at 6:06 PM Christer Holmberg <christer.holmberg@ericsson.c= om> wrote:
https://trac.ietf.org/trac/gen/wiki/GenArtfaq&g= t;.

Document: draft-ietf-perc-srtp-ekt-diet-09
Reviewer: Christer Holmberg
Review Date: 2018-10-20
IETF LC End Date: 2018-11-01
IESG Telechat date: Not scheduled for a telechat

Summary: The document is well written, and easy to read. But, I think some<= br> things still need to be clarified. I also have some editorial modification<= br> suggestions.

Major issues:
--------------

Q1_1:

The text in section 1 says that EKT removes the need for co-ordinating SSRC= s,
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 introd= uction: "EKT does not control the manner in which the SSRC is generate= d..." -- it just makes the distribution of security information easier= .=C2=A0 I extended that paragraph to clarify.

=C2= =A0
Q1_3:

The text in section 1 says that EKT is not intended to replace key
establishment mechanisms, but to "be used in conjunction".

However, there is no description on how that works in conjunction with exis= ting
mechanisms (e.g., together with SDP Offer/Answer), and whether existing
mechanisms need to be modified in order to work in conjunction with EKT.
Section 5.3 does say that the SDP O/A exchange is not affected. If that is<= br> true, then you need to describe how SSRC values etc signalled in SDP relate= to
values signalled using EKT, what happens if there are mismatches etc.

This document only defines one such augmenta= tion -- the integration with DTLS-SRTP.=C2=A0 I extended the relevant part = of the introduction to say this.

=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> Minor issues:
--------------

Q1_2:

The text in section 1 says:

=C2=A0 =C2=A0"However, there are several cases in which conventional s= ignaling systems
=C2=A0 =C2=A0cannot easily provide all of the coordination required."<= br>
I think some examples would be useful.

= Disagree.
=C2=A0
Q1_4:

The text in section 1 says that providing SSRCs etc using signaling systems=
cause layer violations.

Is this layer violation described somewhere? If so, I think a reference wou= ld
be useful.

I just deleted this sentence= .=C2=A0 It wasn't adding much.

=C2=A0
Q4-2_1:

The text in section 4.2 says:

=C2=A0 =C2=A0"All of the received EKT parameter sets SHOULD be stored = by all of the
=C2=A0 =C2=A0participants in an SRTP session, for use in processing inbound= SRTP
=C2=A0 =C2=A0and SRTCP traffic."

What is the reason for SHOULD, instead of MUST? What happens if an endpoint=
does NOT store the EKT parameter sets?

= I think the SHOULD here is to allow, e.g., cache management.=C2=A0 Clarifie= d the consequences.

=C2=A0
Q4-2-1_2:

The text in section 4.2.1 says:

=C2=A0 =C2=A0"Outbound packets SHOULD continue to use the old SRTP Mas= ter Key for
=C2=A0 =C2=A0250 ms after sending any new key."

What is the reason for SHOULD, instead of MUST?

I don't think this should be a MUST.=C2=A0 For example, how ac= curately are you going to measure compliance?=C2=A0 If the change-over is 1= 0ms short 10% of the time, is the endpoint out of compliance. Plus, there&#= 39;s minimal interop impact; this just helps things go smoothly.
<= div>
=C2=A0
Q4-3_2:

The text in section 4.3 says:

=C2=A0 =C2=A0"Section 4.2.1 recommends that SRTP senders continue usin= g an old key
=C2=A0 =C2=A0for some time after sending a new key in an EKT tag."

The text in section 4.2.1 contains a SHOULD, so it is more than a
recommendation.

According to RFC 2119, = a SHOULD is precisely a recommendation:

"&quo= t;"
3. SHOULD=C2=A0=C2=A0 This word, or the adjective "= RECOMMENDED", mean that there
=C2=A0=C2=A0 may exist valid reasons = in particular circumstances to ignore a
=C2=A0=C2=A0 particular item, bu= t the full implications must be understood and
=C2=A0=C2=A0 carefully we= ighed before choosing a different course.
"""


=C2=A0
Nits/editorial comments:
--------------------------

Q1_5:

I think Section 1 should also indicate that EKT is an DTLS extension, simil= ar
to the Abstract. Otherwise, when you say that EKT is a way to distribute information, it is unclear why EKT doesn't violate layers.

Done.

=C2=A0
I think that Section 2 (Overview) could be combined with Section 1
(Introduction). Introduction sections in RFCs typically provide both
background, problem statement and an overview of the mechanism - and someti= mes
also the document structure.

Disagree.<= br>
=C2=A0
Q4_1:

The text in section 4.1 says:

=C2=A0 =C2=A0"EKT MUST NOT be used in conjunction with SRTP's MKI = (Master Key
=C2=A0 =C2=A0Identifier) or with SRTP's <From, To> [RFC3711], as = those SRTP
=C2=A0 =C2=A0features duplicate some of the functions of EKT.=C2=A0 Senders= MUST NOT
=C2=A0 =C2=A0include MKI when using EKT.=C2=A0 Receivers SHOULD simply igno= re any MKI
=C2=A0 =C2=A0field received if EKT is in use."

I suggest to put this text in a dedicated Applicability section.

Disagree.
=C2=A0
Q4-1_1:

The text in section 4.1 says:

=C2=A0 =C2=A0"Together, these data elements are called an EKT paramete= r set.=C2=A0 Each
=C2=A0 =C2=A0distinct EKT parameter set that is used MUST be associated wit= h a
=C2=A0 =C2=A0distinct SPI value to avoid ambiguity."

I suggest to defined "EKT parameter set" in the same way as the o= ther
terminology. I.e.,

=C2=A0 "EKT parameter set: The parameters indicated by the SPI"
....or something like that.

There's= not a terminology section, so I didn't do exactly what you say.=C2=A0 = But I pulled this out into a separate section so that it doesn't interr= upt the flow, and clarified that the SPI-params association is set up by th= e DTLS-SRTP extension.
=C2=A0

Q4-2-1_1:

For the section names of sections 4.2.1 and 4.2.2, I suggest to talk about<= br> sending/transmitting and receiving instead of inbound and outbound.

Disagree
=C2=A0
Q4-3_1:

In section 4.3, I=C2=A0 think the name of the section ("Implementation= Notes") is a
little confusing. Also, is there a reason why the text is not in section 4.= 2.1
and/or 4.2.2?

Just folded this into sec= tion 4.2.2.

=C2=A0
Q4-4_1:

Sections 4.4 and 4.4.1 have the same section names. Please change one of th= em
(e.g., change 4.4.1 to "Default Cipher").
Changed to "AES Key Wrap"

= =C2=A0
Q4-6_1:

I think the text in section 4.6 should be placed in the Applicability secti= on I
suggested earlier (Q4_1).

Merged it int= o section 4.

=C2=A0
Q5_1:

In section 5, I=C2=A0 suggest to change the section name to "DTLS-SRTP=
Considerations".

Disagree.
=C2=A0


_______________________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc
--000000000000570fe00581538c96--