From nobody Fri Oct 5 07:48:57 2018 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E214130DDF for ; Fri, 5 Oct 2018 07:48:55 -0700 (PDT) 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 pW-zp3Nc50Nl for ; Fri, 5 Oct 2018 07:48:51 -0700 (PDT) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (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 12D88130DEB for ; Fri, 5 Oct 2018 07:48:50 -0700 (PDT) Received: by mail-oi1-x22f.google.com with SMTP id e17-v6so10599706oib.4 for ; Fri, 05 Oct 2018 07:48:50 -0700 (PDT) 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=j8K6nuGNc4z2FOjc+qKwqgoTudPTN8aoMu1qf70/5S0=; b=nqnUUz7gU0KrFHciULl6UFsvBQkjd4y6OdizhPrnB8DzZVbTwQSqKcBBj3aU1vQBFI dLQrH493s31zRHOZ6cRq/oUQ3Nb6EiIkcdHO6VUJk59ZGzH5OR8uxvU/O1TEbo8FZhka DjZwhj6U8lBZOySwwPJitp0JB+Lf0/agnQx9tMpaQ0bC+rCmgBNLBNO8S+0T4pXlVtuR 7OB4s9herzR59KBKmty2Fp+5soAQQVCIijqpbNnXhfETF0haax/bdeN9Pb8XvPqhBQVv F9B9yLJhyYRs3VpqnrpIbbCg85O2Psh+h62MvA9H5xP/hKxtFhd+nuKwPYZAWWPcKi8i EcQg== 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=j8K6nuGNc4z2FOjc+qKwqgoTudPTN8aoMu1qf70/5S0=; b=l28VfWbktX9hAbXefqGgww+qlxPpMhWG2maP5BRa2J3RiC1QNno4wVkEs3CMnfAosy PvXyx+3eFIAiFV/OaMn/H6hZJvsC5BNpBmjDirg754YZ4lVDlfuIZdXTfImRfaclCKBN V5aOv9ntTwD+i3raor9WdrocpfM4+P6cSwJWsXeN94SLYiv7kJ79bf31rAZfKp53iWz5 yYRBaL4Ek+3JSp42ozeDRgrsJkmg06PTHXaxTHoQdobbJaUiquenLrlrljAIK7rTQiMw DSzG7Bs2tZPn2hec3W7HqfqUvv/EJQhaHsQy3uzgWB02kGwH4rijfvBHzTL0zWCrX9Q9 sJ+Q== X-Gm-Message-State: ABuFfoiOy4Wj+9mOAs2rkjqIvmZvnGM38nRcCzNZj2vzl3unvdRzi5NZ xjgRShG+3VBVfjLe6s6kPsFRIQgv0MOoNB3mik8oYxyTVqUeIg== X-Google-Smtp-Source: ACcGV6252hRMEavbqW2fIOy0uanTHmBq225HAd62B3Ja8Lx8R8AX1ZpvdmoyjMxJ88/TS7RH66URDVBguMMnEizHQn8= X-Received: by 2002:aca:3195:: with SMTP id x143-v6mr5883624oix.213.1538750930031; Fri, 05 Oct 2018 07:48:50 -0700 (PDT) MIME-Version: 1.0 References: <5AFC524E-7C2A-4C8F-B66B-7BAA3F048403@nostrum.com> In-Reply-To: <5AFC524E-7C2A-4C8F-B66B-7BAA3F048403@nostrum.com> From: Richard Barnes Date: Fri, 5 Oct 2018 10:48:37 -0400 Message-ID: To: Ben Campbell Cc: draft-ietf-perc-double.all@ietf.org, perc@ietf.org Content-Type: multipart/alternative; boundary="00000000000095298205777c5e10" Archived-At: Subject: Re: [Perc] AD Evaluation of draft-ietf-perc-double-09 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 14:48:55 -0000 --00000000000095298205777c5e10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Ben, After talking with Cullen, I am now the stuckee for this. I've filed a PR at: https://github.com/ietf/perc-wg/pull/160 Comments inline below. On Tue, Jun 5, 2018 at 12:40 AM Ben Campbell wrote: > Hi, > > This is my AD Evaluation of draft-ietf-perc-double-09. Thanks for this > work; I think it is important and on the right track, but suffers from so= me > readability issues, especially from =C2=A77 onwards. I=E2=80=99d like to = discuss my > comments prior to IETF last call. > > Thanks! > > Ben. > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94 > > *** Substantive Comments *** > > General: Does it make sense to progress this prior to > draft-ietf-perc-private-media-framework rather than wait and progress the= m > together? it seems like one really needs to read the framework to > understand at least parts of this draft. (Which would, btw, suggest makin= g > the framework a normative reference.) > I think at this point, -framework has caught up a bit (I understand it's awaiting your review), so this seems OBE. I agree that it will make easier reading for ADs to read the three docs (this, framework, and EKT) on the same telechat. > =C2=A72, Media Distributor: Should this be defined as switch-based? Other= wise > it seems circular. > I've copied down the definition =C2=A71, which explicitly says that the MD = does not need to interpret or change media content. Also added a ref to -framework at this point. > =C2=A75 and subsections: These sections are confusing in the treatment of > extensions. =C2=A75.1 step 3 says to truncate the header to remove any > extensions. Yet other sections of text repeatedly mention the handling of > extensions. I think the document needs a paragraph or two to describe the > handling of RTP extensions at a high level. > I've added an overview of the transform, including thoughts on extensions, to the top of =C2=A75. > Along those lines, it=E2=80=99s not entirely clear what is meant by putti= ng =E2=80=9C (12 > + 4 * CC bytes)=E2=80=9D in parentheses after the guidance to truncate in= =C2=A75.1. Is > that the amount to be truncated? Amount left after truncation? (Same > question for =C2=A75.3) > Clarified that this is the amount left after truncation, i.e., take the first N bytes, in both places. > =C2=A75.2: It would be helpful to include a paragraph or two to describe = the > impact if multiple MDs modify the same field(s). I can infer that, but it > would be better to be explicit. (IIRC, there is a passing mention in the > security considerations, but it would be better to have more here.) > Added a paragraph. > =C2=A78: Can you offer any guidance about selecting 128 vs 256? > I don't really think there's much to say here; it's up to the user of the transform. Use 128 unless you're paranoid, then use 256? :) Note that RFC 7714, which defines the AES-GCM transforms, does not provide similar guidance. > =C2=A79: > > - The security considerations mainly summarize the mechanism. I=E2=80=99d= like to > see a description of the potential attacks or risks and how the double > mechanism mitigates them. > - =E2=80=9C=E2=80=A6 this shouldn=E2=80=99t typically impact the strength= of e2e integrity given > the fact that there doesn=E2=80=99t exist header extensions defined today= that > needs e2e protection. However, if future specifications define header > extensions that needs e2e integrity protection, the input to inner > transform may be modified to consider including the header.=E2=80=9D > > - 2nd paragraph: Why is the HBH key for an outgoing packet only > =E2=80=9Ctypically=E2=80=9D different than the key for the incoming packe= t? Are there > security implications if they are the same? > > - 2nd to last paragraph, last sentence: Please elaborate on those risks? > I agree with your assessment that the existing security considerations were not that useful. I've replaced them with an analysis that's more focused on what protections are provided with respect to which attackers. The new version also calls out clearly that when a packet is re-encrypted, the outer keys MUST be different. > *** Editorial comments and nits *** > > There are a number of abbreviations that need to be expanded on first use= . > Please remember that abbreviations should be expanded both in the abstrac= t > and the body. > > - SRTP > - SSRC > - SEQ > - ROC > - PRF > - PT > - SEQ > - RTX > - RED > - FEC > I've expanded most of these. I have left SSRC, SEQ, ROC, and PT, since in this context, they are basically opaque labels for RTP header fields. > =C2=A72: > - Please use the boilerplate from RFC8174. There are a number of lower > case instances of normative keywords. > Done. > - Please use consistent sentence (or lack of sentence) structure for the > definitions in the bullet list. > Done. > =C2=A73, > > - " Generate key and salt values of the length required for the combined > inner (end-to-end) and outer (hop-by-hop) algorithms.=E2=80=9D: The docum= ent is > inconsistent in whether it describes a single key with inner and outer > halves, or separate inner and outer keys. I realize that this is an > artifact of syntax, but it is likely to confuse a reader new to the topic= . > The very next bullet says to glue them together. Not sure how else to say this. > - Paragraph starting with =E2=80=9CObviously, if the Media Distributor=E2= =80=A6=E2=80=9D: > =E2=80=9CObviously=E2=80=9D is a null word in context. > Deleted. > =C2=A73.1: This section would be much more approachable if you defined th= e > terms (such as n, k, and x), rather than forcing readers to look them up = in > 3711. Also, the doubled crypto suite IDs are likely to be confusing to th= e > reader who sees them here without the explanation later in the draft. > Done. > =C2=A75.2, step 2: =E2=80=9CChange any parts of the RTP packet=E2=80=A6= =E2=80=9D -The MS is limited to > changing the 3 fields defined for the OHB, right, at least as defined in > this draft? Not just anything it wants? > Correct. Done. > =C2=A75.3, last two paragraphs: It=E2=80=99s sort of an odd construction = to talk about > =E2=80=9Cany of the following=E2=80=9D with a single entry list. > Revised to clarify. > =C2=A77 and subsections: These could use another proofreading pass. In > particular, it is imprecise about inner vs outer encryption, which actors > do what, and has a number of pronouns with ambiguous antecedents. The hea= vy > use of passive voice obscures the actors in multiple places. I will call > out some specifics, but please do not treat my comments as exhaustive. > Did a revision pass, let me know what you think. > =C2=A77: =E2=80=9C The repair mechanism, when used with double, typically= operates on > the double encrypted data and encrypts > them using only the HBH key.=E2=80=9D Does =E2=80=9Cdouble encrypted= =E2=80=9D mean =E2=80=9Couter > encrypted=E2=80=9D? Also, while I recognize =E2=80=9Cdata=E2=80=9D as plu= ral, it=E2=80=99s plural in a > non-countable sense; that is, s / them / it. > > =C2=A77.1: > - =E2=80=9C =E2=80=A6 cached payloads MUST be the encrypted packets =E2= =80=A6=E2=80=9D - Inner or outer? > What device enforces this? (Consider active voice.) > - Which element represents =E2=80=9Cthe other side=E2=80=9D? Are we talki= ng about an > endpoint or MD? (Please stick to the defined terminology) > - =E2=80=9C When encrypting a retransmission packet, it MUST be encrypted= the > packet in repair mode.=E2=80=9D - I can=E2=80=99t parse the phrase after = the comma. Also, > what device MUST encrypt it? > > =C2=A77.2: > - =E2=80=9Cthe primary encoding MAY contain=E2=80=A6=E2=80=9D - Is that M= AY a grant of permission > or a statement of fact? > > - " The sender takes encrypted payload from the cached packets=E2=80=9D- = Missing > article for encrypted payload? Or should this say =E2=80=9C=E2=80=A6 take= s encrypted > packets from the cached payload=E2=80=A6=E2=80=9D? > > - =E2=80=9C Any header extensions from the primary encoding are copied to= the RTP > packet that will carry the RED payload and the other RTP header informati= on > such as SSRC, SEQ, CSRC, etc are set to the same as the primary payload. > The RED RTP packet is then encrypted in repair mode and sent.=E2=80=9D: T= his is > confusing; parts are copied from the primary encoding and others are the > same as in the primary encoding? Don=E2=80=99t both of those mean the sam= e thing? > > - =E2=80=9C The receiver decrypts the payload=E2=80=A6=E2=80=9D: Endpoint= or MD? Is this inner or > outer encryption? > > - Last paragraph: Seems like that belongs in the FEC section. Also, does > this document really need to make that sort of recommendation? It seems > like a general statement about RED and FEC that is not specific to double= . > > > =C2=A77.3: > > - "When using Flex FEC [I-D.ietf-payload-flexible-fec-scheme] with double= , > the negotiation of double for the crypto is the out of band signaling tha= t > indicates that the repair packets MUST use the order of operations of SRT= P > followed by FEC when encrypting.=E2=80=9D - The sentence is hard to parse= . Also, is > MUST a normative requirement or a statement of fact? (It seems odd to > signal that you MUST do something). > - =E2=80=9C=E2=80=A6 data, which is already encrypted, it MUST be encrypte= d in repair mode > packet.=E2=80=9D s/ =E2=80=9C, which=E2=80=9D / =E2=80=9Cthat=E2=80=9D. A= lso, what actor MUST encrypt the data in > repair mode? (Consider active voice.) > > - =E2=80=9C The algorithm recommend=E2=80=A6=E2=80=9D s / recommend / rec= ommended > Done. > =C2=A77.4: > - s/ "sent with [RFC4733]=E2=80=9D / =E2=80=9Csent using the mechanism in= [RFC4733]=E2=80=9D > - =E2=80=9C and the relay can not read it so it cannot be used=E2=80=9D -= missing comma > between =E2=80=9Cit=E2=80=9D and =E2=80=9Cso=E2=80=9D. > Done. > =C2=A78, last paragraph: =E2=80=9C For packets in repair mode, the data t= hey are caring > is often already encrypted further increasing the size.=E2=80=9D - I assu= me > =E2=80=9Ccaring=E2=80=9D is not the intended word. Did you mean =E2=80=9C= carrying=E2=80=9D? If so, consider > s / =E2=80=9Cdata they are carrying=E2=80=9D / =E2=80=9Cdata they carry= =E2=80=9D Revised. --00000000000095298205777c5e10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Ben,

Af= ter talking with Cullen, I am now the stuckee for this.=C2=A0 I've file= d a PR at:


Comments inline below.

On Tue, Jun 5, 2018 at 12:40 AM Ben Campbell <ben@nostrum.com> wrote= :
Hi,

This is my AD Evaluation of draft-ietf-perc-double-09. Thanks for this work= ; I think it is important and on the right track, but suffers from some rea= dability issues, especially from =C2=A77 onwards. I=E2=80=99d like to discu= ss my comments prior to IETF last call.

Thanks!

Ben.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94

*** Substantive Comments ***

General: Does it make sense to progress this prior to draft-ietf-perc-priva= te-media-framework rather than wait and progress them together? it seems li= ke one really needs to read the framework to understand at least parts of t= his draft. (Which would, btw, suggest making the framework a normative refe= rence.)

I think at this point, -framewo= rk has caught up a bit (I understand it's awaiting your review), so thi= s seems OBE.=C2=A0 I agree that it will make easier reading for ADs to read= the three docs (this, framework, and EKT) on the same telechat.
<= div>
=C2=A0
=C2=A72, Media Distributor: Should this be defined as switch-based? Otherwi= se it seems circular.

I've copied d= own the definition =C2=A71, which explicitly says that the MD does not need= to interpret or change media content.=C2=A0 Also added a ref to -framework= at this point.

=C2=A0
=C2=A75 and subsections: These sections are confusing in the treatment of e= xtensions. =C2=A75.1 step 3 says to truncate the header to remove any exten= sions. Yet other sections of text repeatedly mention the handling of extens= ions. I think the document needs a paragraph or two to describe the handlin= g of RTP extensions at a high level.

I&= #39;ve added an overview of the transform, including thoughts on extensions= , to the top of =C2=A75.
=C2=A0
=C2=A0
Along those lines, it=E2=80=99s not entirely clear what is meant by putting= =E2=80=9C (12 + 4 * CC bytes)=E2=80=9D in parentheses after the guidance t= o truncate in =C2=A75.1. Is that the amount to be truncated? Amount left af= ter truncation? (Same question for =C2=A75.3)

Clarified that this is the amount left after truncation, i.e., take = the first N bytes, in both places.

=C2=A0
=C2=A75.2: It would be helpful to include a paragraph or two to describe th= e impact if multiple MDs modify the same field(s). I can infer that, but it= would be better to be explicit. (IIRC, there is a passing mention in the s= ecurity considerations, but it would be better to have more here.)

Added a paragraph.

=C2= =A0
=C2=A78: Can you offer any guidance about selecting 128 vs 256?

I don't really think there's much to say h= ere; it's up to the user of the transform.=C2=A0 Use 128 unless you'= ;re paranoid, then use 256?=C2=A0 :)=C2=A0 Note that RFC 7714, which define= s the AES-GCM transforms, does not provide similar guidance.
=
=C2=A0
*** Editorial comments and nits ***

There are a number of abbreviations that need to be expanded on first use. = Please remember that abbreviations should be expanded both in the abstract = and the body.

- SRTP
- SSRC
- SEQ
- ROC
- PRF
- PT
- SEQ
- RTX
- RED
- FEC

I've expanded most of these.= =C2=A0 I have left SSRC, SEQ, ROC, and PT, since in this context, they are = basically opaque labels for RTP header fields.=C2=A0

=C2=A0
=C2=A72:
- Please use the boilerplate from RFC8174. There are a number of lower case= instances of normative keywords.

Done.=
=C2=A0
=C2=A73,

- " Generate key and salt values of the length required for the combin= ed inner (end-to-end) and outer (hop-by-hop) algorithms.=E2=80=9D: The docu= ment is inconsistent in whether it describes a single key with inner and ou= ter halves, or separate inner and outer keys. I realize that this is an art= ifact of syntax, but it is likely to confuse a reader new to the topic.
=

The very next bullet says to glue them tog= ether.=C2=A0 Not sure how else to say this.
=C2=A0
- Paragraph starting with =E2=80=9CObviously, if the Media Distributor=E2= =80=A6=E2=80=9D: =E2=80=9CObviously=E2=80=9D is a null word in context.
=

Deleted.
=C2=A0
=C2=A73.1: This section would be much more approachable if you defined the = terms (such as n, k, and x), rather than forcing readers to look them up in= 3711. Also, the doubled crypto suite IDs are likely to be confusing to the= reader who sees them here without the explanation later in the draft.
<= /blockquote>

Done.
=C2=A0
=C2=A75.2, step 2: =E2=80=9CChange any parts of the RTP packet=E2=80=A6=E2= =80=9D -The MS is limited to changing the 3 fields defined for the OHB, rig= ht, at least as defined in this draft? Not just anything it wants?

Correct.=C2=A0 Done.
=C2=A0
=
=C2=A75.3, last two paragraphs: It=E2=80=99s sort of an odd construction to= talk about =E2=80=9Cany of the following=E2=80=9D with a single entry list= .

Revised to clarify.
=C2= =A0
=C2=A77 and subsections: These could use another proofreading pass. In part= icular, it is imprecise about inner vs outer encryption, which actors do wh= at, and has a number of pronouns with ambiguous antecedents. The heavy use = of passive voice obscures the actors in multiple places. I will call out so= me specifics, but please do not treat my comments as exhaustive.

Did a revision pass, let me know what you think.<= br>
=C2=A0
=C2=A77: =E2=80=9C The repair mechanism, when used with double, typically o= perates on the double encrypted data and encrypts
=C2=A0 =C2=A0them using only the HBH key.=E2=80=9D Does =E2=80=9Cdouble enc= rypted=E2=80=9D mean =E2=80=9Couter encrypted=E2=80=9D? Also, while I recog= nize =E2=80=9Cdata=E2=80=9D as plural, it=E2=80=99s plural in a non-countab= le sense; that is, s / them / it.

=C2=A77.1:
- =E2=80=9C =E2=80=A6 cached payloads MUST be the encrypted packets =E2=80= =A6=E2=80=9D - Inner or outer? What device enforces this? (Consider active = voice.)
- Which element represents =E2=80=9Cthe other side=E2=80=9D? Are we talking= about an endpoint or MD? (Please stick to the defined terminology)
- =E2=80=9C When encrypting a retransmission packet, it MUST be encrypted t= he packet in repair mode.=E2=80=9D - I can=E2=80=99t parse the phrase after= the comma. Also, what device MUST encrypt it?

=C2=A77.2:
- =E2=80=9Cthe primary encoding MAY contain=E2=80=A6=E2=80=9D - Is that MAY= a grant of permission or a statement of fact?

- " The sender takes encrypted payload from the cached packets=E2=80= =9D- Missing article for encrypted payload? Or should this say =E2=80=9C=E2= =80=A6 takes encrypted packets from the cached payload=E2=80=A6=E2=80=9D?
- =E2=80=9C Any header extensions from the primary encoding are copied to t= he RTP packet that will carry the RED payload and the other RTP header info= rmation such as SSRC, SEQ, CSRC, etc are set to the same as the primary pay= load.=C2=A0 The RED RTP packet is then encrypted in repair mode and sent.= =E2=80=9D: This is confusing; parts are copied from the primary encoding an= d others are the same as in the primary encoding? Don=E2=80=99t both of tho= se mean the same thing?

- =E2=80=9C The receiver decrypts the payload=E2=80=A6=E2=80=9D: Endpoint o= r MD? Is this inner or outer encryption?

- Last paragraph: Seems like that belongs in the FEC section. Also, does th= is document really need to make that sort of recommendation? It seems like = a general statement about RED and FEC that is not specific to double.


=C2=A77.3:

- "When using Flex FEC [I-D.ietf-payload-flexible-fec-scheme] with dou= ble, the negotiation of double for the crypto is the out of band signaling = that indicates that the repair packets MUST use the order of operations of = SRTP followed by FEC when encrypting.=E2=80=9D - The sentence is hard to pa= rse. Also, is MUST a normative requirement or a statement of fact? (It seem= s odd to signal that you MUST do something).
- =E2=80=9C=E2=80=A6=C2=A0 data, which is already encrypted, it MUST be enc= rypted in repair mode packet.=E2=80=9D s/ =E2=80=9C, which=E2=80=9D / =E2= =80=9Cthat=E2=80=9D. Also, what actor MUST encrypt the data in repair mode?= (Consider active voice.)

- =E2=80=9C The algorithm recommend=E2=80=A6=E2=80=9D s / recommend / recom= mended

Done.
=C2=A0
=
=C2=A77.4:
- s/ "sent with [RFC4733]=E2=80=9D / =E2=80=9Csent using the mechanism= in [RFC4733]=E2=80=9D
- =E2=80=9C and the relay can not read it so it cannot be used=E2=80=9D - m= issing comma between =E2=80=9Cit=E2=80=9D and =E2=80=9Cso=E2=80=9D.

Done.
=C2=A0
=C2=A78, last paragraph: =E2=80=9C For packets in repair mode, the data the= y are caring is often already encrypted further increasing the size.=E2=80= =9D - I assume =E2=80=9Ccaring=E2=80=9D is not the intended word. Did you m= ean =E2=80=9Ccarrying=E2=80=9D? If so, consider s / =E2=80=9Cdata they are = carrying=E2=80=9D / =E2=80=9Cdata they carry=E2=80=9D

=
Revised.
--00000000000095298205777c5e10-- From nobody Tue Oct 9 09:37:49 2018 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D8B13135D; Tue, 9 Oct 2018 09:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 sPmBgvN1NF4P; Tue, 9 Oct 2018 09:37:43 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 23E6B13134F; Tue, 9 Oct 2018 09:37:43 -0700 (PDT) Received: from [10.0.1.27] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w99GbfLN011088 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 9 Oct 2018 11:37:42 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.27] From: Ben Campbell Message-Id: <684FE3D4-EF22-4F7B-9B7E-B542CA4E4708@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_DD643E4E-088B-4988-BDA6-94BC2343D701"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Tue, 9 Oct 2018 11:37:41 -0500 In-Reply-To: Cc: draft-ietf-perc-double.all@ietf.org, perc@ietf.org To: Richard Barnes References: <5AFC524E-7C2A-4C8F-B66B-7BAA3F048403@nostrum.com> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [Perc] AD Evaluation of draft-ietf-perc-double-09 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 16:37:47 -0000 --Apple-Mail=_DD643E4E-088B-4988-BDA6-94BC2343D701 Content-Type: multipart/alternative; boundary="Apple-Mail=_735FB013-D855-4A32-958F-9B359CADF4CE" --Apple-Mail=_735FB013-D855-4A32-958F-9B359CADF4CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks, I will look at both this as the framework draft after I get = through this week=E2=80=99s telechat reading list. Ben. > On Oct 5, 2018, at 9:48 AM, Richard Barnes wrote: >=20 > Hey Ben, >=20 > After talking with Cullen, I am now the stuckee for this. I've filed = a PR at: >=20 > https://github.com/ietf/perc-wg/pull/160 = >=20 > Comments inline below. >=20 > On Tue, Jun 5, 2018 at 12:40 AM Ben Campbell > wrote: > Hi, >=20 > This is my AD Evaluation of draft-ietf-perc-double-09. Thanks for this = work; I think it is important and on the right track, but suffers from = some readability issues, especially from =C2=A77 onwards. I=E2=80=99d = like to discuss my comments prior to IETF last call. >=20 > Thanks! >=20 > Ben. >=20 > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94 >=20 > *** Substantive Comments *** >=20 > General: Does it make sense to progress this prior to = draft-ietf-perc-private-media-framework rather than wait and progress = them together? it seems like one really needs to read the framework to = understand at least parts of this draft. (Which would, btw, suggest = making the framework a normative reference.) >=20 > I think at this point, -framework has caught up a bit (I understand = it's awaiting your review), so this seems OBE. I agree that it will = make easier reading for ADs to read the three docs (this, framework, and = EKT) on the same telechat. >=20 >=20 > =C2=A72, Media Distributor: Should this be defined as switch-based? = Otherwise it seems circular. >=20 > I've copied down the definition =C2=A71, which explicitly says that = the MD does not need to interpret or change media content. Also added a = ref to -framework at this point. >=20 >=20 > =C2=A75 and subsections: These sections are confusing in the treatment = of extensions. =C2=A75.1 step 3 says to truncate the header to remove = any extensions. Yet other sections of text repeatedly mention the = handling of extensions. I think the document needs a paragraph or two to = describe the handling of RTP extensions at a high level. >=20 > I've added an overview of the transform, including thoughts on = extensions, to the top of =C2=A75. >=20 >=20 > Along those lines, it=E2=80=99s not entirely clear what is meant by = putting =E2=80=9C (12 + 4 * CC bytes)=E2=80=9D in parentheses after the = guidance to truncate in =C2=A75.1. Is that the amount to be truncated? = Amount left after truncation? (Same question for =C2=A75.3) >=20 > Clarified that this is the amount left after truncation, i.e., take = the first N bytes, in both places. >=20 >=20 > =C2=A75.2: It would be helpful to include a paragraph or two to = describe the impact if multiple MDs modify the same field(s). I can = infer that, but it would be better to be explicit. (IIRC, there is a = passing mention in the security considerations, but it would be better = to have more here.) >=20 > Added a paragraph. >=20 >=20 > =C2=A78: Can you offer any guidance about selecting 128 vs 256? >=20 > I don't really think there's much to say here; it's up to the user of = the transform. Use 128 unless you're paranoid, then use 256? :) Note = that RFC 7714, which defines the AES-GCM transforms, does not provide = similar guidance. >=20 >=20 > =C2=A79: >=20 > - The security considerations mainly summarize the mechanism. I=E2=80=99= d like to see a description of the potential attacks or risks and how = the double mechanism mitigates them. > - =E2=80=9C=E2=80=A6 this shouldn=E2=80=99t typically impact the = strength of e2e integrity given the fact that there doesn=E2=80=99t = exist header extensions defined today that needs e2e protection. = However, if future specifications define header extensions that needs = e2e integrity protection, the input to inner transform may be modified = to consider including the header.=E2=80=9D >=20 > - 2nd paragraph: Why is the HBH key for an outgoing packet only = =E2=80=9Ctypically=E2=80=9D different than the key for the incoming = packet? Are there security implications if they are the same? >=20 > - 2nd to last paragraph, last sentence: Please elaborate on those = risks? >=20 > I agree with your assessment that the existing security considerations = were not that useful. I've replaced them with an analysis that's more = focused on what protections are provided with respect to which = attackers. >=20 > The new version also calls out clearly that when a packet is = re-encrypted, the outer keys MUST be different. >=20 >=20 > *** Editorial comments and nits *** >=20 > There are a number of abbreviations that need to be expanded on first = use. Please remember that abbreviations should be expanded both in the = abstract and the body. >=20 > - SRTP > - SSRC > - SEQ > - ROC > - PRF > - PT > - SEQ > - RTX > - RED > - FEC >=20 > I've expanded most of these. I have left SSRC, SEQ, ROC, and PT, = since in this context, they are basically opaque labels for RTP header = fields. >=20 >=20 > =C2=A72: > - Please use the boilerplate from RFC8174. There are a number of lower = case instances of normative keywords. >=20 > Done. >=20 > - Please use consistent sentence (or lack of sentence) structure for = the definitions in the bullet list. >=20 > Done. >=20 > =C2=A73, >=20 > - " Generate key and salt values of the length required for the = combined inner (end-to-end) and outer (hop-by-hop) algorithms.=E2=80=9D: = The document is inconsistent in whether it describes a single key with = inner and outer halves, or separate inner and outer keys. I realize that = this is an artifact of syntax, but it is likely to confuse a reader new = to the topic. >=20 > The very next bullet says to glue them together. Not sure how else to = say this. >=20 > - Paragraph starting with =E2=80=9CObviously, if the Media = Distributor=E2=80=A6=E2=80=9D: =E2=80=9CObviously=E2=80=9D is a null = word in context. >=20 > Deleted. >=20 > =C2=A73.1: This section would be much more approachable if you defined = the terms (such as n, k, and x), rather than forcing readers to look = them up in 3711. Also, the doubled crypto suite IDs are likely to be = confusing to the reader who sees them here without the explanation later = in the draft. >=20 > Done. >=20 > =C2=A75.2, step 2: =E2=80=9CChange any parts of the RTP packet=E2=80=A6=E2= =80=9D -The MS is limited to changing the 3 fields defined for the OHB, = right, at least as defined in this draft? Not just anything it wants? >=20 > Correct. Done. >=20 > =C2=A75.3, last two paragraphs: It=E2=80=99s sort of an odd = construction to talk about =E2=80=9Cany of the following=E2=80=9D with a = single entry list. >=20 > Revised to clarify. >=20 > =C2=A77 and subsections: These could use another proofreading pass. In = particular, it is imprecise about inner vs outer encryption, which = actors do what, and has a number of pronouns with ambiguous antecedents. = The heavy use of passive voice obscures the actors in multiple places. I = will call out some specifics, but please do not treat my comments as = exhaustive. >=20 > Did a revision pass, let me know what you think. >=20 > =C2=A77: =E2=80=9C The repair mechanism, when used with double, = typically operates on the double encrypted data and encrypts > them using only the HBH key.=E2=80=9D Does =E2=80=9Cdouble = encrypted=E2=80=9D mean =E2=80=9Couter encrypted=E2=80=9D? Also, while I = recognize =E2=80=9Cdata=E2=80=9D as plural, it=E2=80=99s plural in a = non-countable sense; that is, s / them / it. >=20 > =C2=A77.1: > - =E2=80=9C =E2=80=A6 cached payloads MUST be the encrypted packets = =E2=80=A6=E2=80=9D - Inner or outer? What device enforces this? = (Consider active voice.) > - Which element represents =E2=80=9Cthe other side=E2=80=9D? Are we = talking about an endpoint or MD? (Please stick to the defined = terminology) > - =E2=80=9C When encrypting a retransmission packet, it MUST be = encrypted the packet in repair mode.=E2=80=9D - I can=E2=80=99t parse = the phrase after the comma. Also, what device MUST encrypt it? >=20 > =C2=A77.2: > - =E2=80=9Cthe primary encoding MAY contain=E2=80=A6=E2=80=9D - Is = that MAY a grant of permission or a statement of fact? >=20 > - " The sender takes encrypted payload from the cached packets=E2=80=9D-= Missing article for encrypted payload? Or should this say =E2=80=9C=E2=80= =A6 takes encrypted packets from the cached payload=E2=80=A6=E2=80=9D? >=20 > - =E2=80=9C Any header extensions from the primary encoding are copied = to the RTP packet that will carry the RED payload and the other RTP = header information such as SSRC, SEQ, CSRC, etc are set to the same as = the primary payload. The RED RTP packet is then encrypted in repair = mode and sent.=E2=80=9D: This is confusing; parts are copied from the = primary encoding and others are the same as in the primary encoding? = Don=E2=80=99t both of those mean the same thing? >=20 > - =E2=80=9C The receiver decrypts the payload=E2=80=A6=E2=80=9D: = Endpoint or MD? Is this inner or outer encryption? >=20 > - Last paragraph: Seems like that belongs in the FEC section. Also, = does this document really need to make that sort of recommendation? It = seems like a general statement about RED and FEC that is not specific to = double. >=20 >=20 > =C2=A77.3: >=20 > - "When using Flex FEC [I-D.ietf-payload-flexible-fec-scheme] with = double, the negotiation of double for the crypto is the out of band = signaling that indicates that the repair packets MUST use the order of = operations of SRTP followed by FEC when encrypting.=E2=80=9D - The = sentence is hard to parse. Also, is MUST a normative requirement or a = statement of fact? (It seems odd to signal that you MUST do something). > - =E2=80=9C=E2=80=A6 data, which is already encrypted, it MUST be = encrypted in repair mode packet.=E2=80=9D s/ =E2=80=9C, which=E2=80=9D / = =E2=80=9Cthat=E2=80=9D. Also, what actor MUST encrypt the data in repair = mode? (Consider active voice.) >=20 > - =E2=80=9C The algorithm recommend=E2=80=A6=E2=80=9D s / recommend / = recommended >=20 > Done. >=20 > =C2=A77.4: > - s/ "sent with [RFC4733]=E2=80=9D / =E2=80=9Csent using the mechanism = in [RFC4733]=E2=80=9D > - =E2=80=9C and the relay can not read it so it cannot be used=E2=80=9D = - missing comma between =E2=80=9Cit=E2=80=9D and =E2=80=9Cso=E2=80=9D. >=20 > Done. >=20 > =C2=A78, last paragraph: =E2=80=9C For packets in repair mode, the = data they are caring is often already encrypted further increasing the = size.=E2=80=9D - I assume =E2=80=9Ccaring=E2=80=9D is not the intended = word. Did you mean =E2=80=9Ccarrying=E2=80=9D? If so, consider s / = =E2=80=9Cdata they are carrying=E2=80=9D / =E2=80=9Cdata they carry=E2=80=9D= >=20 > Revised. --Apple-Mail=_735FB013-D855-4A32-958F-9B359CADF4CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks, I will look at both this as the framework draft after = I get through this week=E2=80=99s telechat reading list.

Ben.

On Oct 5, 2018, at 9:48 AM, Richard Barnes <rlb@ipv.sx> wrote:

Hey = Ben,

After = talking with Cullen, I am now the stuckee for this.  I've filed a = PR at:

https://github.com/ietf/perc-wg/pull/160

Comments inline = below.

On Tue, Jun 5, 2018 at = 12:40 AM Ben Campbell <ben@nostrum.com> wrote:
Hi,

This is my AD Evaluation of draft-ietf-perc-double-09. Thanks for this = work; I think it is important and on the right track, but suffers from = some readability issues, especially from =C2=A77 onwards. I=E2=80=99d = like to discuss my comments prior to IETF last call.

Thanks!

Ben.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94

*** Substantive Comments ***

General: Does it make sense to progress this prior to = draft-ietf-perc-private-media-framework rather than wait and progress = them together? it seems like one really needs to read the framework to = understand at least parts of this draft. (Which would, btw, suggest = making the framework a normative reference.)

I think at this point, -framework has caught up a bit (I = understand it's awaiting your review), so this seems OBE.  I agree = that it will make easier reading for ADs to read the three docs (this, = framework, and EKT) on the same telechat.

 
=C2=A72, Media Distributor: Should this be defined as switch-based? = Otherwise it seems circular.

I've copied down the = definition =C2=A71, which explicitly says that the MD does not need to = interpret or change media content.  Also added a ref to -framework = at this point.

 
=C2=A75 and subsections: These sections are confusing in the treatment = of extensions. =C2=A75.1 step 3 says to truncate the header to remove = any extensions. Yet other sections of text repeatedly mention the = handling of extensions. I think the document needs a paragraph or two to = describe the handling of RTP extensions at a high level.

I've added an overview of the transform, including thoughts = on extensions, to the top of =C2=A75.
 
 
Along those lines, it=E2=80=99s not entirely clear what is meant by = putting =E2=80=9C (12 + 4 * CC bytes)=E2=80=9D in parentheses after the = guidance to truncate in =C2=A75.1. Is that the amount to be truncated? = Amount left after truncation? (Same question for =C2=A75.3)

Clarified that this is the amount left after truncation, = i.e., take the first N bytes, in both places.

 
=C2=A75.2: It would be helpful to include a paragraph or two to describe = the impact if multiple MDs modify the same field(s). I can infer that, = but it would be better to be explicit. (IIRC, there is a passing mention = in the security considerations, but it would be better to have more = here.)

Added a paragraph.

 
=C2=A78: Can you offer any guidance about selecting 128 vs 256?

I don't really think there's much to say here; it's up to the = user of the transform.  Use 128 unless you're paranoid, then use = 256?  :)  Note that RFC 7714, which defines the AES-GCM = transforms, does not provide similar guidance.

 
=C2=A79:

- The security considerations mainly summarize the mechanism. I=E2=80=99d = like to see a description of the potential attacks or risks  and = how the double mechanism mitigates them.
- =E2=80=9C=E2=80=A6 this shouldn=E2=80=99t typically impact the = strength of e2e integrity given the fact that there doesn=E2=80=99t = exist header extensions defined today that needs e2e protection.  = However, if future specifications define header extensions that needs = e2e integrity protection, the input to inner transform may be modified = to consider including the header.=E2=80=9D

- 2nd paragraph: Why is the HBH key for an outgoing packet only = =E2=80=9Ctypically=E2=80=9D different than the key for the incoming = packet? Are there security implications if they are the same?

- 2nd to last paragraph, last sentence: Please elaborate on those = risks?

I agree with your assessment that the = existing security considerations were not that useful.  I've = replaced them with an analysis that's more focused on what protections = are provided with respect to which attackers. 

The = new version also calls out clearly that when a packet is re-encrypted, = the outer keys MUST be different.

 
*** Editorial comments and nits ***

There are a number of abbreviations that need to be expanded on first = use. Please remember that abbreviations should be expanded both in the = abstract and the body.

- SRTP
- SSRC
- SEQ
- ROC
- PRF
- PT
- SEQ
- RTX
- RED
- FEC

I've expanded most of these.  I have left SSRC, SEQ, = ROC, and PT, since in this context, they are basically opaque labels for = RTP header fields. 

 
=C2=A72:
- Please use the boilerplate from RFC8174. There are a number of lower = case instances of normative keywords.

Done.
 
- Please use consistent sentence (or lack of sentence) structure for the = definitions in the bullet list.

Done.
 
=C2=A73,

- " Generate key and salt values of the length required for the combined = inner (end-to-end) and outer (hop-by-hop) algorithms.=E2=80=9D: The = document is inconsistent in whether it describes a single key with inner = and outer halves, or separate inner and outer keys. I realize that this = is an artifact of syntax, but it is likely to confuse a reader new to = the topic.

The very next bullet says to glue them = together.  Not sure how else to say this.
 
- Paragraph starting with =E2=80=9CObviously, if the Media = Distributor=E2=80=A6=E2=80=9D: =E2=80=9CObviously=E2=80=9D is a null = word in context.

Deleted.
 
=C2=A73.1: This section would be much more approachable if you defined = the terms (such as n, k, and x), rather than forcing readers to look = them up in 3711. Also, the doubled crypto suite IDs are likely to be = confusing to the reader who sees them here without the explanation later = in the draft.

Done.
 
=C2=A75.2, step 2: =E2=80=9CChange any parts of the RTP packet=E2=80=A6=E2= =80=9D -The MS is limited to changing the 3 fields defined for the OHB, = right, at least as defined in this draft? Not just anything it wants?

Correct.  Done.
 
=C2=A75.3, last two paragraphs: It=E2=80=99s sort of an odd construction = to talk about =E2=80=9Cany of the following=E2=80=9D with a single entry = list.

Revised to clarify.
 
=C2=A77 and subsections: These could use another proofreading pass. In = particular, it is imprecise about inner vs outer encryption, which = actors do what, and has a number of pronouns with ambiguous antecedents. = The heavy use of passive voice obscures the actors in multiple places. I = will call out some specifics, but please do not treat my comments as = exhaustive.

Did a revision pass, let me know what = you think.
 
=C2=A77: =E2=80=9C The repair mechanism, when used with double, = typically operates on the double encrypted data and encrypts
   them using only the HBH key.=E2=80=9D Does =E2=80=9Cdouble = encrypted=E2=80=9D mean =E2=80=9Couter encrypted=E2=80=9D? Also, while I = recognize =E2=80=9Cdata=E2=80=9D as plural, it=E2=80=99s plural in a = non-countable sense; that is, s / them / it.

=C2=A77.1:
- =E2=80=9C =E2=80=A6 cached payloads MUST be the encrypted packets = =E2=80=A6=E2=80=9D - Inner or outer? What device enforces this? = (Consider active voice.)
- Which element represents =E2=80=9Cthe other side=E2=80=9D? Are we = talking about an endpoint or MD? (Please stick to the defined = terminology)
- =E2=80=9C When encrypting a retransmission packet, it MUST be = encrypted the packet in repair mode.=E2=80=9D - I can=E2=80=99t parse = the phrase after the comma. Also, what device MUST encrypt it?

=C2=A77.2:
- =E2=80=9Cthe primary encoding MAY contain=E2=80=A6=E2=80=9D - Is that = MAY a grant of permission or a statement of fact?

- " The sender takes encrypted payload from the cached packets=E2=80=9D- = Missing article for encrypted payload? Or should this say =E2=80=9C=E2=80=A6= takes encrypted packets from the cached payload=E2=80=A6=E2=80=9D?

- =E2=80=9C Any header extensions from the primary encoding are copied = to the RTP packet that will carry the RED payload and the other RTP = header information such as SSRC, SEQ, CSRC, etc are set to the same as = the primary payload.  The RED RTP packet is then encrypted in = repair mode and sent.=E2=80=9D: This is confusing; parts are copied from = the primary encoding and others are the same as in the primary encoding? = Don=E2=80=99t both of those mean the same thing?

- =E2=80=9C The receiver decrypts the payload=E2=80=A6=E2=80=9D: = Endpoint or MD? Is this inner or outer encryption?

- Last paragraph: Seems like that belongs in the FEC section. Also, does = this document really need to make that sort of recommendation? It seems = like a general statement about RED and FEC that is not specific to = double.


=C2=A77.3:

- "When using Flex FEC [I-D.ietf-payload-flexible-fec-scheme] with = double, the negotiation of double for the crypto is the out of band = signaling that indicates that the repair packets MUST use the order of = operations of SRTP followed by FEC when encrypting.=E2=80=9D - The = sentence is hard to parse. Also, is MUST a normative requirement or a = statement of fact? (It seems odd to signal that you MUST do = something).
- =E2=80=9C=E2=80=A6  data, which is already encrypted, it MUST be = encrypted in repair mode packet.=E2=80=9D s/ =E2=80=9C, which=E2=80=9D / = =E2=80=9Cthat=E2=80=9D. Also, what actor MUST encrypt the data in repair = mode? (Consider active voice.)

- =E2=80=9C The algorithm recommend=E2=80=A6=E2=80=9D s / recommend / = recommended

Done.
 
=C2=A77.4:
- s/ "sent with [RFC4733]=E2=80=9D / =E2=80=9Csent using the mechanism = in [RFC4733]=E2=80=9D
- =E2=80=9C and the relay can not read it so it cannot be used=E2=80=9D = - missing comma between =E2=80=9Cit=E2=80=9D and =E2=80=9Cso=E2=80=9D.

Done.
 
=C2=A78, last paragraph: =E2=80=9C For packets in repair mode, the data = they are caring is often already encrypted further increasing the = size.=E2=80=9D - I assume =E2=80=9Ccaring=E2=80=9D is not the intended = word. Did you mean =E2=80=9Ccarrying=E2=80=9D? If so, consider s / = =E2=80=9Cdata they are carrying=E2=80=9D / =E2=80=9Cdata they = carry=E2=80=9D

Revised.

= --Apple-Mail=_735FB013-D855-4A32-958F-9B359CADF4CE-- --Apple-Mail=_DD643E4E-088B-4988-BDA6-94BC2343D701 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlu82VUACgkQgFZKbJXz 1A0P6BAAsncHy5Ss6vwWTIOwLsXeg2Fgg3dbfVSihZReVKmmC0hFBKqVupOqq2qw OMc/xr5e2gqn/SdUKysHi/voK2FavTPegWNCCZHzWKdN1N0jPjHiG88ydJjngEbq rv2kCRg8e93C0sroG88ii6axUk5AziQS/bT8zkszhS/61zN6cBs0WYpaiKWfl7Pi 4kCtw/Uf7Vt/kuTpJoBs/t20kf5qDVYjz/U4OmicGZmYbEZdaFXzsZug8MJHhfFr ZSREeTWnUhyPHAa2Ni9WsAYGp8hZqn5GpJrAN1kYS9hm0cL0ZunyhADPd6x2oQRM 3Lxs0SLjqBW95TWl7m619paS+u69Ns1u8stEUYTBajL4pEgaMrt9i8LaAwxFwBli 4l88Iaj6YkA6f5pkdg3ed47zSEFn00QU3wcbWE/AjUsJWAs6C7/BKuNvO27FcakP w68JNQhHkkJAW6YvMtLHY0r08gSzOjFBUp05aHIxJ7PKCXvyCpUCEEuDju7n0kcj AUE2sRGWJXCSoeJPww/y79k3mrX7duDeIQKonRub90+d5Y1Fd8dYi5vYACO/uK1A TlUAxw2nM/x9Qi+PnVlKrod5xgM1vy5N8TK1nREtWs3CesEYiyH0RTO4gyCoNESc JcpUZWWkkrZ3GzwTwgp1h9H6iox+zDWx2hupWNTySVRyO+e9tvk= =7Hck -----END PGP SIGNATURE----- --Apple-Mail=_DD643E4E-088B-4988-BDA6-94BC2343D701-- From nobody Tue Oct 9 12:07:06 2018 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537C512F1A5 for ; Tue, 9 Oct 2018 12:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham 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 4FYGER1BkRoL for ; Tue, 9 Oct 2018 12:07:03 -0700 (PDT) Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (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 28D2D12F1A2 for ; Tue, 9 Oct 2018 12:07:03 -0700 (PDT) Received: by mail-oi1-x22d.google.com with SMTP id p125-v6so2137279oic.3 for ; Tue, 09 Oct 2018 12:07:03 -0700 (PDT) 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=AKYb5v3hSZqZVASRlMQRLQfcFviRQGVP7aHp3BvmmsU=; b=HZmdlzrze5R8jBFG39EHJRghumk6hZUgmsFG8szab0fC7g0yX9xcwS6kTh0nMONqm9 uKL6Hl2sHyF7/tPGp6/ILIvxV1fbT9bc0zd4KOUZH9v+O4ZAeJFe6HUhS7Eva5hi8bjo 9l6lUKoQ9MhqJ7sg8gjBIVf1UzX1NbJFeBV5Axhjo2sQn5EwJtCq709YKDL053pmpKt2 sGdmBnMH97x4EbSURPyBUGaNllzDXj+R2oxL9vUh9izSlFUK0gI84QDFTq7ByAsqLngW 6H2QADUa7HYUNAjLy37OVi5LcDUjAJXHPAZ7PJm+N8grfmKS7KyZ3Vz57h4/gR1zZFPm P78Q== 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=AKYb5v3hSZqZVASRlMQRLQfcFviRQGVP7aHp3BvmmsU=; b=dGKDUu+OgMFMq2yG+GdVUu2m0mJYXxLQyc5gNaJeEwgEbYhVjJKamLPx3s/5Ap6+XY HV0rGNwEqorMghcafmN2evfmqkOihVCRUMfzi3TomT92b76RmCdAlbl8Rzl91y2QWfG3 2ODndU/hiQgmkLfNkCtx0kddyKqrKXeQ1y1JhdaCA228OSGzFJ2wae8jpxgie4aVv+Hq SnHSl6bo5ZVXuZAE790RylCIVOWxIYjoCvjH6A3jmBcn4UlowjahWpwYiJuVmtHvC7Wp 8Yz4d89UtDMlIgS9TrJf4koj7C3/fO6bFcnJ7bsvy7YTtgTqDzjbYGOfBrzHWfF80wXR P6Aw== X-Gm-Message-State: ABuFfojkJ0m/PN0bki90riD0MJ2OpKIGGriFJ9pkqRrGXWBPkFAO1jUL XfwCsBlp7RRAw+ZcHgZPwn9uGkjEwlfxh0wgcCBWqyjMPor04w== X-Google-Smtp-Source: ACcGV63jvEI9ZQhRgxsKxObTk4J5q8LjDAhEAE287GiNcV8u4PvQv8VuHSm7gWfG14lQ2JEgAyYDZWyrNjvydCCzPcs= X-Received: by 2002:aca:b5c6:: with SMTP id e189-v6mr7283788oif.51.1539112022179; Tue, 09 Oct 2018 12:07:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Tue, 9 Oct 2018 15:06:46 -0400 Message-ID: To: Ben Campbell Cc: draft-ietf-perc-srtp-ekt-diet.all@ietf.org, perc@ietf.org Content-Type: multipart/alternative; boundary="0000000000005a14d20577d071fa" Archived-At: Subject: Re: [Perc] AD Evaluation of draft-ietf-perc-srtp-ekt-diet-08 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 19:07:06 -0000 --0000000000005a14d20577d071fa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the review, Ben. I've posted a PR with responses; notes inline below... https://github.com/ietf/perc-wg/pull/161 Apropos of your follow-up comment, I have sent a ping to the last address I have for Dan Wing, and will update the PR with whatever I hear back from him. On Thu, Aug 9, 2018 at 6:28 PM Ben Campbell wrote: > Hi, > > This is my AD Evaluation of draft-ietf-perc-srtp-ekt-diet-08. > > The document is mostly in good shape. It=E2=80=99s easy to read and under= stand. > However, I have a few substantive comments/questions and some editorial > comments. I would like to at least discuss the substantive comments befor= e > going to IETF LC. > > Thanks! > > Ben. > > ---------- > > *** Substantive Comments: *** > > > =C2=A73: Is there a reason not to use the RFC 8174 boilerplate? There are= at > least a few instances of lowercase keywords in places that don=E2=80=99t = seem > intended as normative. > Not intentional. I fixed one lower-case "must" and changed over to 8174. > =C2=A74.2.1, first paragraph: Is there never a situation where you send n= either > version? Also, did I miss a description of the purpose and semantics for > ShortEKTField, other than =E2=80=9Csend it when you don=E2=80=99t send th= e full version=E2=80=9D? > No, there is never such a situation. EKT always adds at least one byte of overhead to every packet. Because RTP lacks an internal length indicator, the receiver of an EKT-enabled flow needs to know how much EKT data to strip off the end of any given packet. Even if the answer is "zero", you still need a way to signal that, which is what the ShortEKTField does. > =C2=A74.2.2, step 3: "If the EKT decryption operation returns an authenti= cation > failure, then the packet processing stops.=E2=80=9D > > .... and then what? > Clarified that EKT processing is definitely over, and the packet SHOULD be discarded. > - Step 6: "This applies in transforms such as [ I-D.ietf-perc-double] for > replacing just half the key, but SHOULD return a processing error > otherwise.=E2=80=9D > > I don=E2=80=99t understand that sentence. Is the point to say that using = a =E2=80=9Ctoo > short=E2=80=9D key to replace part of the old key is only valid for perc-= double or > similar transforms, and receiving one in other contexts is an error? > Revised to clarify and tighten. > - Next Sentence: "Outbound packets SHOULD continue to use the old SRTP > Master Key for 250 ms after=E2=80=9D Does that imply a normative requirem= ent for > recipients to keep old keys around for at least that long? There=E2=80=99= s > currently an implementation suggestion about that, but it doesn=E2=80=99t= use MUST > or SHOULD. > (Editorial: The sentence seems to belong in the =E2=80=9Coutbound=E2=80= =9D section, not > the =E2=80=9Cinbound=E2=80=9D section.) > Yeah, moved this to the outbound section. Added MAY-level inbound considerations to the implementation notes -- either the receiver can accept packet loss or do trial decryption. > =C2=A74.3: > > - =E2=80=9C This ciphertext value MAY be cached by an SRTP > receiver to minimize computational effort by noting when the SRTP > master key is unchanged and avoiding repeating the steps defined in ..= =E2=80=9D > > Are we really talking about the recipient? How would the recipient know > that the key has not changed without processing the ciphertext value? > (Also, the sentence is unfinished--maybe the answer would be clear if the > rest of the sentence came out of hiding :-) ) > The unclear ending is a missing cross-reference to Section 4.2. I think the receiver optimization here is that if you cache the tag, you can memcmp instead of decrypting. Same on the sender side, memcpy vs. encrypt. Updated to reflect that. > - =E2=80=9C The receiver may want to have a sliding window to retain old = SRTP > Master Keys (and related context) for some brief period of time, so > that out of order packets can be processed as well as packets sent > during the time keys are changing.=E2=80=9D > > See comment to =C2=A74.2.2, step 6. =E2=80=9Cmay want=E2=80=9D seems weak= given that the sender > SHOULD keep using the old key for a period of time. > Revised this as noted above, though note that MAY WISH TO is defined in RFC 6919. > =C2=A74.7: =E2=80=9CA new sender SHOULD send a packet containing the Full= EKTField as > soon as possible...=E2=80=9D > > Why not MUST? Would it ever make sense not to do this? It seems like the > mechanism doesn=E2=80=99t work very well otherwise. > How would you comply with a "MUST ... as soon as possible"? I don't think we want to dictate a schedule here, but I've added a note that packet loss can result if you don't. > =C2=A76, first paragraph: =E2=80=9Cor other=E2=80=9D - what other? > Clarified. > - paragraph 8: =E2=80=9C An endpoint MUST NOT encrypt more than T differe= nt > FullEKTField values using the same EKTKey.=E2=80=9D > > Is there a reciprocal requirement for decryption? > No. The risk attaches once the ciphertext is transmitted. > - last paragraph: =E2=80=9C...SHOULD be limited using the ekt_ttl=E2=80= =9D > > Why not MUST? > Upgraded. > =C2=A77.3: Should this cite RFC 5246 instead of RFC 4366? > You mean RFC 8446? Actually this line and the similar one below it are both unnecessary, so I've deleted them. > *** Editorial Comments: *** > > =C2=A72: =E2=80=9C...each endpoint picks there own SRTP master key...: > s/their/its > Done. > =C2=A74.1, first paragraph: Please reference figures by number. I can ima= gine > some future RFC rendering failing to maintain the relative positions. > (This occurs a few times throughout the document.) > > =C2=A74.2.2, step 3: > Should "The EKTCiphertext authentication is checked and is decrypted=E2= =80=9D be > something like =E2=80=9C > The EKTCiphertext field authentication is checked and its contents > decrypted=E2=80=9D I assume you don=E2=80=99t mean to say its authenticat= ion is decrypted. > "The EKTCiphertext is authenticated and decrypted..." -- since these operations are combined in many SRTP transforms. > Also, there=E2=80=99s a number of occurrences of =E2=80=9CThe [fieldname]= ...=E2=80=9D that should > probably say =E2=80=9CThe [fieldname] field...=E2=80=9D > This doesn't seem like a bad ambiguity to me. > - Step 6: s/crypto/cryptographic > Disagree. > - Step 7: is the replay protection part relevant to the step? > Deleted. Added a note about replay to the security considerations. > =C2=A74.3, third paragraph: This is the first mention of ekt_ttl. It woul= d help > to have a brief explanation or at least a forward reference. > Added a forward reference > =C2=A74.6: s/ =E2=80=9Cother specification=E2=80=9D / =E2=80=9Canother sp= ecification=E2=80=9D ; or =E2=80=9Cother > specifications=E2=80=9D > Revised. > =C2=A74.7, third paragraph: Both occurrences of =E2=80=9Cwhich=E2=80=9D n= eed preceding commas. > Done. > =C2=A75.2, paragraph after figure 4: =E2=80=9C ... the extensions defined= in this > session allows the DTLS server...=E2=80=9D > Defined in this =E2=80=9Csession=E2=80=9D or this =E2=80=9Csection=E2=80= =9D? > Actually, "in this document" > =C2=A7, paragraph 7: =E2=80=9C... causing the receiving system will decry= pt...=E2=80=9D > s/will/to > Done > > > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --0000000000005a14d20577d071fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the revi= ew, Ben.=C2=A0 I've posted a PR with responses; notes inline below...


Apropos of your follow-up comment, I have sent a ping to the last address = I have for Dan Wing, and will update the PR with whatever I hear back from = him.


On= Thu, Aug 9, 2018 at 6:28 PM Ben Campbell <ben@nostrum.com> wrote:
Hi,

This is my AD Evaluation of draft-ietf-perc-srtp-ekt-diet-08.

The document is mostly in good shape. It=E2=80=99s easy to read and underst= and. However, I have a few substantive comments/questions and some editoria= l comments. I would like to at least discuss the substantive comments befor= e going to IETF LC.

Thanks!

Ben.

----------

*** Substantive Comments: ***


=C2=A73: Is there a reason not to use the RFC 8174 boilerplate? There are a= t least a few instances of lowercase keywords in places that don=E2=80=99t = seem intended as normative.

Not intenti= onal.=C2=A0 I fixed one lower-case "must" and changed over to 817= 4.

=C2=A0
=C2=A74.2.1, first paragraph: Is there never a situation where you send nei= ther version?=C2=A0 Also, did I miss a description of the purpose and seman= tics for ShortEKTField, other than =E2=80=9Csend it when you don=E2=80=99t = send the full version=E2=80=9D?

No, the= re is never such a situation.=C2=A0 EKT always adds at least one byte of ov= erhead to every packet.=C2=A0 Because RTP lacks an internal length indicato= r, the receiver of an EKT-enabled flow needs to know how much EKT data to s= trip off the end of any given packet.=C2=A0 Even if the answer is "zer= o", you still need a way to signal that, which is what the ShortEKTFie= ld does.

=C2=A0
=C2=A74.2.2, step 3: "If the EKT decryption operation returns an authe= ntication failure, then the packet processing stops.=E2=80=9D

.... and then what?

Clarified that EKT = processing is definitely over, and the packet SHOULD be discarded.

=C2=A0
- Step 6: "This applies in transforms such as [ I-D.ietf-perc-double] = for replacing just half the key, but SHOULD return a processing error other= wise.=E2=80=9D

I don=E2=80=99t understand that sentence. Is the point to say that using a = =E2=80=9Ctoo short=E2=80=9D key to replace part of the old key is only vali= d for perc-double or similar transforms, and receiving one in other context= s is an error?

Revised to clarify and t= ighten.
=C2=A0
- Next Sentence: "Outbound packets SHOULD continue to use the old SRTP= Master Key for 250 ms after=E2=80=9D Does that imply a normative requireme= nt for recipients to keep old keys around for at least that long? There=E2= =80=99s currently an implementation suggestion about that, but it doesn=E2= =80=99t use MUST or SHOULD.
(Editorial: The sentence seems to belong in the =E2=80=9Coutbound=E2=80=9D = section, not the =E2=80=9Cinbound=E2=80=9D section.)
<= br>
Yeah, moved this to the outbound section.=C2=A0 Added MAY-lev= el inbound considerations to the implementation notes -- either the receive= r can accept packet loss or do trial decryption.

=C2=A0
=C2=A74.3:

- =E2=80=9C This ciphertext value MAY be cached by an SRTP
=C2=A0 =C2=A0receiver to minimize computational effort by noting when the S= RTP
=C2=A0 =C2=A0master key is unchanged and avoiding repeating the steps defin= ed in ..=E2=80=9D

Are we really talking about the recipient? How would the recipient know tha= t the key has not changed without processing the ciphertext value? (Also, t= he sentence is unfinished--maybe the answer would be clear if the rest of t= he sentence came out of hiding :-) )

Th= e unclear ending is a missing cross-reference to Section 4.2.=C2=A0 I think= the receiver optimization here is that if you cache the tag, you can memcm= p instead of decrypting.=C2=A0 Same on the sender side, memcpy vs. encrypt.= =C2=A0 Updated to reflect that.
=C2=A0
- =E2=80=9C The receiver may want to have a sliding window to retain old SR= TP
=C2=A0 =C2=A0Master Keys (and related context) for some brief period of tim= e, so
=C2=A0 =C2=A0that out of order packets can be processed as well as packets = sent
=C2=A0 =C2=A0during the time keys are changing.=E2=80=9D

See comment to =C2=A74.2.2, step 6. =E2=80=9Cmay want=E2=80=9D seems weak g= iven that the sender SHOULD keep using the old key for a period of time.

Revised this as noted above, though note = that MAY WISH TO is defined in RFC 6919.

=C2= =A0
=C2=A74.7: =E2=80=9CA new sender SHOULD send a packet containing the FullEK= TField as soon as possible...=E2=80=9D

Why not MUST? Would it ever make sense not to do this? It seems like the me= chanism doesn=E2=80=99t work very well otherwise.

=
How would you comply with a "MUST ... as soon as possible&q= uot;?=C2=A0 I don't think we want to dictate a schedule here, but I'= ;ve added a note that packet loss can result if you don't.

=C2=A0
=C2=A76, first paragraph: =E2=80=9Cor other=E2=80=9D - what other?

Clarified.

=C2=A0
- paragraph 8: =E2=80=9C An endpoint MUST NOT encrypt more than T different= FullEKTField values using the same EKTKey.=E2=80=9D

Is there a reciprocal requirement for decryption?

=
No.=C2=A0 The risk attaches once the ciphertext is transmitted. =

=C2=A0
- last paragraph: =E2=80=9C...SHOULD be limited using the ekt_ttl=E2=80=9D<= br>
Why not MUST?

Upgraded.

<= /div>
=C2=A0
=C2=A77.3: Should this cite RFC 5246 instead of RFC 4366?
<= div>
You mean RFC 8446?=C2=A0 Actually this line and the simi= lar one below it are both unnecessary, so I've deleted them.
<= div>
=C2=A0
*** Editorial Comments: ***

=C2=A72: =E2=80=9C...each endpoint picks there own SRTP master key...:
s/their/its

Done.

=C2=A0
=C2=A74.1, first paragraph: Please reference figures by number. I can imagi= ne some future RFC rendering failing to=C2=A0 maintain the relative positio= ns.=C2=A0 (This occurs a few times throughout the document.)

=C2=A74.2.2, step 3:
Should "The EKTCiphertext authentication is checked and is decrypted= =E2=80=9D be something like =E2=80=9C
The EKTCiphertext field authentication is checked and its contents decrypte= d=E2=80=9D I assume you don=E2=80=99t mean to say its authentication is dec= rypted.

"The EKTCiphertext is auth= enticated and decrypted..." -- since these operations are combined in = many SRTP transforms.

=C2=A0
Also, there=E2=80=99s a number of occurrences of =E2=80=9CThe [fieldname]..= .=E2=80=9D that should probably say =E2=80=9CThe [fieldname] field...=E2=80= =9D

This doesn't seem like a bad am= biguity to me.

=C2=A0
- Step 6: s/crypto/cryptographic

Disagr= ee.

=C2=A0
- Step 7: is the replay protection part relevant to the step?

Deleted.=C2=A0 Added a note about replay to the secu= rity considerations.

=C2=A0
=C2=A74.3, third paragraph: This is the first mention of ekt_ttl. It would = help to have a brief explanation or at least a forward reference.

Added a forward reference

=C2=A0
=C2=A74.6: s/ =E2=80=9Cother specification=E2=80=9D / =E2=80=9Canother spec= ification=E2=80=9D ; or =E2=80=9Cother specifications=E2=80=9D

Revised.

=C2=A0
=C2=A74.7, third paragraph: Both occurrences of =E2=80=9Cwhich=E2=80=9D nee= d preceding commas.

Done.
=C2=A0
=C2=A75.2, paragraph after figure 4: =E2=80=9C ... the extensions defined i= n this session allows the DTLS server...=E2=80=9D
Defined in this =E2=80=9Csession=E2=80=9D or this =E2=80=9Csection=E2=80=9D= ?

Actually, "in this document"= ;

=C2=A0
=C2=A7, paragraph 7: =E2=80=9C... causing the receiving system will decrypt= ...=E2=80=9D
s/will/to

Done
=C2=A0



_______________________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc
--0000000000005a14d20577d071fa-- From nobody Tue Oct 9 12:09:32 2018 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0654E129BBF; Tue, 9 Oct 2018 12:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 OEaX-rnH1BIv; Tue, 9 Oct 2018 12:09:27 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 C2CCD12D7F8; Tue, 9 Oct 2018 12:09:27 -0700 (PDT) Received: from [10.0.1.27] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w99J9Qn4035849 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 9 Oct 2018 14:09:27 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.27] From: Ben Campbell Message-Id: <3A5779D7-B315-4954-B1CE-348B682D8DA1@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_6B0677C3-238F-4375-9FE7-937AB333F1C2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Tue, 9 Oct 2018 14:09:25 -0500 In-Reply-To: Cc: draft-ietf-perc-srtp-ekt-diet.all@ietf.org, perc@ietf.org To: Richard Barnes References: X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [Perc] AD Evaluation of draft-ietf-perc-srtp-ekt-diet-08 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 19:09:31 -0000 --Apple-Mail=_6B0677C3-238F-4375-9FE7-937AB333F1C2 Content-Type: multipart/alternative; boundary="Apple-Mail=_74023F88-25B2-408D-A065-8DBF1A000BFF" --Apple-Mail=_74023F88-25B2-408D-A065-8DBF1A000BFF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks!. I will add this to my list of things to look at after this = week=E2=80=99s telechat. Ben. > On Oct 9, 2018, at 2:06 PM, Richard Barnes wrote: >=20 > Thanks for the review, Ben. I've posted a PR with responses; notes = inline below... >=20 > https://github.com/ietf/perc-wg/pull/161 = >=20 > Apropos of your follow-up comment, I have sent a ping to the last = address I have for Dan Wing, and will update the PR with whatever I hear = back from him. >=20 >=20 > On Thu, Aug 9, 2018 at 6:28 PM Ben Campbell > wrote: > Hi, >=20 > This is my AD Evaluation of draft-ietf-perc-srtp-ekt-diet-08. >=20 > The document is mostly in good shape. It=E2=80=99s easy to read and = understand. However, I have a few substantive comments/questions and = some editorial comments. I would like to at least discuss the = substantive comments before going to IETF LC. >=20 > Thanks! >=20 > Ben. >=20 > ---------- >=20 > *** Substantive Comments: *** >=20 >=20 > =C2=A73: Is there a reason not to use the RFC 8174 boilerplate? There = are at least a few instances of lowercase keywords in places that = don=E2=80=99t seem intended as normative. >=20 > Not intentional. I fixed one lower-case "must" and changed over to = 8174. >=20 >=20 > =C2=A74.2.1, first paragraph: Is there never a situation where you = send neither version? Also, did I miss a description of the purpose and = semantics for ShortEKTField, other than =E2=80=9Csend it when you = don=E2=80=99t send the full version=E2=80=9D? >=20 > No, there is never such a situation. EKT always adds at least one = byte of overhead to every packet. Because RTP lacks an internal length = indicator, the receiver of an EKT-enabled flow needs to know how much = EKT data to strip off the end of any given packet. Even if the answer = is "zero", you still need a way to signal that, which is what the = ShortEKTField does. >=20 >=20 > =C2=A74.2.2, step 3: "If the EKT decryption operation returns an = authentication failure, then the packet processing stops.=E2=80=9D >=20 > .... and then what? >=20 > Clarified that EKT processing is definitely over, and the packet = SHOULD be discarded. >=20 >=20 > - Step 6: "This applies in transforms such as [ I-D.ietf-perc-double] = for replacing just half the key, but SHOULD return a processing error = otherwise.=E2=80=9D >=20 > I don=E2=80=99t understand that sentence. Is the point to say that = using a =E2=80=9Ctoo short=E2=80=9D key to replace part of the old key = is only valid for perc-double or similar transforms, and receiving one = in other contexts is an error? >=20 > Revised to clarify and tighten. >=20 > - Next Sentence: "Outbound packets SHOULD continue to use the old SRTP = Master Key for 250 ms after=E2=80=9D Does that imply a normative = requirement for recipients to keep old keys around for at least that = long? There=E2=80=99s currently an implementation suggestion about that, = but it doesn=E2=80=99t use MUST or SHOULD. > (Editorial: The sentence seems to belong in the =E2=80=9Coutbound=E2=80=9D= section, not the =E2=80=9Cinbound=E2=80=9D section.) >=20 > Yeah, moved this to the outbound section. Added MAY-level inbound = considerations to the implementation notes -- either the receiver can = accept packet loss or do trial decryption. >=20 >=20 > =C2=A74.3: >=20 > - =E2=80=9C This ciphertext value MAY be cached by an SRTP > receiver to minimize computational effort by noting when the SRTP > master key is unchanged and avoiding repeating the steps defined in = ..=E2=80=9D >=20 > Are we really talking about the recipient? How would the recipient = know that the key has not changed without processing the ciphertext = value? (Also, the sentence is unfinished--maybe the answer would be = clear if the rest of the sentence came out of hiding :-) ) >=20 > The unclear ending is a missing cross-reference to Section 4.2. I = think the receiver optimization here is that if you cache the tag, you = can memcmp instead of decrypting. Same on the sender side, memcpy vs. = encrypt. Updated to reflect that. >=20 > - =E2=80=9C The receiver may want to have a sliding window to retain = old SRTP > Master Keys (and related context) for some brief period of time, so > that out of order packets can be processed as well as packets sent > during the time keys are changing.=E2=80=9D >=20 > See comment to =C2=A74.2.2, step 6. =E2=80=9Cmay want=E2=80=9D seems = weak given that the sender SHOULD keep using the old key for a period of = time. >=20 > Revised this as noted above, though note that MAY WISH TO is defined = in RFC 6919. >=20 >=20 > =C2=A74.7: =E2=80=9CA new sender SHOULD send a packet containing the = FullEKTField as soon as possible...=E2=80=9D >=20 > Why not MUST? Would it ever make sense not to do this? It seems like = the mechanism doesn=E2=80=99t work very well otherwise. >=20 > How would you comply with a "MUST ... as soon as possible"? I don't = think we want to dictate a schedule here, but I've added a note that = packet loss can result if you don't. >=20 >=20 > =C2=A76, first paragraph: =E2=80=9Cor other=E2=80=9D - what other? >=20 > Clarified. >=20 >=20 > - paragraph 8: =E2=80=9C An endpoint MUST NOT encrypt more than T = different FullEKTField values using the same EKTKey.=E2=80=9D >=20 > Is there a reciprocal requirement for decryption? >=20 > No. The risk attaches once the ciphertext is transmitted. >=20 >=20 > - last paragraph: =E2=80=9C...SHOULD be limited using the ekt_ttl=E2=80=9D= >=20 > Why not MUST? >=20 > Upgraded. >=20 >=20 > =C2=A77.3: Should this cite RFC 5246 instead of RFC 4366? >=20 > You mean RFC 8446? Actually this line and the similar one below it = are both unnecessary, so I've deleted them. >=20 >=20 > *** Editorial Comments: *** >=20 > =C2=A72: =E2=80=9C...each endpoint picks there own SRTP master key...: > s/their/its >=20 > Done. >=20 >=20 > =C2=A74.1, first paragraph: Please reference figures by number. I can = imagine some future RFC rendering failing to maintain the relative = positions. (This occurs a few times throughout the document.) >=20 > =C2=A74.2.2, step 3: > Should "The EKTCiphertext authentication is checked and is = decrypted=E2=80=9D be something like =E2=80=9C > The EKTCiphertext field authentication is checked and its contents = decrypted=E2=80=9D I assume you don=E2=80=99t mean to say its = authentication is decrypted. >=20 > "The EKTCiphertext is authenticated and decrypted..." -- since these = operations are combined in many SRTP transforms. >=20 >=20 > Also, there=E2=80=99s a number of occurrences of =E2=80=9CThe = [fieldname]...=E2=80=9D that should probably say =E2=80=9CThe = [fieldname] field...=E2=80=9D >=20 > This doesn't seem like a bad ambiguity to me. >=20 >=20 > - Step 6: s/crypto/cryptographic >=20 > Disagree. >=20 >=20 > - Step 7: is the replay protection part relevant to the step? >=20 > Deleted. Added a note about replay to the security considerations. >=20 >=20 > =C2=A74.3, third paragraph: This is the first mention of ekt_ttl. It = would help to have a brief explanation or at least a forward reference. >=20 > Added a forward reference >=20 >=20 > =C2=A74.6: s/ =E2=80=9Cother specification=E2=80=9D / =E2=80=9Canother = specification=E2=80=9D ; or =E2=80=9Cother specifications=E2=80=9D >=20 > Revised. >=20 >=20 > =C2=A74.7, third paragraph: Both occurrences of =E2=80=9Cwhich=E2=80=9D = need preceding commas. >=20 > Done. >=20 >=20 > =C2=A75.2, paragraph after figure 4: =E2=80=9C ... the extensions = defined in this session allows the DTLS server...=E2=80=9D > Defined in this =E2=80=9Csession=E2=80=9D or this =E2=80=9Csection=E2=80= =9D? >=20 > Actually, "in this document" >=20 >=20 > =C2=A7, paragraph 7: =E2=80=9C... causing the receiving system will = decrypt...=E2=80=9D > s/will/to >=20 > Done >=20 >=20 >=20 >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc = --Apple-Mail=_74023F88-25B2-408D-A065-8DBF1A000BFF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks!.  I will add this to my list of things to look = at after this week=E2=80=99s telechat.

Ben.

On Oct = 9, 2018, at 2:06 PM, Richard Barnes <rlb@ipv.sx> wrote:

Thanks for the review, Ben.  I've posted a PR with = responses; notes inline below...

https://github.com/ietf/perc-wg/pull/161

Apropos of your follow-up comment, I have sent a ping to the = last address I have for Dan Wing, and will update the PR with whatever I = hear back from him.


On = Thu, Aug 9, 2018 at 6:28 PM Ben Campbell <ben@nostrum.com> = wrote:
Hi,

This is my AD Evaluation of draft-ietf-perc-srtp-ekt-diet-08.

The document is mostly in good shape. It=E2=80=99s easy to read and = understand. However, I have a few substantive comments/questions and = some editorial comments. I would like to at least discuss the = substantive comments before going to IETF LC.

Thanks!

Ben.

----------

*** Substantive Comments: ***


=C2=A73: Is there a reason not to use the RFC 8174 boilerplate? There = are at least a few instances of lowercase keywords in places that = don=E2=80=99t seem intended as normative.

Not intentional.  I = fixed one lower-case "must" and changed over to 8174.

 
=C2=A74.2.1, first paragraph: Is there never a situation where you send = neither version?  Also, did I miss a description of the purpose and = semantics for ShortEKTField, other than =E2=80=9Csend it when you = don=E2=80=99t send the full version=E2=80=9D?

No, there is never such a situation.  EKT always adds at = least one byte of overhead to every packet.  Because RTP lacks an = internal length indicator, the receiver of an EKT-enabled flow needs to = know how much EKT data to strip off the end of any given packet.  = Even if the answer is "zero", you still need a way to signal that, which = is what the ShortEKTField does.

 
=C2=A74.2.2, step 3: "If the EKT decryption operation returns an = authentication failure, then the packet processing stops.=E2=80=9D

.... and then what?

Clarified that EKT processing is = definitely over, and the packet SHOULD be discarded.

 
- Step 6: "This applies in transforms such as [ I-D.ietf-perc-double] = for replacing just half the key, but SHOULD return a processing error = otherwise.=E2=80=9D

I don=E2=80=99t understand that sentence. Is the point to say that using = a =E2=80=9Ctoo short=E2=80=9D key to replace part of the old key is only = valid for perc-double or similar transforms, and receiving one in other = contexts is an error?

Revised to clarify and tighten.
 
- Next Sentence: "Outbound packets SHOULD continue to use the old SRTP = Master Key for 250 ms after=E2=80=9D Does that imply a normative = requirement for recipients to keep old keys around for at least that = long? There=E2=80=99s currently an implementation suggestion about that, = but it doesn=E2=80=99t use MUST or SHOULD.
(Editorial: The sentence seems to belong in the =E2=80=9Coutbound=E2=80=9D= section, not the =E2=80=9Cinbound=E2=80=9D section.)

Yeah, moved this to the outbound section.  Added = MAY-level inbound considerations to the implementation notes -- either = the receiver can accept packet loss or do trial decryption.

 
=C2=A74.3:

- =E2=80=9C This ciphertext value MAY be cached by an SRTP
   receiver to minimize computational effort by noting when = the SRTP
   master key is unchanged and avoiding repeating the steps = defined in ..=E2=80=9D

Are we really talking about the recipient? How would the recipient know = that the key has not changed without processing the ciphertext value? = (Also, the sentence is unfinished--maybe the answer would be clear if = the rest of the sentence came out of hiding :-) )

The unclear ending is a missing cross-reference to Section = 4.2.  I think the receiver optimization here is that if you cache = the tag, you can memcmp instead of decrypting.  Same on the sender = side, memcpy vs. encrypt.  Updated to reflect that.
 
- =E2=80=9C The receiver may want to have a sliding window to retain old = SRTP
   Master Keys (and related context) for some brief period of = time, so
   that out of order packets can be processed as well as = packets sent
   during the time keys are changing.=E2=80=9D

See comment to =C2=A74.2.2, step 6. =E2=80=9Cmay want=E2=80=9D seems = weak given that the sender SHOULD keep using the old key for a period of = time.

Revised this as noted above, though note that MAY WISH TO is = defined in RFC 6919.

 
=C2=A74.7: =E2=80=9CA new sender SHOULD send a packet containing the = FullEKTField as soon as possible...=E2=80=9D

Why not MUST? Would it ever make sense not to do this? It seems like the = mechanism doesn=E2=80=99t work very well otherwise.

How would you comply with a "MUST ... as soon as = possible"?  I don't think we want to dictate a schedule here, but = I've added a note that packet loss can result if you don't.

 
=C2=A76, first paragraph: =E2=80=9Cor other=E2=80=9D - what other?

Clarified.

 
- paragraph 8: =E2=80=9C An endpoint MUST NOT encrypt more than T = different FullEKTField values using the same EKTKey.=E2=80=9D

Is there a reciprocal requirement for decryption?

No.  The risk attaches once the ciphertext is = transmitted.

 
- last paragraph: =E2=80=9C...SHOULD be limited using the ekt_ttl=E2=80=9D=

Why not MUST?

Upgraded.

 
=C2=A77.3: Should this cite RFC 5246 instead of RFC 4366?

You mean RFC 8446?  Actually this line and the similar = one below it are both unnecessary, so I've deleted them.

 
*** Editorial Comments: ***

=C2=A72: =E2=80=9C...each endpoint picks there own SRTP master = key...:
s/their/its

Done.

 
=C2=A74.1, first paragraph: Please reference figures by number. I can = imagine some future RFC rendering failing to  maintain the relative = positions.  (This occurs a few times throughout the document.)

=C2=A74.2.2, step 3:
Should "The EKTCiphertext authentication is checked and is decrypted=E2=80= =9D be something like =E2=80=9C
The EKTCiphertext field authentication is checked and its contents = decrypted=E2=80=9D I assume you don=E2=80=99t mean to say its = authentication is decrypted.

"The EKTCiphertext is = authenticated and decrypted..." -- since these operations are combined = in many SRTP transforms.

 
Also, there=E2=80=99s a number of occurrences of =E2=80=9CThe = [fieldname]...=E2=80=9D that should probably say =E2=80=9CThe = [fieldname] field...=E2=80=9D

This doesn't seem like a = bad ambiguity to me.

 
- Step 6: s/crypto/cryptographic

Disagree.

 
- Step 7: is the replay protection part relevant to the step?

Deleted.  Added a note about replay to the security = considerations.

 
=C2=A74.3, third paragraph: This is the first mention of ekt_ttl. It = would help to have a brief explanation or at least a forward = reference.

Added a forward reference

 
=C2=A74.6: s/ =E2=80=9Cother specification=E2=80=9D / =E2=80=9Canother = specification=E2=80=9D ; or =E2=80=9Cother specifications=E2=80=9D

Revised.

 
=C2=A74.7, third paragraph: Both occurrences of =E2=80=9Cwhich=E2=80=9D = need preceding commas.

Done.

 
=C2=A75.2, paragraph after figure 4: =E2=80=9C ... the extensions = defined in this session allows the DTLS server...=E2=80=9D
Defined in this =E2=80=9Csession=E2=80=9D or this =E2=80=9Csection=E2=80=9D= ?

Actually, "in this document"

 
=C2=A7, paragraph 7: =E2=80=9C... causing the receiving system will = decrypt...=E2=80=9D
s/will/to

Done
 



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

= --Apple-Mail=_74023F88-25B2-408D-A065-8DBF1A000BFF-- --Apple-Mail=_6B0677C3-238F-4375-9FE7-937AB333F1C2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlu8/OUACgkQgFZKbJXz 1A3DwxAAnm+KAstA22JJdgMZOZFtdp2aAeEE0CZwkf3OS5Sa7NwfuOBp25Y9EsKN Ha67AQRj6GLuo8GAwcwg4RWAPqbYibs0Dxskecge42EPLwx3d9bQCTMtK/6HpkjW OzB4crVUkeNnm+xeQ/CTs90AIw0yOkahLgcSwXRDiQMn1lHlkJEDH9nv42Qq4ZJR mzO6f3a/aUrJd+93NENqeVo3xmgcWSqDX3BNJv+McudB0pCUb/YbykWWt0zvwKpg W5yByVUouPgwBGn1LfvOTjr7bRGZQSUKRiJbYelf6Qt43oHxuodITucidZlA3aRZ YANazrTQSfwxFnGLudwHIV/SaxfoDpc++h8uAOoE2IY+oZIyOsa/Dqjf4RuCIWiY htDzTCnZfV/VU2ZH/gLFDNYWT6U2pOi+4ydCjkCkk+zWIdkIH8x9xNqUiI1nD/4y HgLe93CxtB0hCRLoHv0XjLODAnQRRXhySSA0VI/ZjAwQuzG2RFgD6kNQq2Jkp443 pCuql7fTsJtw3rviTEnKmJufmNCCTVhsP3J+lxJ1DGbJ8xyYvyXQ6rx4cc4iwp7F oj+2qSFHow6EkUS8U+0Y1DBNc066jvagnD086E+LDTkmvbwIZ0XFZpWhyfuNHMrB y9D+oknyBU9acy50DZbkPrRcVXt/IL6kCMt2FdPLhpW5X53/4CE= =ycTP -----END PGP SIGNATURE----- --Apple-Mail=_6B0677C3-238F-4375-9FE7-937AB333F1C2-- From nobody Mon Oct 15 15:40:27 2018 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA513127B92; Mon, 15 Oct 2018 15:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 mzPBldBbyh-n; Mon, 15 Oct 2018 15:40:19 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 1BFAF130DEA; Mon, 15 Oct 2018 15:40:19 -0700 (PDT) Received: from [10.0.1.27] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w9FMeHnm084039 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 15 Oct 2018 17:40:18 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.27] From: Ben Campbell Message-Id: <095B6E4D-B6DF-4AE9-9853-1D0F87510A14@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_BE486A98-902D-4456-814C-A359EFF4308E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Mon, 15 Oct 2018 17:40:16 -0500 In-Reply-To: Cc: perc@ietf.org, draft-ietf-perc-double.all@ietf.org To: Richard Barnes References: <5AFC524E-7C2A-4C8F-B66B-7BAA3F048403@nostrum.com> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [Perc] AD Evaluation of draft-ietf-perc-double-09 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 22:40:24 -0000 --Apple-Mail=_BE486A98-902D-4456-814C-A359EFF4308E Content-Type: multipart/alternative; boundary="Apple-Mail=_D38BBA4B-CB1D-48AE-81EE-7CE61E827231" --Apple-Mail=_D38BBA4B-CB1D-48AE-81EE-7CE61E827231 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks, the PR looks good to me. Please submit a revision when you are = ready. I think that, with the PR applied, it will be ready for IETF LC. That = should probably be done in tandem with the media framework (in my queue = to review in the next couple of days. Authors and chairs: do you think = we should also coordinate with ekt-diet? Thanks! Ben. > On Oct 5, 2018, at 9:48 AM, Richard Barnes wrote: >=20 > Hey Ben, >=20 > After talking with Cullen, I am now the stuckee for this. I've filed = a PR at: >=20 > https://github.com/ietf/perc-wg/pull/160 = >=20 > Comments inline below. >=20 > On Tue, Jun 5, 2018 at 12:40 AM Ben Campbell > wrote: > Hi, >=20 > This is my AD Evaluation of draft-ietf-perc-double-09. Thanks for this = work; I think it is important and on the right track, but suffers from = some readability issues, especially from =C2=A77 onwards. I=E2=80=99d = like to discuss my comments prior to IETF last call. >=20 > Thanks! >=20 > Ben. >=20 > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94 >=20 > *** Substantive Comments *** >=20 > General: Does it make sense to progress this prior to = draft-ietf-perc-private-media-framework rather than wait and progress = them together? it seems like one really needs to read the framework to = understand at least parts of this draft. (Which would, btw, suggest = making the framework a normative reference.) >=20 > I think at this point, -framework has caught up a bit (I understand = it's awaiting your review), so this seems OBE. I agree that it will = make easier reading for ADs to read the three docs (this, framework, and = EKT) on the same telechat. >=20 >=20 > =C2=A72, Media Distributor: Should this be defined as switch-based? = Otherwise it seems circular. >=20 > I've copied down the definition =C2=A71, which explicitly says that = the MD does not need to interpret or change media content. Also added a = ref to -framework at this point. >=20 >=20 > =C2=A75 and subsections: These sections are confusing in the treatment = of extensions. =C2=A75.1 step 3 says to truncate the header to remove = any extensions. Yet other sections of text repeatedly mention the = handling of extensions. I think the document needs a paragraph or two to = describe the handling of RTP extensions at a high level. >=20 > I've added an overview of the transform, including thoughts on = extensions, to the top of =C2=A75. >=20 >=20 > Along those lines, it=E2=80=99s not entirely clear what is meant by = putting =E2=80=9C (12 + 4 * CC bytes)=E2=80=9D in parentheses after the = guidance to truncate in =C2=A75.1. Is that the amount to be truncated? = Amount left after truncation? (Same question for =C2=A75.3) >=20 > Clarified that this is the amount left after truncation, i.e., take = the first N bytes, in both places. >=20 >=20 > =C2=A75.2: It would be helpful to include a paragraph or two to = describe the impact if multiple MDs modify the same field(s). I can = infer that, but it would be better to be explicit. (IIRC, there is a = passing mention in the security considerations, but it would be better = to have more here.) >=20 > Added a paragraph. >=20 >=20 > =C2=A78: Can you offer any guidance about selecting 128 vs 256? >=20 > I don't really think there's much to say here; it's up to the user of = the transform. Use 128 unless you're paranoid, then use 256? :) Note = that RFC 7714, which defines the AES-GCM transforms, does not provide = similar guidance. >=20 >=20 > =C2=A79: >=20 > - The security considerations mainly summarize the mechanism. I=E2=80=99= d like to see a description of the potential attacks or risks and how = the double mechanism mitigates them. > - =E2=80=9C=E2=80=A6 this shouldn=E2=80=99t typically impact the = strength of e2e integrity given the fact that there doesn=E2=80=99t = exist header extensions defined today that needs e2e protection. = However, if future specifications define header extensions that needs = e2e integrity protection, the input to inner transform may be modified = to consider including the header.=E2=80=9D >=20 > - 2nd paragraph: Why is the HBH key for an outgoing packet only = =E2=80=9Ctypically=E2=80=9D different than the key for the incoming = packet? Are there security implications if they are the same? >=20 > - 2nd to last paragraph, last sentence: Please elaborate on those = risks? >=20 > I agree with your assessment that the existing security considerations = were not that useful. I've replaced them with an analysis that's more = focused on what protections are provided with respect to which = attackers. >=20 > The new version also calls out clearly that when a packet is = re-encrypted, the outer keys MUST be different. >=20 >=20 > *** Editorial comments and nits *** >=20 > There are a number of abbreviations that need to be expanded on first = use. Please remember that abbreviations should be expanded both in the = abstract and the body. >=20 > - SRTP > - SSRC > - SEQ > - ROC > - PRF > - PT > - SEQ > - RTX > - RED > - FEC >=20 > I've expanded most of these. I have left SSRC, SEQ, ROC, and PT, = since in this context, they are basically opaque labels for RTP header = fields. >=20 >=20 > =C2=A72: > - Please use the boilerplate from RFC8174. There are a number of lower = case instances of normative keywords. >=20 > Done. >=20 > - Please use consistent sentence (or lack of sentence) structure for = the definitions in the bullet list. >=20 > Done. >=20 > =C2=A73, >=20 > - " Generate key and salt values of the length required for the = combined inner (end-to-end) and outer (hop-by-hop) algorithms.=E2=80=9D: = The document is inconsistent in whether it describes a single key with = inner and outer halves, or separate inner and outer keys. I realize that = this is an artifact of syntax, but it is likely to confuse a reader new = to the topic. >=20 > The very next bullet says to glue them together. Not sure how else to = say this. >=20 > - Paragraph starting with =E2=80=9CObviously, if the Media = Distributor=E2=80=A6=E2=80=9D: =E2=80=9CObviously=E2=80=9D is a null = word in context. >=20 > Deleted. >=20 > =C2=A73.1: This section would be much more approachable if you defined = the terms (such as n, k, and x), rather than forcing readers to look = them up in 3711. Also, the doubled crypto suite IDs are likely to be = confusing to the reader who sees them here without the explanation later = in the draft. >=20 > Done. >=20 > =C2=A75.2, step 2: =E2=80=9CChange any parts of the RTP packet=E2=80=A6=E2= =80=9D -The MS is limited to changing the 3 fields defined for the OHB, = right, at least as defined in this draft? Not just anything it wants? >=20 > Correct. Done. >=20 > =C2=A75.3, last two paragraphs: It=E2=80=99s sort of an odd = construction to talk about =E2=80=9Cany of the following=E2=80=9D with a = single entry list.. >=20 > Revised to clarify. >=20 > =C2=A77 and subsections: These could use another proofreading pass. In = particular, it is imprecise about inner vs outer encryption, which = actors do what, and has a number of pronouns with ambiguous antecedents. = The heavy use of passive voice obscures the actors in multiple places. I = will call out some specifics, but please do not treat my comments as = exhaustive. >=20 > Did a revision pass, let me know what you think. >=20 > =C2=A77: =E2=80=9C The repair mechanism, when used with double, = typically operates on the double encrypted data and encrypts > them using only the HBH key.=E2=80=9D Does =E2=80=9Cdouble = encrypted=E2=80=9D mean =E2=80=9Couter encrypted=E2=80=9D? Also, while I = recognize =E2=80=9Cdata=E2=80=9D as plural, it=E2=80=99s plural in a = non-countable sense; that is, s / them / it. >=20 > =C2=A77.1: > - =E2=80=9C =E2=80=A6 cached payloads MUST be the encrypted packets = =E2=80=A6=E2=80=9D - Inner or outer? What device enforces this? = (Consider active voice.) > - Which element represents =E2=80=9Cthe other side=E2=80=9D? Are we = talking about an endpoint or MD? (Please stick to the defined = terminology) > - =E2=80=9C When encrypting a retransmission packet, it MUST be = encrypted the packet in repair mode.=E2=80=9D - I can=E2=80=99t parse = the phrase after the comma. Also, what device MUST encrypt it? >=20 > =C2=A77.2: > - =E2=80=9Cthe primary encoding MAY contain=E2=80=A6=E2=80=9D - Is = that MAY a grant of permission or a statement of fact? >=20 > - " The sender takes encrypted payload from the cached packets=E2=80=9D-= Missing article for encrypted payload? Or should this say =E2=80=9C=E2=80= =A6 takes encrypted packets from the cached payload=E2=80=A6=E2=80=9D? >=20 > - =E2=80=9C Any header extensions from the primary encoding are copied = to the RTP packet that will carry the RED payload and the other RTP = header information such as SSRC, SEQ, CSRC, etc are set to the same as = the primary payload. The RED RTP packet is then encrypted in repair = mode and sent.=E2=80=9D: This is confusing; parts are copied from the = primary encoding and others are the same as in the primary encoding? = Don=E2=80=99t both of those mean the same thing? >=20 > - =E2=80=9C The receiver decrypts the payload=E2=80=A6=E2=80=9D: = Endpoint or MD? Is this inner or outer encryption? >=20 > - Last paragraph: Seems like that belongs in the FEC section. Also, = does this document really need to make that sort of recommendation? It = seems like a general statement about RED and FEC that is not specific to = double. >=20 >=20 > =C2=A77.3: >=20 > - "When using Flex FEC [I-D.ietf-payload-flexible-fec-scheme] with = double, the negotiation of double for the crypto is the out of band = signaling that indicates that the repair packets MUST use the order of = operations of SRTP followed by FEC when encrypting.=E2=80=9D - The = sentence is hard to parse. Also, is MUST a normative requirement or a = statement of fact? (It seems odd to signal that you MUST do something). > - =E2=80=9C=E2=80=A6 data, which is already encrypted, it MUST be = encrypted in repair mode packet.=E2=80=9D s/ =E2=80=9C, which=E2=80=9D / = =E2=80=9Cthat=E2=80=9D. Also, what actor MUST encrypt the data in repair = mode? (Consider active voice.) >=20 > - =E2=80=9C The algorithm recommend=E2=80=A6=E2=80=9D s / recommend / = recommended >=20 > Done. >=20 > =C2=A77.4: > - s/ "sent with [RFC4733]=E2=80=9D / =E2=80=9Csent using the mechanism = in [RFC4733]=E2=80=9D > - =E2=80=9C and the relay can not read it so it cannot be used=E2=80=9D = - missing comma between =E2=80=9Cit=E2=80=9D and =E2=80=9Cso=E2=80=9D. >=20 > Done. >=20 > =C2=A78, last paragraph: =E2=80=9C For packets in repair mode, the = data they are caring is often already encrypted further increasing the = size.=E2=80=9D - I assume =E2=80=9Ccaring=E2=80=9D is not the intended = word. Did you mean =E2=80=9Ccarrying=E2=80=9D? If so, consider s / = =E2=80=9Cdata they are carrying=E2=80=9D / =E2=80=9Cdata they carry=E2=80=9D= >=20 > Revised. > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc --Apple-Mail=_D38BBA4B-CB1D-48AE-81EE-7CE61E827231 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks, the PR looks good to me. Please submit a revision = when you are ready.

I = think that, with the PR applied, it will be ready for IETF LC. =  That should probably be done in tandem with the media framework = (in my queue to review in the next couple of days. Authors and chairs: = do you think we should also coordinate with ekt-diet?

Thanks!

Ben.


On = Oct 5, 2018, at 9:48 AM, Richard Barnes <rlb@ipv.sx> wrote:

Hey = Ben,

After = talking with Cullen, I am now the stuckee for this.  I've filed a = PR at:

https://github.com/ietf/perc-wg/pull/160

Comments inline = below.

On Tue, Jun 5, 2018 at = 12:40 AM Ben Campbell <ben@nostrum.com> wrote:
Hi,

This is my AD Evaluation of draft-ietf-perc-double-09. Thanks for this = work; I think it is important and on the right track, but suffers from = some readability issues, especially from =C2=A77 onwards. I=E2=80=99d = like to discuss my comments prior to IETF last call.

Thanks!

Ben.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94

*** Substantive Comments ***

General: Does it make sense to progress this prior to = draft-ietf-perc-private-media-framework rather than wait and progress = them together? it seems like one really needs to read the framework to = understand at least parts of this draft. (Which would, btw, suggest = making the framework a normative reference.)

I think at this point, -framework has caught up a bit (I = understand it's awaiting your review), so this seems OBE.  I agree = that it will make easier reading for ADs to read the three docs (this, = framework, and EKT) on the same telechat.

 
=C2=A72, Media Distributor: Should this be defined as switch-based? = Otherwise it seems circular.

I've copied down the = definition =C2=A71, which explicitly says that the MD does not need to = interpret or change media content.  Also added a ref to -framework = at this point.

 
=C2=A75 and subsections: These sections are confusing in the treatment = of extensions. =C2=A75.1 step 3 says to truncate the header to remove = any extensions. Yet other sections of text repeatedly mention the = handling of extensions. I think the document needs a paragraph or two to = describe the handling of RTP extensions at a high level.

I've added an overview of the transform, including thoughts = on extensions, to the top of =C2=A75.
 
 
Along those lines, it=E2=80=99s not entirely clear what is meant by = putting =E2=80=9C (12 + 4 * CC bytes)=E2=80=9D in parentheses after the = guidance to truncate in =C2=A75.1. Is that the amount to be truncated? = Amount left after truncation? (Same question for =C2=A75.3)

Clarified that this is the amount left after truncation, = i.e., take the first N bytes, in both places.

 
=C2=A75.2: It would be helpful to include a paragraph or two to describe = the impact if multiple MDs modify the same field(s). I can infer that, = but it would be better to be explicit. (IIRC, there is a passing mention = in the security considerations, but it would be better to have more = here.)

Added a paragraph.

 
=C2=A78: Can you offer any guidance about selecting 128 vs 256?

I don't really think there's much to say here; it's up to the = user of the transform.  Use 128 unless you're paranoid, then use = 256?  :)  Note that RFC 7714, which defines the AES-GCM = transforms, does not provide similar guidance.

 
=C2=A79:

- The security considerations mainly summarize the mechanism. I=E2=80=99d = like to see a description of the potential attacks or risks  and = how the double mechanism mitigates them.
- =E2=80=9C=E2=80=A6 this shouldn=E2=80=99t typically impact the = strength of e2e integrity given the fact that there doesn=E2=80=99t = exist header extensions defined today that needs e2e protection.  = However, if future specifications define header extensions that needs = e2e integrity protection, the input to inner transform may be modified = to consider including the header.=E2=80=9D

- 2nd paragraph: Why is the HBH key for an outgoing packet only = =E2=80=9Ctypically=E2=80=9D different than the key for the incoming = packet? Are there security implications if they are the same?

- 2nd to last paragraph, last sentence: Please elaborate on those = risks?

I agree with your assessment that the = existing security considerations were not that useful.  I've = replaced them with an analysis that's more focused on what protections = are provided with respect to which attackers. 

The = new version also calls out clearly that when a packet is re-encrypted, = the outer keys MUST be different.

 
*** Editorial comments and nits ***

There are a number of abbreviations that need to be expanded on first = use. Please remember that abbreviations should be expanded both in the = abstract and the body.

- SRTP
- SSRC
- SEQ
- ROC
- PRF
- PT
- SEQ
- RTX
- RED
- FEC

I've expanded most of these.  I have left SSRC, SEQ, = ROC, and PT, since in this context, they are basically opaque labels for = RTP header fields. 

 
=C2=A72:
- Please use the boilerplate from RFC8174. There are a number of lower = case instances of normative keywords.

Done.
 
- Please use consistent sentence (or lack of sentence) structure for the = definitions in the bullet list.

Done.
 
=C2=A73,

- " Generate key and salt values of the length required for the combined = inner (end-to-end) and outer (hop-by-hop) algorithms.=E2=80=9D: The = document is inconsistent in whether it describes a single key with inner = and outer halves, or separate inner and outer keys. I realize that this = is an artifact of syntax, but it is likely to confuse a reader new to = the topic.

The very next bullet says to glue them = together.  Not sure how else to say this.
 
- Paragraph starting with =E2=80=9CObviously, if the Media = Distributor=E2=80=A6=E2=80=9D: =E2=80=9CObviously=E2=80=9D is a null = word in context.

Deleted.
 
=C2=A73.1: This section would be much more approachable if you defined = the terms (such as n, k, and x), rather than forcing readers to look = them up in 3711. Also, the doubled crypto suite IDs are likely to be = confusing to the reader who sees them here without the explanation later = in the draft.

Done.
 
=C2=A75.2, step 2: =E2=80=9CChange any parts of the RTP packet=E2=80=A6=E2= =80=9D -The MS is limited to changing the 3 fields defined for the OHB, = right, at least as defined in this draft? Not just anything it wants?

Correct.  Done.
 
=C2=A75.3, last two paragraphs: It=E2=80=99s sort of an odd construction = to talk about =E2=80=9Cany of the following=E2=80=9D with a single entry = list..

Revised to clarify.
 
=C2=A77 and subsections: These could use another proofreading pass. In = particular, it is imprecise about inner vs outer encryption, which = actors do what, and has a number of pronouns with ambiguous antecedents. = The heavy use of passive voice obscures the actors in multiple places. I = will call out some specifics, but please do not treat my comments as = exhaustive.

Did a revision pass, let me know what = you think.
 
=C2=A77: =E2=80=9C The repair mechanism, when used with double, = typically operates on the double encrypted data and encrypts
   them using only the HBH key.=E2=80=9D Does =E2=80=9Cdouble = encrypted=E2=80=9D mean =E2=80=9Couter encrypted=E2=80=9D? Also, while I = recognize =E2=80=9Cdata=E2=80=9D as plural, it=E2=80=99s plural in a = non-countable sense; that is, s / them / it.

=C2=A77.1:
- =E2=80=9C =E2=80=A6 cached payloads MUST be the encrypted packets = =E2=80=A6=E2=80=9D - Inner or outer? What device enforces this? = (Consider active voice.)
- Which element represents =E2=80=9Cthe other side=E2=80=9D? Are we = talking about an endpoint or MD? (Please stick to the defined = terminology)
- =E2=80=9C When encrypting a retransmission packet, it MUST be = encrypted the packet in repair mode.=E2=80=9D - I can=E2=80=99t parse = the phrase after the comma. Also, what device MUST encrypt it?

=C2=A77.2:
- =E2=80=9Cthe primary encoding MAY contain=E2=80=A6=E2=80=9D - Is that = MAY a grant of permission or a statement of fact?

- " The sender takes encrypted payload from the cached packets=E2=80=9D- = Missing article for encrypted payload? Or should this say =E2=80=9C=E2=80=A6= takes encrypted packets from the cached payload=E2=80=A6=E2=80=9D?

- =E2=80=9C Any header extensions from the primary encoding are copied = to the RTP packet that will carry the RED payload and the other RTP = header information such as SSRC, SEQ, CSRC, etc are set to the same as = the primary payload.  The RED RTP packet is then encrypted in = repair mode and sent.=E2=80=9D: This is confusing; parts are copied from = the primary encoding and others are the same as in the primary encoding? = Don=E2=80=99t both of those mean the same thing?

- =E2=80=9C The receiver decrypts the payload=E2=80=A6=E2=80=9D: = Endpoint or MD? Is this inner or outer encryption?

- Last paragraph: Seems like that belongs in the FEC section. Also, does = this document really need to make that sort of recommendation? It seems = like a general statement about RED and FEC that is not specific to = double.


=C2=A77.3:

- "When using Flex FEC [I-D.ietf-payload-flexible-fec-scheme] with = double, the negotiation of double for the crypto is the out of band = signaling that indicates that the repair packets MUST use the order of = operations of SRTP followed by FEC when encrypting.=E2=80=9D - The = sentence is hard to parse. Also, is MUST a normative requirement or a = statement of fact? (It seems odd to signal that you MUST do = something).
- =E2=80=9C=E2=80=A6  data, which is already encrypted, it MUST be = encrypted in repair mode packet.=E2=80=9D s/ =E2=80=9C, which=E2=80=9D / = =E2=80=9Cthat=E2=80=9D. Also, what actor MUST encrypt the data in repair = mode? (Consider active voice.)

- =E2=80=9C The algorithm recommend=E2=80=A6=E2=80=9D s / recommend / = recommended

Done.
 
=C2=A77.4:
- s/ "sent with [RFC4733]=E2=80=9D / =E2=80=9Csent using the mechanism = in [RFC4733]=E2=80=9D
- =E2=80=9C and the relay can not read it so it cannot be used=E2=80=9D = - missing comma between =E2=80=9Cit=E2=80=9D and =E2=80=9Cso=E2=80=9D.

Done.
 
=C2=A78, last paragraph: =E2=80=9C For packets in repair mode, the data = they are caring is often already encrypted further increasing the = size.=E2=80=9D - I assume =E2=80=9Ccaring=E2=80=9D is not the intended = word. Did you mean =E2=80=9Ccarrying=E2=80=9D? If so, consider s / = =E2=80=9Cdata they are carrying=E2=80=9D / =E2=80=9Cdata they = carry=E2=80=9D

Revised.
_______________________________________________
Perc = mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc

= --Apple-Mail=_D38BBA4B-CB1D-48AE-81EE-7CE61E827231-- --Apple-Mail=_BE486A98-902D-4456-814C-A359EFF4308E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlvFF1AACgkQgFZKbJXz 1A3byg/8CpRlGlgv6oKf8JC1BtUGkCLwGbzE8YsXys1IIAaHFnPK6DVCHgk3Tjtb 5QcmvRMDeSyPXKbeU4iXNKV+1CdSMZFwDLYu1rEEbwJEfXWCcGMi3v9xPrXyJwD1 7EzlVRc4vBZtSNrDOPaHBDHPbM/GRESQdVZSAduWQO7bTOSBJ1vdWKSk5t20lEZF ojO8uYyBtT4YgIBKvdCY0eGcEH5vUB8CanxCT2RdUDSswCh9hn8dpU0AygV/4AQ9 6E4+b/aDCMfGy4M4tJEhZM4C/uUyYYF4vtu+hg/PToRkzDcZlwFPFP/37dzTCBbM xUGwFSEJR4/AzblXY71tbCb/SqZ+yeogdVgtkeCkVl09HM+eU8uFZHvMyGDqQFHt FpGG7SJ3LXP+LMvSzCmFG8oOA93RjSTSHLh0Zc0SOx8zRhqp1VAvtu6RzBVsVDCA vPX1kBpjE94/d2E490b4774W9xCbZNjWfh2y/AphQzt9Dr+xIStVQIw2c8M8v8xk qFqViWzsCNb+nL7MZ8hUADRnrKeEAlJs3dXdBZ3ivBqBE/Z/6JibSxZBBoJYx19N 93V8uga0argbxjpI0MRfkrmxbDClxtpiLMUSvQyQ8y242F/nCxm8NYFa17S6womz yZ+sGT7PQ/WL0GLlvRww/6HDCSGmrq5/ZHkjfeiV4iDRYTd5kDU= =PCmf -----END PGP SIGNATURE----- --Apple-Mail=_BE486A98-902D-4456-814C-A359EFF4308E-- From nobody Mon Oct 15 15:43:14 2018 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15120130DEF for ; Mon, 15 Oct 2018 15:43:12 -0700 (PDT) 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=ham 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 wuG9l3DoVPnE for ; Mon, 15 Oct 2018 15:43:09 -0700 (PDT) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (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 D09A3130DE4 for ; Mon, 15 Oct 2018 15:43:08 -0700 (PDT) Received: by mail-oi1-x234.google.com with SMTP id e17-v6so16453715oib.4 for ; Mon, 15 Oct 2018 15:43:08 -0700 (PDT) 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=jhqBlq6soNOhvJkBUD8umE69ahQHu9z4hgZ4atdoDk0=; b=hCe04kvjV95j5eNHOUoAp61tPOmmIChVrwQGo0AteUqsuJiTfqLQ38ODctprIR5Dsm zgXS0+TS8JNJETrlw/Hrd3aRsSp6RDR3edZe0FnJ1o0IHhpGEwag1JyNOweUj49Dmw50 eoZtSgcl30upH1TJrHkWsoJ/kRDhsl3v6XmzecF1piRxO5TsWkWhflzRnPJHhqNESOIn ULru03Pc8cOSZ1NzQpJHHkP6zuP6/eSvK/ossAY6VYPk6iRhHQRdSD0xXCtVUxd3ioll K4yZ+9xn9HKF/Zwdr18+Lsml9qeqe/fJAliEKnieHzQglTJhwYiZAFBM95sHuGJgeLpq IVSQ== 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=jhqBlq6soNOhvJkBUD8umE69ahQHu9z4hgZ4atdoDk0=; b=T5rbxEdJEDQXkQPaGchp8AoA8XZZ+G+jHgX/sXIj1PaI9WZSer1XhqWcjBit5WIziv GyrVBsEfTztVm1r4J6Brhk/MRzypHCUP4y2ZmvPZrGiGiaSetXFO3YpZOOIoXBLl3NYR Jbf0j/5tlZ16kYDCZK+AuqkwqKelwPFEu8/4hSgRJbuEBqRcqB3Kheifnhn1s6ApX/cy K5aaF5sAMzgZ/PxhFcE7VHh/JUYRGFnQmtxHC+k5WeRyMk+KHqu6ocACX2+s+NSat9CF 4Y8HB6VjikgsMRn0LVI5ZAMHfpF/fB6macG3esb9Q9a2uHJn5kWDrdVQBM62BVDl3XxP X9lA== X-Gm-Message-State: ABuFfogHUtq37BfDqecFAVE+G/NtSsy0Q2wv0j8i/52QMQ9AYh3J2pFw Mk7qn9mDykhnUZXxIlxbY3UxKvMfq4sm6qprl684+nV4kWQ= X-Google-Smtp-Source: ACcGV61OBZz50xJ/xCv2r1j9gBUguxBP9N8ZQwmkYU5EliXfAWvkGiilUfOnHkyXOHpudq0GyJQDuu5eGiIET0tsHjQ= X-Received: by 2002:aca:d05c:: with SMTP id h89-v6mr9824131oig.199.1539643387967; Mon, 15 Oct 2018 15:43:07 -0700 (PDT) MIME-Version: 1.0 References: <5AFC524E-7C2A-4C8F-B66B-7BAA3F048403@nostrum.com> <095B6E4D-B6DF-4AE9-9853-1D0F87510A14@nostrum.com> In-Reply-To: <095B6E4D-B6DF-4AE9-9853-1D0F87510A14@nostrum.com> From: Richard Barnes Date: Mon, 15 Oct 2018 18:42:49 -0400 Message-ID: To: Ben Campbell Cc: perc@ietf.org, draft-ietf-perc-double.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000388d1f05784c297c" Archived-At: Subject: Re: [Perc] AD Evaluation of draft-ietf-perc-double-09 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 22:43:12 -0000 --000000000000388d1f05784c297c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would propose we put forward all three documents together. (-double, -ekt-diet, and -framework) They'll be more comprehensible to the ADs that way. On Mon, Oct 15, 2018 at 6:40 PM Ben Campbell wrote: > Thanks, the PR looks good to me. Please submit a revision when you are > ready. > > I think that, with the PR applied, it will be ready for IETF LC. That > should probably be done in tandem with the media framework (in my queue t= o > review in the next couple of days. Authors and chairs: do you think we > should also coordinate with ekt-diet? > > Thanks! > > Ben. > > > On Oct 5, 2018, at 9:48 AM, Richard Barnes wrote: > > Hey Ben, > > After talking with Cullen, I am now the stuckee for this. I've filed a P= R > at: > > https://github.com/ietf/perc-wg/pull/160 > > Comments inline below. > > On Tue, Jun 5, 2018 at 12:40 AM Ben Campbell wrote: > >> Hi, >> >> This is my AD Evaluation of draft-ietf-perc-double-09. Thanks for this >> work; I think it is important and on the right track, but suffers from s= ome >> readability issues, especially from =C2=A77 onwards. I=E2=80=99d like to= discuss my >> comments prior to IETF last call. >> >> Thanks! >> >> Ben. >> >> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94 >> >> *** Substantive Comments *** >> >> General: Does it make sense to progress this prior to >> draft-ietf-perc-private-media-framework rather than wait and progress th= em >> together? it seems like one really needs to read the framework to >> understand at least parts of this draft. (Which would, btw, suggest maki= ng >> the framework a normative reference.) >> > > I think at this point, -framework has caught up a bit (I understand it's > awaiting your review), so this seems OBE. I agree that it will make easi= er > reading for ADs to read the three docs (this, framework, and EKT) on the > same telechat. > > > >> =C2=A72, Media Distributor: Should this be defined as switch-based? Othe= rwise >> it seems circular. >> > > I've copied down the definition =C2=A71, which explicitly says that the M= D does > not need to interpret or change media content. Also added a ref to > -framework at this point. > > > >> =C2=A75 and subsections: These sections are confusing in the treatment o= f >> extensions. =C2=A75.1 step 3 says to truncate the header to remove any >> extensions. Yet other sections of text repeatedly mention the handling o= f >> extensions. I think the document needs a paragraph or two to describe th= e >> handling of RTP extensions at a high level. >> > > I've added an overview of the transform, including thoughts on extensions= , > to the top of =C2=A75. > > > >> Along those lines, it=E2=80=99s not entirely clear what is meant by putt= ing =E2=80=9C (12 >> + 4 * CC bytes)=E2=80=9D in parentheses after the guidance to truncate i= n =C2=A75.1. Is >> that the amount to be truncated? Amount left after truncation? (Same >> question for =C2=A75.3) >> > > Clarified that this is the amount left after truncation, i.e., take the > first N bytes, in both places. > > > >> =C2=A75.2: It would be helpful to include a paragraph or two to describe= the >> impact if multiple MDs modify the same field(s). I can infer that, but i= t >> would be better to be explicit. (IIRC, there is a passing mention in the >> security considerations, but it would be better to have more here.) >> > > Added a paragraph. > > > >> =C2=A78: Can you offer any guidance about selecting 128 vs 256? >> > > I don't really think there's much to say here; it's up to the user of the > transform. Use 128 unless you're paranoid, then use 256? :) Note that > RFC 7714, which defines the AES-GCM transforms, does not provide similar > guidance. > > > >> =C2=A79: >> >> - The security considerations mainly summarize the mechanism. I=E2=80=99= d like to >> see a description of the potential attacks or risks and how the double >> mechanism mitigates them. >> - =E2=80=9C=E2=80=A6 this shouldn=E2=80=99t typically impact the strengt= h of e2e integrity given >> the fact that there doesn=E2=80=99t exist header extensions defined toda= y that >> needs e2e protection. However, if future specifications define header >> extensions that needs e2e integrity protection, the input to inner >> transform may be modified to consider including the header.=E2=80=9D >> >> - 2nd paragraph: Why is the HBH key for an outgoing packet only >> =E2=80=9Ctypically=E2=80=9D different than the key for the incoming pack= et? Are there >> security implications if they are the same? >> >> - 2nd to last paragraph, last sentence: Please elaborate on those risks? >> > > I agree with your assessment that the existing security considerations > were not that useful. I've replaced them with an analysis that's more > focused on what protections are provided with respect to which attackers. > > The new version also calls out clearly that when a packet is re-encrypted= , > the outer keys MUST be different. > > > >> *** Editorial comments and nits *** >> >> There are a number of abbreviations that need to be expanded on first >> use. Please remember that abbreviations should be expanded both in the >> abstract and the body. >> >> - SRTP >> - SSRC >> - SEQ >> - ROC >> - PRF >> - PT >> - SEQ >> - RTX >> - RED >> - FEC >> > > I've expanded most of these. I have left SSRC, SEQ, ROC, and PT, since i= n > this context, they are basically opaque labels for RTP header fields. > > > >> =C2=A72: >> - Please use the boilerplate from RFC8174. There are a number of lower >> case instances of normative keywords. >> > > Done. > > >> - Please use consistent sentence (or lack of sentence) structure for the >> definitions in the bullet list. >> > > Done. > > >> =C2=A73, >> >> - " Generate key and salt values of the length required for the combined >> inner (end-to-end) and outer (hop-by-hop) algorithms.=E2=80=9D: The docu= ment is >> inconsistent in whether it describes a single key with inner and outer >> halves, or separate inner and outer keys. I realize that this is an >> artifact of syntax, but it is likely to confuse a reader new to the topi= c. >> > > The very next bullet says to glue them together. Not sure how else to sa= y > this. > > >> - Paragraph starting with =E2=80=9CObviously, if the Media Distributor= =E2=80=A6=E2=80=9D: >> =E2=80=9CObviously=E2=80=9D is a null word in context. >> > > Deleted. > > >> =C2=A73.1: This section would be much more approachable if you defined t= he >> terms (such as n, k, and x), rather than forcing readers to look them up= in >> 3711. Also, the doubled crypto suite IDs are likely to be confusing to t= he >> reader who sees them here without the explanation later in the draft. >> > > Done. > > >> =C2=A75.2, step 2: =E2=80=9CChange any parts of the RTP packet=E2=80=A6= =E2=80=9D -The MS is limited to >> changing the 3 fields defined for the OHB, right, at least as defined in >> this draft? Not just anything it wants? >> > > Correct. Done. > > >> =C2=A75.3, last two paragraphs: It=E2=80=99s sort of an odd construction= to talk about >> =E2=80=9Cany of the following=E2=80=9D with a single entry list.. >> > > Revised to clarify. > > >> =C2=A77 and subsections: These could use another proofreading pass. In >> particular, it is imprecise about inner vs outer encryption, which actor= s >> do what, and has a number of pronouns with ambiguous antecedents. The he= avy >> use of passive voice obscures the actors in multiple places. I will call >> out some specifics, but please do not treat my comments as exhaustive. >> > > Did a revision pass, let me know what you think. > > >> =C2=A77: =E2=80=9C The repair mechanism, when used with double, typicall= y operates on >> the double encrypted data and encrypts >> them using only the HBH key.=E2=80=9D Does =E2=80=9Cdouble encrypted= =E2=80=9D mean =E2=80=9Couter >> encrypted=E2=80=9D? Also, while I recognize =E2=80=9Cdata=E2=80=9D as pl= ural, it=E2=80=99s plural in a >> non-countable sense; that is, s / them / it. >> >> =C2=A77.1: >> - =E2=80=9C =E2=80=A6 cached payloads MUST be the encrypted packets =E2= =80=A6=E2=80=9D - Inner or outer? >> What device enforces this? (Consider active voice.) >> - Which element represents =E2=80=9Cthe other side=E2=80=9D? Are we talk= ing about an >> endpoint or MD? (Please stick to the defined terminology) >> - =E2=80=9C When encrypting a retransmission packet, it MUST be encrypte= d the >> packet in repair mode.=E2=80=9D - I can=E2=80=99t parse the phrase after= the comma. Also, >> what device MUST encrypt it? >> >> =C2=A77.2: >> - =E2=80=9Cthe primary encoding MAY contain=E2=80=A6=E2=80=9D - Is that = MAY a grant of permission >> or a statement of fact? >> >> - " The sender takes encrypted payload from the cached packets=E2=80=9D-= Missing >> article for encrypted payload? Or should this say =E2=80=9C=E2=80=A6 tak= es encrypted >> packets from the cached payload=E2=80=A6=E2=80=9D? >> >> - =E2=80=9C Any header extensions from the primary encoding are copied t= o the RTP >> packet that will carry the RED payload and the other RTP header informat= ion >> such as SSRC, SEQ, CSRC, etc are set to the same as the primary payload. >> The RED RTP packet is then encrypted in repair mode and sent.=E2=80=9D: = This is >> confusing; parts are copied from the primary encoding and others are the >> same as in the primary encoding? Don=E2=80=99t both of those mean the sa= me thing? >> >> - =E2=80=9C The receiver decrypts the payload=E2=80=A6=E2=80=9D: Endpoin= t or MD? Is this inner or >> outer encryption? >> >> - Last paragraph: Seems like that belongs in the FEC section. Also, does >> this document really need to make that sort of recommendation? It seems >> like a general statement about RED and FEC that is not specific to doubl= e. >> >> >> =C2=A77.3: >> >> - "When using Flex FEC [I-D.ietf-payload-flexible-fec-scheme] with >> double, the negotiation of double for the crypto is the out of band >> signaling that indicates that the repair packets MUST use the order of >> operations of SRTP followed by FEC when encrypting.=E2=80=9D - The sente= nce is hard >> to parse. Also, is MUST a normative requirement or a statement of fact? = (It >> seems odd to signal that you MUST do something). >> > - =E2=80=9C=E2=80=A6 data, which is already encrypted, it MUST be encryp= ted in repair >> mode packet.=E2=80=9D s/ =E2=80=9C, which=E2=80=9D / =E2=80=9Cthat=E2=80= =9D. Also, what actor MUST encrypt the data >> in repair mode? (Consider active voice.) >> >> - =E2=80=9C The algorithm recommend=E2=80=A6=E2=80=9D s / recommend / re= commended >> > > Done. > > >> =C2=A77.4: >> - s/ "sent with [RFC4733]=E2=80=9D / =E2=80=9Csent using the mechanism i= n [RFC4733]=E2=80=9D >> - =E2=80=9C and the relay can not read it so it cannot be used=E2=80=9D = - missing comma >> between =E2=80=9Cit=E2=80=9D and =E2=80=9Cso=E2=80=9D. >> > > Done. > > >> =C2=A78, last paragraph: =E2=80=9C For packets in repair mode, the data = they are >> caring is often already encrypted further increasing the size.=E2=80=9D = - I assume >> =E2=80=9Ccaring=E2=80=9D is not the intended word. Did you mean =E2=80= =9Ccarrying=E2=80=9D? If so, consider >> s / =E2=80=9Cdata they are carrying=E2=80=9D / =E2=80=9Cdata they carry= =E2=80=9D > > > Revised. > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > > > --000000000000388d1f05784c297c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would propose we put forward all three documents togethe= r.=C2=A0 (-double, -ekt-diet, and -framework)=C2=A0 They'll be more com= prehensible to the ADs that way.

On Mon, Oct 15, 2018 at 6:40 PM Ben Campbell <ben@nostrum.com> wrote:
Thanks, the PR looks good to me. Please submit a revision when yo= u are ready.

I think that, with the PR applied, it will = be ready for IETF LC.=C2=A0 That should probably be done in tandem with the= media framework (in my queue to review in the next couple of days. Authors= and chairs: do you think we should also coordinate with ekt-diet?

Thanks!

Ben.

=

On Oct 5, 2018, at 9:48 AM, Ri= chard Barnes <rlb@ipv.sx= > wrote:

Hey Ben,

=
After talking with Cullen, I am now the stuckee for this.=C2=A0 = I've filed a PR at:


Comments inline below.

On Tue, Jun 5, 2018 at 12= :40 AM Ben Campbell <ben@nostrum.com> wrote:
Hi,

This is my AD Evaluation of draft-ietf-perc-double-09. Thanks for this work= ; I think it is important and on the right track, but suffers from some rea= dability issues, especially from =C2=A77 onwards. I=E2=80=99d like to discu= ss my comments prior to IETF last call.

Thanks!

Ben.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94

*** Substantive Comments ***

General: Does it make sense to progress this prior to draft-ietf-perc-priva= te-media-framework rather than wait and progress them together? it seems li= ke one really needs to read the framework to understand at least parts of t= his draft. (Which would, btw, suggest making the framework a normative refe= rence.)

I think at this point, -framewo= rk has caught up a bit (I understand it's awaiting your review), so thi= s seems OBE.=C2=A0 I agree that it will make easier reading for ADs to read= the three docs (this, framework, and EKT) on the same telechat.
<= div>
=C2=A0
=C2=A72, Media Distributor: Should this be defined as switch-based? Otherwi= se it seems circular.

I've copied d= own the definition =C2=A71, which explicitly says that the MD does not need= to interpret or change media content.=C2=A0 Also added a ref to -framework= at this point.

=C2=A0
=C2=A75 and subsections: These sections are confusing in the treatment of e= xtensions. =C2=A75.1 step 3 says to truncate the header to remove any exten= sions. Yet other sections of text repeatedly mention the handling of extens= ions. I think the document needs a paragraph or two to describe the handlin= g of RTP extensions at a high level.

I&= #39;ve added an overview of the transform, including thoughts on extensions= , to the top of =C2=A75.
=C2=A0
=C2=A0
Along those lines, it=E2=80=99s not entirely clear what is meant by putting= =E2=80=9C (12 + 4 * CC bytes)=E2=80=9D in parentheses after the guidance t= o truncate in =C2=A75.1. Is that the amount to be truncated? Amount left af= ter truncation? (Same question for =C2=A75.3)

Clarified that this is the amount left after truncation, i.e., take = the first N bytes, in both places.

=C2=A0
=C2=A75.2: It would be helpful to include a paragraph or two to describe th= e impact if multiple MDs modify the same field(s). I can infer that, but it= would be better to be explicit. (IIRC, there is a passing mention in the s= ecurity considerations, but it would be better to have more here.)

Added a paragraph.

=C2= =A0
=C2=A78: Can you offer any guidance about selecting 128 vs 256?

I don't really think there's much to say h= ere; it's up to the user of the transform.=C2=A0 Use 128 unless you'= ;re paranoid, then use 256?=C2=A0 :)=C2=A0 Note that RFC 7714, which define= s the AES-GCM transforms, does not provide similar guidance.
=
=C2=A0
*** Editorial comments and nits ***

There are a number of abbreviations that need to be expanded on first use. = Please remember that abbreviations should be expanded both in the abstract = and the body.

- SRTP
- SSRC
- SEQ
- ROC
- PRF
- PT
- SEQ
- RTX
- RED
- FEC

I've expanded most of these.= =C2=A0 I have left SSRC, SEQ, ROC, and PT, since in this context, they are = basically opaque labels for RTP header fields.=C2=A0

=C2=A0
=C2=A72:
- Please use the boilerplate from RFC8174. There are a number of lower case= instances of normative keywords.

Done.=
=C2=A0
=C2=A73,

- " Generate key and salt values of the length required for the combin= ed inner (end-to-end) and outer (hop-by-hop) algorithms.=E2=80=9D: The docu= ment is inconsistent in whether it describes a single key with inner and ou= ter halves, or separate inner and outer keys. I realize that this is an art= ifact of syntax, but it is likely to confuse a reader new to the topic.
=

The very next bullet says to glue them tog= ether.=C2=A0 Not sure how else to say this.
=C2=A0
- Paragraph starting with =E2=80=9CObviously, if the Media Distributor=E2= =80=A6=E2=80=9D: =E2=80=9CObviously=E2=80=9D is a null word in context.
=

Deleted.
=C2=A0
=C2=A73.1: This section would be much more approachable if you defined the = terms (such as n, k, and x), rather than forcing readers to look them up in= 3711. Also, the doubled crypto suite IDs are likely to be confusing to the= reader who sees them here without the explanation later in the draft.
<= /blockquote>

Done.
=C2=A0
=C2=A75.2, step 2: =E2=80=9CChange any parts of the RTP packet=E2=80=A6=E2= =80=9D -The MS is limited to changing the 3 fields defined for the OHB, rig= ht, at least as defined in this draft? Not just anything it wants?

Correct.=C2=A0 Done.
=C2=A0
=
=C2=A75.3, last two paragraphs: It=E2=80=99s sort of an odd construction to= talk about =E2=80=9Cany of the following=E2=80=9D with a single entry list= ..

Revised to clarify.
= =C2=A0
=C2=A77 and subsections: These could use another proofreading pass. In part= icular, it is imprecise about inner vs outer encryption, which actors do wh= at, and has a number of pronouns with ambiguous antecedents. The heavy use = of passive voice obscures the actors in multiple places. I will call out so= me specifics, but please do not treat my comments as exhaustive.

Did a revision pass, let me know what you think.<= br>
=C2=A0
=C2=A77: =E2=80=9C The repair mechanism, when used with double, typically o= perates on the double encrypted data and encrypts
=C2=A0 =C2=A0them using only the HBH key.=E2=80=9D Does =E2=80=9Cdouble enc= rypted=E2=80=9D mean =E2=80=9Couter encrypted=E2=80=9D? Also, while I recog= nize =E2=80=9Cdata=E2=80=9D as plural, it=E2=80=99s plural in a non-countab= le sense; that is, s / them / it.

=C2=A77.1:
- =E2=80=9C =E2=80=A6 cached payloads MUST be the encrypted packets =E2=80= =A6=E2=80=9D - Inner or outer? What device enforces this? (Consider active = voice.)
- Which element represents =E2=80=9Cthe other side=E2=80=9D? Are we talking= about an endpoint or MD? (Please stick to the defined terminology)
- =E2=80=9C When encrypting a retransmission packet, it MUST be encrypted t= he packet in repair mode.=E2=80=9D - I can=E2=80=99t parse the phrase after= the comma. Also, what device MUST encrypt it?

=C2=A77.2:
- =E2=80=9Cthe primary encoding MAY contain=E2=80=A6=E2=80=9D - Is that MAY= a grant of permission or a statement of fact?

- " The sender takes encrypted payload from the cached packets=E2=80= =9D- Missing article for encrypted payload? Or should this say =E2=80=9C=E2= =80=A6 takes encrypted packets from the cached payload=E2=80=A6=E2=80=9D?
- =E2=80=9C Any header extensions from the primary encoding are copied to t= he RTP packet that will carry the RED payload and the other RTP header info= rmation such as SSRC, SEQ, CSRC, etc are set to the same as the primary pay= load.=C2=A0 The RED RTP packet is then encrypted in repair mode and sent.= =E2=80=9D: This is confusing; parts are copied from the primary encoding an= d others are the same as in the primary encoding? Don=E2=80=99t both of tho= se mean the same thing?

- =E2=80=9C The receiver decrypts the payload=E2=80=A6=E2=80=9D: Endpoint o= r MD? Is this inner or outer encryption?

- Last paragraph: Seems like that belongs in the FEC section. Also, does th= is document really need to make that sort of recommendation? It seems like = a general statement about RED and FEC that is not specific to double.


=C2=A77.3:

- "When using Flex FEC [I-D.ietf-payload-flexible-fec-scheme] with dou= ble, the negotiation of double for the crypto is the out of band signaling = that indicates that the repair packets MUST use the order of operations of = SRTP followed by FEC when encrypting.=E2=80=9D - The sentence is hard to pa= rse. Also, is MUST a normative requirement or a statement of fact? (It seem= s odd to signal that you MUST do something).
- =E2=80=9C=E2=80=A6=C2=A0 data, which is already encrypted, it MUST be enc= rypted in repair mode packet.=E2=80=9D s/ =E2=80=9C, which=E2=80=9D / =E2= =80=9Cthat=E2=80=9D. Also, what actor MUST encrypt the data in repair mode?= (Consider active voice.)

- =E2=80=9C The algorithm recommend=E2=80=A6=E2=80=9D s / recommend / recom= mended

Done.
=C2=A0
=
=C2=A77.4:
- s/ "sent with [RFC4733]=E2=80=9D / =E2=80=9Csent using the mechanism= in [RFC4733]=E2=80=9D
- =E2=80=9C and the relay can not read it so it cannot be used=E2=80=9D - m= issing comma between =E2=80=9Cit=E2=80=9D and =E2=80=9Cso=E2=80=9D.

Done.
=C2=A0
=C2=A78, last paragraph: =E2=80=9C For packets in repair mode, the data the= y are caring is often already encrypted further increasing the size.=E2=80= =9D - I assume =E2=80=9Ccaring=E2=80=9D is not the intended word. Did you m= ean =E2=80=9Ccarrying=E2=80=9D? If so, consider s / =E2=80=9Cdata they are = carrying=E2=80=9D / =E2=80=9Cdata they carry=E2=80=9D

=
Revised.
_______________________________________________
Perc mailing list
Perc@ietf.org
https://= www.ietf.org/mailman/listinfo/perc

--000000000000388d1f05784c297c-- From nobody Mon Oct 15 16:03:27 2018 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FD3130F01; Mon, 15 Oct 2018 16:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 af5RA35HY4y0; Mon, 15 Oct 2018 16:03:23 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 1D6FC130E25; Mon, 15 Oct 2018 16:03:23 -0700 (PDT) Received: from [10.0.1.27] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w9FN3LLr087754 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 15 Oct 2018 18:03:22 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.27] From: Ben Campbell Message-Id: <13EEFBA0-C345-4DBE-ADC9-110717CB96E5@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_3C0FD83D-162D-4D49-9E03-D70F94781B83"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Mon, 15 Oct 2018 18:03:20 -0500 In-Reply-To: Cc: draft-ietf-perc-srtp-ekt-diet.all@ietf.org, perc@ietf.org To: Richard Barnes References: X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [Perc] AD Evaluation of draft-ietf-perc-srtp-ekt-diet-08 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 23:03:26 -0000 --Apple-Mail=_3C0FD83D-162D-4D49-9E03-D70F94781B83 Content-Type: multipart/alternative; boundary="Apple-Mail=_B7E57D56-26A6-4C96-85DA-D3C7F8882AAB" --Apple-Mail=_B7E57D56-26A6-4C96-85DA-D3C7F8882AAB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The PR looks good to me. Once submitted with the PR applied,I think this = is ready for IETF LC, subject to coordination with the framework and = double drafts. Please submit when you are ready. I do have a few that I do not expect to cause document changes: > On Oct 9, 2018, at 2:06 PM, Richard Barnes wrote: >=20 > Thanks for the review, Ben. I've posted a PR with responses; notes = inline below... >=20 > https://github.com/ietf/perc-wg/pull/161 = >=20 [...] >=20 > - =E2=80=9C The receiver may want to have a sliding window to retain = old SRTP > Master Keys (and related context) for some brief period of time, so > that out of order packets can be processed as well as packets sent > during the time keys are changing.=E2=80=9D >=20 > See comment to =C2=A74.2.2, step 6. =E2=80=9Cmay want=E2=80=9D seems = weak given that the sender SHOULD keep using the old key for a period of = time. >=20 > Revised this as noted above, though note that MAY WISH TO is defined = in RFC 6919. Sure, put a normative reference to RFC 6919 in there. The resulting = downref discussion on the telechat should be fun. ;-) >=20 >=20 > =C2=A74.7: =E2=80=9CA new sender SHOULD send a packet containing the = FullEKTField as soon as possible...=E2=80=9D >=20 > Why not MUST? Would it ever make sense not to do this? It seems like = the mechanism doesn=E2=80=99t work very well otherwise. >=20 > How would you comply with a "MUST ... as soon as possible"? I don't = think we want to dictate a schedule here, but I've added a note that = packet loss can result if you don=E2=80=99t. I note that =E2=80=9CSHOULD ... as soon as possible=E2=80=9D has = somewhat the same issue. But adding the note addresses my concern. [...] >=20 >=20 > *** Editorial Comments: *** [...] >=20 >=20 > - Step 6: s/crypto/cryptographic >=20 > Disagree. Really? I=E2=80=99m not going to push the point, but I=E2=80=99m curious = why? Especially since the financial industry is doing it=E2=80=99s best = to steal =E2=80=9Ccrypto=E2=80=9D. But now I wonder if I=E2=80=99ve = missed some subtle difference of definition. [...] --Apple-Mail=_B7E57D56-26A6-4C96-85DA-D3C7F8882AAB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = PR looks good to me. Once submitted with the PR applied,I think this is = ready for IETF LC, subject to coordination with the framework and double = drafts. Please submit when you are ready.

I do have a few that I do not expect to = cause document changes:


On Oct 9, 2018, at 2:06 PM, Richard Barnes <rlb@ipv.sx> wrote:

Thanks for the review, Ben.  I've posted a PR with = responses; notes inline below...

https://github.com/ietf/perc-wg/pull/161


[...]

 
- =E2=80=9C The receiver may want to have a sliding window to retain old = SRTP
   Master Keys (and related context) for some brief period of = time, so
   that out of order packets can be processed as well as = packets sent
   during the time keys are changing.=E2=80=9D

See comment to =C2=A74.2.2, step 6. =E2=80=9Cmay want=E2=80=9D seems = weak given that the sender SHOULD keep using the old key for a period of = time.

Revised this as noted above, though note that MAY WISH TO is = defined in RFC 6919.

Sure, put a normative reference to RFC 6919 in = there. The resulting downref discussion on the telechat should be fun. = ;-)


 
=C2=A74.7: =E2=80=9CA new sender SHOULD send a packet containing the = FullEKTField as soon as possible...=E2=80=9D

Why not MUST? Would it ever make sense not to do this? It seems like the = mechanism doesn=E2=80=99t work very well otherwise.

How would you comply with a "MUST ... as soon as = possible"?  I don't think we want to dictate a schedule here, but = I've added a note that packet loss can result if you don=E2=80=99t.

I note that =E2=80=9CSHOULD ... as soon as = possible=E2=80=9D has somewhat the same issue. But adding the note = addresses my concern.

[...]

 
*** Editorial Comments: ***
[...]


 
- Step 6: s/crypto/cryptographic

Disagree.
=
Really? I=E2=80=99m not going to push the = point, but I=E2=80=99m curious why? Especially since the financial = industry is doing it=E2=80=99s best to steal =E2=80=9Ccrypto=E2=80=9D. = But now I wonder if I=E2=80=99ve missed some subtle difference of = definition.

[...]

= --Apple-Mail=_B7E57D56-26A6-4C96-85DA-D3C7F8882AAB-- --Apple-Mail=_3C0FD83D-162D-4D49-9E03-D70F94781B83 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlvFHLgACgkQgFZKbJXz 1A259g//eX2U6rMQYKhZ+GRMB7BGePgQimzq7xeBA40C75Z5kX+ZEKhT92aO8mk5 AsOqiOj255KXNQqbknPuVP90s9uRIUL5Qqf+CJ7vWgJbldNj28McPRu3afrZwleG tn25t3t+ylLjT07i9UpMH6TgD5Z3nOve6pAhqVGygStNKlgAVDol4hbyF6UsU8pA gXmXSw/Ehznb5z0xwPtxYV6Q0jT76i+tJOxIfOSn2j5uX5C16U6fsHNLsnbEG7jC tiuSTiP2UOHAFn2ed8wH1MFyj8OsOWnQEDjynvn5VccTvJ3CWt9uBhDEcSQQc2DN MEI7qaBvdnrwu1X+VfwgxwIppm2Kj30lWZy4CGcYQ6dCUv+AkHUOuOdMVF5vmO1a saeeUhhhUb7tQCgWxwxucR/mmKmtX1ljzETHWDCWYgZLYC8uLYRSZo9ZaPNP2fM5 nemUfiuORW2zCUUWQOGGkNCX3AmBa0jKytgXgiaSuIAxJY/LVCs9SmpUUU/E8u5O 6+V1eQSBkE1LVZwuMK/1AmTK4bqszYn8wjKyU5KiDcEu0bvHsiYXFsCI7AAgBBJU mfAbpMYFAjQifSC7S2xucacLQchwi2qOBL3GNN/jNYdxnNsWNWP7ydghUN4mS/6+ bNZdSrdg9+Bj/8RCrG+5I6JHcPX2cyS86+W7L2TnHWm3EEKq4iw= =3gVv -----END PGP SIGNATURE----- --Apple-Mail=_3C0FD83D-162D-4D49-9E03-D70F94781B83-- From nobody Mon Oct 15 16:04:35 2018 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696B3130E25; Mon, 15 Oct 2018 16:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 MIYxcGZJXr5J; Mon, 15 Oct 2018 16:04:30 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 88A0B120072; Mon, 15 Oct 2018 16:04:30 -0700 (PDT) Received: from [10.0.1.27] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w9FN4Tnq087958 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 15 Oct 2018 18:04:29 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.27] From: Ben Campbell Message-Id: <2AA700F6-A875-469B-8CAF-698930BC3914@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_4494432F-7845-425A-9F17-C115F425543A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Mon, 15 Oct 2018 18:04:28 -0500 In-Reply-To: Cc: perc@ietf.org, draft-ietf-perc-double.all@ietf.org To: Richard Barnes References: <5AFC524E-7C2A-4C8F-B66B-7BAA3F048403@nostrum.com> <095B6E4D-B6DF-4AE9-9853-1D0F87510A14@nostrum.com> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [Perc] AD Evaluation of draft-ietf-perc-double-09 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 23:04:34 -0000 --Apple-Mail=_4494432F-7845-425A-9F17-C115F425543A Content-Type: multipart/alternative; boundary="Apple-Mail=_A07D6A92-0EF5-46F8-819D-2E1346624F91" --Apple-Mail=_A07D6A92-0EF5-46F8-819D-2E1346624F91 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Works for me. The framework draft review is in my queue for tomorrow. Thanks! Ben. > On Oct 15, 2018, at 5:42 PM, Richard Barnes wrote: >=20 > I would propose we put forward all three documents together. = (-double, -ekt-diet, and -framework) They'll be more comprehensible to = the ADs that way. >=20 > On Mon, Oct 15, 2018 at 6:40 PM Ben Campbell > wrote: > Thanks, the PR looks good to me. Please submit a revision when you are = ready. >=20 > I think that, with the PR applied, it will be ready for IETF LC. That = should probably be done in tandem with the media framework (in my queue = to review in the next couple of days. Authors and chairs: do you think = we should also coordinate with ekt-diet? >=20 > Thanks! >=20 > Ben. >=20 >=20 >> On Oct 5, 2018, at 9:48 AM, Richard Barnes > wrote: >>=20 >> Hey Ben, >>=20 >> After talking with Cullen, I am now the stuckee for this. I've filed = a PR at: >>=20 >> https://github.com/ietf/perc-wg/pull/160 = >>=20 >> Comments inline below. >>=20 >> On Tue, Jun 5, 2018 at 12:40 AM Ben Campbell > wrote: >> Hi, >>=20 >> This is my AD Evaluation of draft-ietf-perc-double-09. Thanks for = this work; I think it is important and on the right track, but suffers = from some readability issues, especially from =C2=A77 onwards. I=E2=80=99d= like to discuss my comments prior to IETF last call. >>=20 >> Thanks! >>=20 >> Ben. >>=20 >> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94 >>=20 >> *** Substantive Comments *** >>=20 >> General: Does it make sense to progress this prior to = draft-ietf-perc-private-media-framework rather than wait and progress = them together? it seems like one really needs to read the framework to = understand at least parts of this draft. (Which would, btw, suggest = making the framework a normative reference.) >>=20 >> I think at this point, -framework has caught up a bit (I understand = it's awaiting your review), so this seems OBE. I agree that it will = make easier reading for ADs to read the three docs (this, framework, and = EKT) on the same telechat. >>=20 >>=20 >> =C2=A72, Media Distributor: Should this be defined as switch-based? = Otherwise it seems circular. >>=20 >> I've copied down the definition =C2=A71, which explicitly says that = the MD does not need to interpret or change media content. Also added a = ref to -framework at this point. >>=20 >>=20 >> =C2=A75 and subsections: These sections are confusing in the = treatment of extensions. =C2=A75.1 step 3 says to truncate the header to = remove any extensions. Yet other sections of text repeatedly mention the = handling of extensions. I think the document needs a paragraph or two to = describe the handling of RTP extensions at a high level. >>=20 >> I've added an overview of the transform, including thoughts on = extensions, to the top of =C2=A75. >>=20 >>=20 >> Along those lines, it=E2=80=99s not entirely clear what is meant by = putting =E2=80=9C (12 + 4 * CC bytes)=E2=80=9D in parentheses after the = guidance to truncate in =C2=A75.1. Is that the amount to be truncated? = Amount left after truncation? (Same question for =C2=A75.3) >>=20 >> Clarified that this is the amount left after truncation, i.e., take = the first N bytes, in both places. >>=20 >>=20 >> =C2=A75.2: It would be helpful to include a paragraph or two to = describe the impact if multiple MDs modify the same field(s). I can = infer that, but it would be better to be explicit. (IIRC, there is a = passing mention in the security considerations, but it would be better = to have more here.) >>=20 >> Added a paragraph. >>=20 >>=20 >> =C2=A78: Can you offer any guidance about selecting 128 vs 256? >>=20 >> I don't really think there's much to say here; it's up to the user of = the transform. Use 128 unless you're paranoid, then use 256? :) Note = that RFC 7714, which defines the AES-GCM transforms, does not provide = similar guidance. >>=20 >>=20 >> =C2=A79: >>=20 >> - The security considerations mainly summarize the mechanism. I=E2=80=99= d like to see a description of the potential attacks or risks and how = the double mechanism mitigates them. >> - =E2=80=9C=E2=80=A6 this shouldn=E2=80=99t typically impact the = strength of e2e integrity given the fact that there doesn=E2=80=99t = exist header extensions defined today that needs e2e protection. = However, if future specifications define header extensions that needs = e2e integrity protection, the input to inner transform may be modified = to consider including the header.=E2=80=9D >>=20 >> - 2nd paragraph: Why is the HBH key for an outgoing packet only = =E2=80=9Ctypically=E2=80=9D different than the key for the incoming = packet? Are there security implications if they are the same? >>=20 >> - 2nd to last paragraph, last sentence: Please elaborate on those = risks? >>=20 >> I agree with your assessment that the existing security = considerations were not that useful. I've replaced them with an = analysis that's more focused on what protections are provided with = respect to which attackers. >>=20 >> The new version also calls out clearly that when a packet is = re-encrypted, the outer keys MUST be different. >>=20 >>=20 >> *** Editorial comments and nits *** >>=20 >> There are a number of abbreviations that need to be expanded on first = use. Please remember that abbreviations should be expanded both in the = abstract and the body. >>=20 >> - SRTP >> - SSRC >> - SEQ >> - ROC >> - PRF >> - PT >> - SEQ >> - RTX >> - RED >> - FEC >>=20 >> I've expanded most of these. I have left SSRC, SEQ, ROC, and PT, = since in this context, they are basically opaque labels for RTP header = fields. >>=20 >>=20 >> =C2=A72: >> - Please use the boilerplate from RFC8174. There are a number of = lower case instances of normative keywords. >>=20 >> Done. >>=20 >> - Please use consistent sentence (or lack of sentence) structure for = the definitions in the bullet list. >>=20 >> Done. >>=20 >> =C2=A73, >>=20 >> - " Generate key and salt values of the length required for the = combined inner (end-to-end) and outer (hop-by-hop) algorithms.=E2=80=9D: = The document is inconsistent in whether it describes a single key with = inner and outer halves, or separate inner and outer keys. I realize that = this is an artifact of syntax, but it is likely to confuse a reader new = to the topic. >>=20 >> The very next bullet says to glue them together. Not sure how else = to say this. >>=20 >> - Paragraph starting with =E2=80=9CObviously, if the Media = Distributor=E2=80=A6=E2=80=9D: =E2=80=9CObviously=E2=80=9D is a null = word in context. >>=20 >> Deleted. >>=20 >> =C2=A73.1: This section would be much more approachable if you = defined the terms (such as n, k, and x), rather than forcing readers to = look them up in 3711. Also, the doubled crypto suite IDs are likely to = be confusing to the reader who sees them here without the explanation = later in the draft. >>=20 >> Done. >>=20 >> =C2=A75.2, step 2: =E2=80=9CChange any parts of the RTP packet=E2=80=A6= =E2=80=9D -The MS is limited to changing the 3 fields defined for the = OHB, right, at least as defined in this draft? Not just anything it = wants? >>=20 >> Correct. Done. >>=20 >> =C2=A75.3, last two paragraphs: It=E2=80=99s sort of an odd = construction to talk about =E2=80=9Cany of the following=E2=80=9D with a = single entry list.. >>=20 >> Revised to clarify. >>=20 >> =C2=A77 and subsections: These could use another proofreading pass. = In particular, it is imprecise about inner vs outer encryption, which = actors do what, and has a number of pronouns with ambiguous antecedents. = The heavy use of passive voice obscures the actors in multiple places. I = will call out some specifics, but please do not treat my comments as = exhaustive. >>=20 >> Did a revision pass, let me know what you think. >>=20 >> =C2=A77: =E2=80=9C The repair mechanism, when used with double, = typically operates on the double encrypted data and encrypts >> them using only the HBH key.=E2=80=9D Does =E2=80=9Cdouble = encrypted=E2=80=9D mean =E2=80=9Couter encrypted=E2=80=9D? Also, while I = recognize =E2=80=9Cdata=E2=80=9D as plural, it=E2=80=99s plural in a = non-countable sense; that is, s / them / it. >>=20 >> =C2=A77.1: >> - =E2=80=9C =E2=80=A6 cached payloads MUST be the encrypted packets = =E2=80=A6=E2=80=9D - Inner or outer? What device enforces this? = (Consider active voice.) >> - Which element represents =E2=80=9Cthe other side=E2=80=9D? Are we = talking about an endpoint or MD? (Please stick to the defined = terminology) >> - =E2=80=9C When encrypting a retransmission packet, it MUST be = encrypted the packet in repair mode.=E2=80=9D - I can=E2=80=99t parse = the phrase after the comma. Also, what device MUST encrypt it? >>=20 >> =C2=A77.2: >> - =E2=80=9Cthe primary encoding MAY contain=E2=80=A6=E2=80=9D - Is = that MAY a grant of permission or a statement of fact? >>=20 >> - " The sender takes encrypted payload from the cached packets=E2=80=9D= - Missing article for encrypted payload? Or should this say =E2=80=9C=E2=80= =A6 takes encrypted packets from the cached payload=E2=80=A6=E2=80=9D? >>=20 >> - =E2=80=9C Any header extensions from the primary encoding are = copied to the RTP packet that will carry the RED payload and the other = RTP header information such as SSRC, SEQ, CSRC, etc are set to the same = as the primary payload. The RED RTP packet is then encrypted in repair = mode and sent.=E2=80=9D: This is confusing; parts are copied from the = primary encoding and others are the same as in the primary encoding? = Don=E2=80=99t both of those mean the same thing? >>=20 >> - =E2=80=9C The receiver decrypts the payload=E2=80=A6=E2=80=9D: = Endpoint or MD? Is this inner or outer encryption? >>=20 >> - Last paragraph: Seems like that belongs in the FEC section. Also, = does this document really need to make that sort of recommendation? It = seems like a general statement about RED and FEC that is not specific to = double. >>=20 >>=20 >> =C2=A77.3: >>=20 >> - "When using Flex FEC [I-D.ietf-payload-flexible-fec-scheme] with = double, the negotiation of double for the crypto is the out of band = signaling that indicates that the repair packets MUST use the order of = operations of SRTP followed by FEC when encrypting.=E2=80=9D - The = sentence is hard to parse. Also, is MUST a normative requirement or a = statement of fact? (It seems odd to signal that you MUST do something). >> - =E2=80=9C=E2=80=A6 data, which is already encrypted, it MUST be = encrypted in repair mode packet.=E2=80=9D s/ =E2=80=9C, which=E2=80=9D / = =E2=80=9Cthat=E2=80=9D. Also, what actor MUST encrypt the data in repair = mode? (Consider active voice.) >>=20 >> - =E2=80=9C The algorithm recommend=E2=80=A6=E2=80=9D s / recommend / = recommended >>=20 >> Done. >>=20 >> =C2=A77.4: >> - s/ "sent with [RFC4733]=E2=80=9D / =E2=80=9Csent using the = mechanism in [RFC4733]=E2=80=9D >> - =E2=80=9C and the relay can not read it so it cannot be used=E2=80=9D= - missing comma between =E2=80=9Cit=E2=80=9D and =E2=80=9Cso=E2=80=9D. >>=20 >> Done. >>=20 >> =C2=A78, last paragraph: =E2=80=9C For packets in repair mode, the = data they are caring is often already encrypted further increasing the = size.=E2=80=9D - I assume =E2=80=9Ccaring=E2=80=9D is not the intended = word. Did you mean =E2=80=9Ccarrying=E2=80=9D? If so, consider s / = =E2=80=9Cdata they are carrying=E2=80=9D / =E2=80=9Cdata they carry=E2=80=9D= >>=20 >> Revised. >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc = >=20 --Apple-Mail=_A07D6A92-0EF5-46F8-819D-2E1346624F91 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Works= for me. The framework draft review is in my queue for tomorrow.

Thanks!

Ben.

On Oct 15, 2018, at 5:42 PM, Richard Barnes <rlb@ipv.sx> wrote:

I would propose we put forward all three documents = together.  (-double, -ekt-diet, and -framework)  They'll be = more comprehensible to the ADs that way.

On = Mon, Oct 15, 2018 at 6:40 PM Ben Campbell <ben@nostrum.com> = wrote:
Thanks, the PR looks good to me. Please submit a revision = when you are ready.

I = think that, with the PR applied, it will be ready for IETF LC.  = That should probably be done in tandem with the media framework (in my = queue to review in the next couple of days. Authors and chairs: do you = think we should also coordinate with ekt-diet?

Thanks!

Ben.


On Oct = 5, 2018, at 9:48 AM, Richard Barnes <rlb@ipv.sx> wrote:

Hey Ben,

After talking with Cullen, I am now the stuckee for = this.  I've filed a PR at:

https://github.com/ietf/perc-wg/pull/160

Comments inline = below.

On Tue, Jun 5, 2018 at = 12:40 AM Ben Campbell <ben@nostrum.com> wrote:
Hi,

This is my AD Evaluation of draft-ietf-perc-double-09. Thanks for this = work; I think it is important and on the right track, but suffers from = some readability issues, especially from =C2=A77 onwards. I=E2=80=99d = like to discuss my comments prior to IETF last call.

Thanks!

Ben.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94

*** Substantive Comments ***

General: Does it make sense to progress this prior to = draft-ietf-perc-private-media-framework rather than wait and progress = them together? it seems like one really needs to read the framework to = understand at least parts of this draft. (Which would, btw, suggest = making the framework a normative reference.)

I think at this point, -framework has caught up a bit (I = understand it's awaiting your review), so this seems OBE.  I agree = that it will make easier reading for ADs to read the three docs (this, = framework, and EKT) on the same telechat.

 
=C2=A72, Media Distributor: Should this be defined as switch-based? = Otherwise it seems circular.

I've copied down the = definition =C2=A71, which explicitly says that the MD does not need to = interpret or change media content.  Also added a ref to -framework = at this point.

 
=C2=A75 and subsections: These sections are confusing in the treatment = of extensions. =C2=A75.1 step 3 says to truncate the header to remove = any extensions. Yet other sections of text repeatedly mention the = handling of extensions. I think the document needs a paragraph or two to = describe the handling of RTP extensions at a high level.

I've added an overview of the transform, including thoughts = on extensions, to the top of =C2=A75.
 
 
Along those lines, it=E2=80=99s not entirely clear what is meant by = putting =E2=80=9C (12 + 4 * CC bytes)=E2=80=9D in parentheses after the = guidance to truncate in =C2=A75.1. Is that the amount to be truncated? = Amount left after truncation? (Same question for =C2=A75.3)

Clarified that this is the amount left after truncation, = i.e., take the first N bytes, in both places.

 
=C2=A75.2: It would be helpful to include a paragraph or two to describe = the impact if multiple MDs modify the same field(s). I can infer that, = but it would be better to be explicit. (IIRC, there is a passing mention = in the security considerations, but it would be better to have more = here.)

Added a paragraph.

 
=C2=A78: Can you offer any guidance about selecting 128 vs 256?

I don't really think there's much to say here; it's up to the = user of the transform.  Use 128 unless you're paranoid, then use = 256?  :)  Note that RFC 7714, which defines the AES-GCM = transforms, does not provide similar guidance.

 
=C2=A79:

- The security considerations mainly summarize the mechanism. I=E2=80=99d = like to see a description of the potential attacks or risks  and = how the double mechanism mitigates them.
- =E2=80=9C=E2=80=A6 this shouldn=E2=80=99t typically impact the = strength of e2e integrity given the fact that there doesn=E2=80=99t = exist header extensions defined today that needs e2e protection.  = However, if future specifications define header extensions that needs = e2e integrity protection, the input to inner transform may be modified = to consider including the header.=E2=80=9D

- 2nd paragraph: Why is the HBH key for an outgoing packet only = =E2=80=9Ctypically=E2=80=9D different than the key for the incoming = packet? Are there security implications if they are the same?

- 2nd to last paragraph, last sentence: Please elaborate on those = risks?

I agree with your assessment that the = existing security considerations were not that useful.  I've = replaced them with an analysis that's more focused on what protections = are provided with respect to which attackers. 

The = new version also calls out clearly that when a packet is re-encrypted, = the outer keys MUST be different.

 
*** Editorial comments and nits ***

There are a number of abbreviations that need to be expanded on first = use. Please remember that abbreviations should be expanded both in the = abstract and the body.

- SRTP
- SSRC
- SEQ
- ROC
- PRF
- PT
- SEQ
- RTX
- RED
- FEC

I've expanded most of these.  I have left SSRC, SEQ, = ROC, and PT, since in this context, they are basically opaque labels for = RTP header fields. 

 
=C2=A72:
- Please use the boilerplate from RFC8174. There are a number of lower = case instances of normative keywords.

Done.
 
- Please use consistent sentence (or lack of sentence) structure for the = definitions in the bullet list.

Done.
 
=C2=A73,

- " Generate key and salt values of the length required for the combined = inner (end-to-end) and outer (hop-by-hop) algorithms.=E2=80=9D: The = document is inconsistent in whether it describes a single key with inner = and outer halves, or separate inner and outer keys. I realize that this = is an artifact of syntax, but it is likely to confuse a reader new to = the topic.

The very next bullet says to glue them = together.  Not sure how else to say this.
 
- Paragraph starting with =E2=80=9CObviously, if the Media = Distributor=E2=80=A6=E2=80=9D: =E2=80=9CObviously=E2=80=9D is a null = word in context.

Deleted.
 
=C2=A73.1: This section would be much more approachable if you defined = the terms (such as n, k, and x), rather than forcing readers to look = them up in 3711. Also, the doubled crypto suite IDs are likely to be = confusing to the reader who sees them here without the explanation later = in the draft.

Done.
 
=C2=A75.2, step 2: =E2=80=9CChange any parts of the RTP packet=E2=80=A6=E2= =80=9D -The MS is limited to changing the 3 fields defined for the OHB, = right, at least as defined in this draft? Not just anything it wants?

Correct.  Done.
 
=C2=A75.3, last two paragraphs: It=E2=80=99s sort of an odd construction = to talk about =E2=80=9Cany of the following=E2=80=9D with a single entry = list..

Revised to clarify.
 
=C2=A77 and subsections: These could use another proofreading pass. In = particular, it is imprecise about inner vs outer encryption, which = actors do what, and has a number of pronouns with ambiguous antecedents. = The heavy use of passive voice obscures the actors in multiple places. I = will call out some specifics, but please do not treat my comments as = exhaustive.

Did a revision pass, let me know what = you think.
 
=C2=A77: =E2=80=9C The repair mechanism, when used with double, = typically operates on the double encrypted data and encrypts
   them using only the HBH key.=E2=80=9D Does =E2=80=9Cdouble = encrypted=E2=80=9D mean =E2=80=9Couter encrypted=E2=80=9D? Also, while I = recognize =E2=80=9Cdata=E2=80=9D as plural, it=E2=80=99s plural in a = non-countable sense; that is, s / them / it.

=C2=A77.1:
- =E2=80=9C =E2=80=A6 cached payloads MUST be the encrypted packets = =E2=80=A6=E2=80=9D - Inner or outer? What device enforces this? = (Consider active voice.)
- Which element represents =E2=80=9Cthe other side=E2=80=9D? Are we = talking about an endpoint or MD? (Please stick to the defined = terminology)
- =E2=80=9C When encrypting a retransmission packet, it MUST be = encrypted the packet in repair mode.=E2=80=9D - I can=E2=80=99t parse = the phrase after the comma. Also, what device MUST encrypt it?

=C2=A77.2:
- =E2=80=9Cthe primary encoding MAY contain=E2=80=A6=E2=80=9D - Is that = MAY a grant of permission or a statement of fact?

- " The sender takes encrypted payload from the cached packets=E2=80=9D- = Missing article for encrypted payload? Or should this say =E2=80=9C=E2=80=A6= takes encrypted packets from the cached payload=E2=80=A6=E2=80=9D?

- =E2=80=9C Any header extensions from the primary encoding are copied = to the RTP packet that will carry the RED payload and the other RTP = header information such as SSRC, SEQ, CSRC, etc are set to the same as = the primary payload.  The RED RTP packet is then encrypted in = repair mode and sent.=E2=80=9D: This is confusing; parts are copied from = the primary encoding and others are the same as in the primary encoding? = Don=E2=80=99t both of those mean the same thing?

- =E2=80=9C The receiver decrypts the payload=E2=80=A6=E2=80=9D: = Endpoint or MD? Is this inner or outer encryption?

- Last paragraph: Seems like that belongs in the FEC section. Also, does = this document really need to make that sort of recommendation? It seems = like a general statement about RED and FEC that is not specific to = double.


=C2=A77.3:

- "When using Flex FEC [I-D.ietf-payload-flexible-fec-scheme] with = double, the negotiation of double for the crypto is the out of band = signaling that indicates that the repair packets MUST use the order of = operations of SRTP followed by FEC when encrypting.=E2=80=9D - The = sentence is hard to parse. Also, is MUST a normative requirement or a = statement of fact? (It seems odd to signal that you MUST do = something).
- =E2=80=9C=E2=80=A6  data, which is already encrypted, it MUST be = encrypted in repair mode packet.=E2=80=9D s/ =E2=80=9C, which=E2=80=9D / = =E2=80=9Cthat=E2=80=9D. Also, what actor MUST encrypt the data in repair = mode? (Consider active voice.)

- =E2=80=9C The algorithm recommend=E2=80=A6=E2=80=9D s / recommend / = recommended

Done.
 
=C2=A77.4:
- s/ "sent with [RFC4733]=E2=80=9D / =E2=80=9Csent using the mechanism = in [RFC4733]=E2=80=9D
- =E2=80=9C and the relay can not read it so it cannot be used=E2=80=9D = - missing comma between =E2=80=9Cit=E2=80=9D and =E2=80=9Cso=E2=80=9D.

Done.
 
=C2=A78, last paragraph: =E2=80=9C For packets in repair mode, the data = they are caring is often already encrypted further increasing the = size.=E2=80=9D - I assume =E2=80=9Ccaring=E2=80=9D is not the intended = word. Did you mean =E2=80=9Ccarrying=E2=80=9D? If so, consider s / = =E2=80=9Cdata they are carrying=E2=80=9D / =E2=80=9Cdata they = carry=E2=80=9D

Revised.
_______________________________________________
Perc = mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc


= --Apple-Mail=_A07D6A92-0EF5-46F8-819D-2E1346624F91-- --Apple-Mail=_4494432F-7845-425A-9F17-C115F425543A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlvFHPwACgkQgFZKbJXz 1A139w//ZDEeuRZxcqMaMIF+X4kBF+oErKio5HGKDAwUyA5MNaMYJguO/8/TXcc0 JAT9c1sJZ/O88GWjC4y/G/fh4S1n4YLgS7GMVbmWI1wZh2MPVVi8eXbk+Xl4GcB8 qJcbc33f2tP6+XcmjQAfVyNV2Wu42wF42OZcaaZyXkeasVsyKa/aXL+LwpYV22So ryNluo6lF3PsApLGabXJZkLzlWSBB9T+rAt2j8SubP4m4fxudTFJ3iw7R1b0ouBc hR5F9tccDW53uwaoW6Q9Mk2LC9akOj9nbFTErG9ROyZpp/KUK8bsEKmhAxjuq1eR A9P9Bb8XcA+GGLnmZh8W96jW0XyyghDHv03EJ2PYp+MZIwg170TnsJhrB9RhPkQH cAohnHpsZq7Tgz8T5gcPBngUZnSaIuHz89XLDmHmulxrl5mR0IeZgWns5NC2Gz7T d0rFmKO8buK3tkdtk7BDxUCHonw7kaTzHBHoWyJV7mtKhrficf7Tkk9DDG+Eh/6x uNwuLqMhe/Q2UNTfa0o8FbsugZPkEfxavCZ+kPJhZQ2nXfa941Xr7CKTNfXLq8sf dAFKGwpADx5ugsyWH0GORZwo3MLCBL8di3D3fGZwN+oenxM/VTLSSnVFSmTDLWFu KnpRpc66pfHacz2XjNWwWrygsdyHWHYLq+JQUSvw0PeYlF4Q1H0= =urYU -----END PGP SIGNATURE----- --Apple-Mail=_4494432F-7845-425A-9F17-C115F425543A-- From nobody Mon Oct 15 17:41:04 2018 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBD8127333 for ; Mon, 15 Oct 2018 17:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 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] autolearn=ham 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 XfVurcMX-ZOd for ; Mon, 15 Oct 2018 17:40:59 -0700 (PDT) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 0534E126F72 for ; Mon, 15 Oct 2018 17:40:58 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id o14so20810289oth.4 for ; Mon, 15 Oct 2018 17:40:58 -0700 (PDT) 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=AKJbCVVekGJ/gf84LFp07XqFAhYZvPVMqIRua52+wPo=; b=fBaBK3qytsj1pldAUkQJEI5xXmJC1F2hOeQQ1OjQenZPj9vltO2AhP4HAQ6Q+a9sJX 3+B4imnGO4yw/K9lPf+v7/k8g8/bQ0UCDXOMuwzTAmGjphVZbmAzvO246+LCHzyD5nmp l6XNlKSQXDWMFb10oQY8sd4xhGj6tvktPMO4HkUTOWXcua6e1KJBnzuD14LM7NrGxfEl 7RypTBMtGagei4Chx0LCiR/qJkMi3e5WmPaWZpY/lK/CvQJsCgQt8EWKALWvAfCuVhF7 5DD959XSF5VOvQADW79HW1YVjzzPeOiiBNnTecWpzA0LG+EZ61zcs54f8z4EA3MSE8i/ jaZA== 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=AKJbCVVekGJ/gf84LFp07XqFAhYZvPVMqIRua52+wPo=; b=W0MfnSod4WKg6WapfF1M95Y+hULvn6la67qQtsd6A0j2i6g6qjaMZyeqD72oV+z1Ti PFntYSKgPu4tC1KHncaTDjif+Jnr9HrkunSTdcBz/Z4rhiXozgm1sInpI0s76N6N2KRH adH918Tp2vRg4V7VDQsC56PgQ12rp0jLSsaSvxMoA5vYwRlsHQZOX4SuMZ1IyjHv11SD Z9Y2Jqpwqaofvf75d6h0rbu2bIrv2nHKGT99crthUOzCqNmokU1MMpg0MUuwLsBixoNe JvZ3E9dLUfSVLrQocIr77oylOr3vGVlB9UD623zYezFz5pLkGym7XBFMby7tyeYtUk3M /Ykg== X-Gm-Message-State: ABuFfohCIiMP7tTvH1sz3ohmIJEMq2yUzlu6f/WVW4ux0tC9ePK8SmWI WbkzOqYIMFUwf74Y/BpgEQPFBs5tvAa63Ximscl6vMJMvg8= X-Google-Smtp-Source: ACcGV61ZBsi8JAoGTBiO1s6VK87K7OuPLiZGOOz8itesLtzju9Ix+rpYPihByGgI0uF3V69VBU6GviubCglyd/v/Oog= X-Received: by 2002:a9d:49a9:: with SMTP id g41mr13502534otf.162.1539650458070; Mon, 15 Oct 2018 17:40:58 -0700 (PDT) MIME-Version: 1.0 References: <5AFC524E-7C2A-4C8F-B66B-7BAA3F048403@nostrum.com> <095B6E4D-B6DF-4AE9-9853-1D0F87510A14@nostrum.com> <2AA700F6-A875-469B-8CAF-698930BC3914@nostrum.com> In-Reply-To: <2AA700F6-A875-469B-8CAF-698930BC3914@nostrum.com> From: Richard Barnes Date: Mon, 15 Oct 2018 20:40:39 -0400 Message-ID: To: Ben Campbell Cc: perc@ietf.org, draft-ietf-perc-double.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000a1c44605784dceca" Archived-At: Subject: Re: [Perc] AD Evaluation of draft-ietf-perc-double-09 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 00:41:03 -0000 --000000000000a1c44605784dceca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Oh actually, let's not worry about synchronizing now. I'm OK to send these to IETF LC separately; I just think they should all be on the same IESG telechat. I'll push a new version of this tomorrow, and EKT as soon as I can find a responsive author. --Richard On Mon, Oct 15, 2018 at 7:04 PM Ben Campbell wrote: > Works for me. The framework draft review is in my queue for tomorrow. > > Thanks! > > Ben. > > On Oct 15, 2018, at 5:42 PM, Richard Barnes wrote: > > I would propose we put forward all three documents together. (-double, > -ekt-diet, and -framework) They'll be more comprehensible to the ADs tha= t > way. > > On Mon, Oct 15, 2018 at 6:40 PM Ben Campbell wrote: > >> Thanks, the PR looks good to me. Please submit a revision when you are >> ready. >> >> I think that, with the PR applied, it will be ready for IETF LC. That >> should probably be done in tandem with the media framework (in my queue = to >> review in the next couple of days. Authors and chairs: do you think we >> should also coordinate with ekt-diet? >> >> Thanks! >> >> Ben. >> >> >> On Oct 5, 2018, at 9:48 AM, Richard Barnes wrote: >> >> Hey Ben, >> >> After talking with Cullen, I am now the stuckee for this. I've filed a >> PR at: >> >> https://github.com/ietf/perc-wg/pull/160 >> >> Comments inline below. >> >> On Tue, Jun 5, 2018 at 12:40 AM Ben Campbell wrote: >> >>> Hi, >>> >>> This is my AD Evaluation of draft-ietf-perc-double-09. Thanks for this >>> work; I think it is important and on the right track, but suffers from = some >>> readability issues, especially from =C2=A77 onwards. I=E2=80=99d like t= o discuss my >>> comments prior to IETF last call. >>> >>> Thanks! >>> >>> Ben. >>> >>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94 >>> >>> *** Substantive Comments *** >>> >>> General: Does it make sense to progress this prior to >>> draft-ietf-perc-private-media-framework rather than wait and progress t= hem >>> together? it seems like one really needs to read the framework to >>> understand at least parts of this draft. (Which would, btw, suggest mak= ing >>> the framework a normative reference.) >>> >> >> I think at this point, -framework has caught up a bit (I understand it's >> awaiting your review), so this seems OBE. I agree that it will make eas= ier >> reading for ADs to read the three docs (this, framework, and EKT) on the >> same telechat. >> >> >> >>> =C2=A72, Media Distributor: Should this be defined as switch-based? Oth= erwise >>> it seems circular. >>> >> >> I've copied down the definition =C2=A71, which explicitly says that the = MD >> does not need to interpret or change media content. Also added a ref to >> -framework at this point. >> >> >> >>> =C2=A75 and subsections: These sections are confusing in the treatment = of >>> extensions. =C2=A75.1 step 3 says to truncate the header to remove any >>> extensions. Yet other sections of text repeatedly mention the handling = of >>> extensions. I think the document needs a paragraph or two to describe t= he >>> handling of RTP extensions at a high level. >>> >> >> I've added an overview of the transform, including thoughts on >> extensions, to the top of =C2=A75. >> >> >> >>> Along those lines, it=E2=80=99s not entirely clear what is meant by put= ting =E2=80=9C >>> (12 + 4 * CC bytes)=E2=80=9D in parentheses after the guidance to trunc= ate in =C2=A75.1. >>> Is that the amount to be truncated? Amount left after truncation? (Same >>> question for =C2=A75.3) >>> >> >> Clarified that this is the amount left after truncation, i.e., take the >> first N bytes, in both places. >> >> >> >>> =C2=A75.2: It would be helpful to include a paragraph or two to describ= e the >>> impact if multiple MDs modify the same field(s). I can infer that, but = it >>> would be better to be explicit. (IIRC, there is a passing mention in th= e >>> security considerations, but it would be better to have more here.) >>> >> >> Added a paragraph. >> >> >> >>> =C2=A78: Can you offer any guidance about selecting 128 vs 256? >>> >> >> I don't really think there's much to say here; it's up to the user of th= e >> transform. Use 128 unless you're paranoid, then use 256? :) Note that >> RFC 7714, which defines the AES-GCM transforms, does not provide similar >> guidance. >> >> >> >>> =C2=A79: >>> >>> - The security considerations mainly summarize the mechanism. I=E2=80= =99d like >>> to see a description of the potential attacks or risks and how the dou= ble >>> mechanism mitigates them. >>> - =E2=80=9C=E2=80=A6 this shouldn=E2=80=99t typically impact the streng= th of e2e integrity given >>> the fact that there doesn=E2=80=99t exist header extensions defined tod= ay that >>> needs e2e protection. However, if future specifications define header >>> extensions that needs e2e integrity protection, the input to inner >>> transform may be modified to consider including the header.=E2=80=9D >>> >>> - 2nd paragraph: Why is the HBH key for an outgoing packet only >>> =E2=80=9Ctypically=E2=80=9D different than the key for the incoming pac= ket? Are there >>> security implications if they are the same? >>> >>> - 2nd to last paragraph, last sentence: Please elaborate on those risks= ? >>> >> >> I agree with your assessment that the existing security considerations >> were not that useful. I've replaced them with an analysis that's more >> focused on what protections are provided with respect to which attackers= . >> >> The new version also calls out clearly that when a packet is >> re-encrypted, the outer keys MUST be different. >> >> >> >>> *** Editorial comments and nits *** >>> >>> There are a number of abbreviations that need to be expanded on first >>> use. Please remember that abbreviations should be expanded both in the >>> abstract and the body. >>> >>> - SRTP >>> - SSRC >>> - SEQ >>> - ROC >>> - PRF >>> - PT >>> - SEQ >>> - RTX >>> - RED >>> - FEC >>> >> >> I've expanded most of these. I have left SSRC, SEQ, ROC, and PT, since >> in this context, they are basically opaque labels for RTP header fields. >> >> >> >>> =C2=A72: >>> - Please use the boilerplate from RFC8174. There are a number of lower >>> case instances of normative keywords. >>> >> >> Done. >> >> >>> - Please use consistent sentence (or lack of sentence) structure for th= e >>> definitions in the bullet list. >>> >> >> Done. >> >> >>> =C2=A73, >>> >>> - " Generate key and salt values of the length required for the combine= d >>> inner (end-to-end) and outer (hop-by-hop) algorithms.=E2=80=9D: The doc= ument is >>> inconsistent in whether it describes a single key with inner and outer >>> halves, or separate inner and outer keys. I realize that this is an >>> artifact of syntax, but it is likely to confuse a reader new to the top= ic. >>> >> >> The very next bullet says to glue them together. Not sure how else to >> say this. >> >> >>> - Paragraph starting with =E2=80=9CObviously, if the Media Distributor= =E2=80=A6=E2=80=9D: >>> =E2=80=9CObviously=E2=80=9D is a null word in context. >>> >> >> Deleted. >> >> >>> =C2=A73.1: This section would be much more approachable if you defined = the >>> terms (such as n, k, and x), rather than forcing readers to look them u= p in >>> 3711. Also, the doubled crypto suite IDs are likely to be confusing to = the >>> reader who sees them here without the explanation later in the draft. >>> >> >> Done. >> >> >>> =C2=A75.2, step 2: =E2=80=9CChange any parts of the RTP packet=E2=80=A6= =E2=80=9D -The MS is limited >>> to changing the 3 fields defined for the OHB, right, at least as define= d in >>> this draft? Not just anything it wants? >>> >> >> Correct. Done. >> >> >>> =C2=A75.3, last two paragraphs: It=E2=80=99s sort of an odd constructio= n to talk >>> about =E2=80=9Cany of the following=E2=80=9D with a single entry list.. >>> >> >> Revised to clarify. >> >> >>> =C2=A77 and subsections: These could use another proofreading pass. In >>> particular, it is imprecise about inner vs outer encryption, which acto= rs >>> do what, and has a number of pronouns with ambiguous antecedents. The h= eavy >>> use of passive voice obscures the actors in multiple places. I will cal= l >>> out some specifics, but please do not treat my comments as exhaustive. >>> >> >> Did a revision pass, let me know what you think. >> >> >>> =C2=A77: =E2=80=9C The repair mechanism, when used with double, typical= ly operates on >>> the double encrypted data and encrypts >>> them using only the HBH key.=E2=80=9D Does =E2=80=9Cdouble encrypted= =E2=80=9D mean =E2=80=9Couter >>> encrypted=E2=80=9D? Also, while I recognize =E2=80=9Cdata=E2=80=9D as p= lural, it=E2=80=99s plural in a >>> non-countable sense; that is, s / them / it. >>> >>> =C2=A77.1: >>> - =E2=80=9C =E2=80=A6 cached payloads MUST be the encrypted packets =E2= =80=A6=E2=80=9D - Inner or outer? >>> What device enforces this? (Consider active voice.) >>> - Which element represents =E2=80=9Cthe other side=E2=80=9D? Are we tal= king about an >>> endpoint or MD? (Please stick to the defined terminology) >>> - =E2=80=9C When encrypting a retransmission packet, it MUST be encrypt= ed the >>> packet in repair mode.=E2=80=9D - I can=E2=80=99t parse the phrase afte= r the comma. Also, >>> what device MUST encrypt it? >>> >>> =C2=A77.2: >>> - =E2=80=9Cthe primary encoding MAY contain=E2=80=A6=E2=80=9D - Is that= MAY a grant of >>> permission or a statement of fact? >>> >>> - " The sender takes encrypted payload from the cached packets=E2=80=9D= - Missing >>> article for encrypted payload? Or should this say =E2=80=9C=E2=80=A6 ta= kes encrypted >>> packets from the cached payload=E2=80=A6=E2=80=9D? >>> >>> - =E2=80=9C Any header extensions from the primary encoding are copied = to the >>> RTP packet that will carry the RED payload and the other RTP header >>> information such as SSRC, SEQ, CSRC, etc are set to the same as the pri= mary >>> payload. The RED RTP packet is then encrypted in repair mode and sent.= =E2=80=9D: >>> This is confusing; parts are copied from the primary encoding and other= s >>> are the same as in the primary encoding? Don=E2=80=99t both of those me= an the same >>> thing? >>> >>> - =E2=80=9C The receiver decrypts the payload=E2=80=A6=E2=80=9D: Endpoi= nt or MD? Is this inner >>> or outer encryption? >>> >>> - Last paragraph: Seems like that belongs in the FEC section. Also, doe= s >>> this document really need to make that sort of recommendation? It seems >>> like a general statement about RED and FEC that is not specific to doub= le. >>> >>> >>> =C2=A77.3: >>> >>> - "When using Flex FEC [I-D.ietf-payload-flexible-fec-scheme] with >>> double, the negotiation of double for the crypto is the out of band >>> signaling that indicates that the repair packets MUST use the order of >>> operations of SRTP followed by FEC when encrypting.=E2=80=9D - The sent= ence is hard >>> to parse. Also, is MUST a normative requirement or a statement of fact?= (It >>> seems odd to signal that you MUST do something). >>> >> - =E2=80=9C=E2=80=A6 data, which is already encrypted, it MUST be encry= pted in repair >>> mode packet.=E2=80=9D s/ =E2=80=9C, which=E2=80=9D / =E2=80=9Cthat=E2= =80=9D. Also, what actor MUST encrypt the data >>> in repair mode? (Consider active voice.) >>> >>> - =E2=80=9C The algorithm recommend=E2=80=A6=E2=80=9D s / recommend / r= ecommended >>> >> >> Done. >> >> >>> =C2=A77.4: >>> - s/ "sent with [RFC4733]=E2=80=9D / =E2=80=9Csent using the mechanism = in [RFC4733]=E2=80=9D >>> - =E2=80=9C and the relay can not read it so it cannot be used=E2=80=9D= - missing comma >>> between =E2=80=9Cit=E2=80=9D and =E2=80=9Cso=E2=80=9D. >>> >> >> Done. >> >> >>> =C2=A78, last paragraph: =E2=80=9C For packets in repair mode, the data= they are >>> caring is often already encrypted further increasing the size.=E2=80=9D= - I assume >>> =E2=80=9Ccaring=E2=80=9D is not the intended word. Did you mean =E2=80= =9Ccarrying=E2=80=9D? If so, consider >>> s / =E2=80=9Cdata they are carrying=E2=80=9D / =E2=80=9Cdata they carry= =E2=80=9D >> >> >> Revised. >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >> >> >> > --000000000000a1c44605784dceca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Oh actually, let's not worry about synchronizing = now.=C2=A0 I'm OK to send these to IETF LC separately; I just think the= y should all be on the same IESG telechat.

I'l= l push a new version of this tomorrow, and EKT as soon as I can find a resp= onsive author.

--Richard

On Mon, Oct 15, 2018 at 7:04 PM B= en Campbell <ben@nostrum.com> = wrote:
Works for me. The framework draft revi= ew is in my queue for tomorrow.

Thanks!

Ben.

On Oct 15, 2018, a= t 5:42 PM, Richard Barnes <rlb@ipv.sx> wrote:

I would propose we put forward al= l three documents together.=C2=A0 (-double, -ekt-diet, and -framework)=C2= =A0 They'll be more comprehensible to the ADs that way.

On Mon, Oct 15, 2018 at 6:40 PM B= en Campbell <ben@no= strum.com> wrote:
Thanks, the PR loo= ks good to me. Please submit a revision when you are ready.

<= div>I think that, with the PR applied, it will be ready for IETF LC.=C2=A0 = That should probably be done in tandem with the media framework (in my queu= e to review in the next couple of days. Authors and chairs: do you think we= should also coordinate with ekt-diet?

Thanks!

Ben.


On Oct 5, 2018, at 9:48 AM, Richard Barnes <rlb@ipv.sx> wrote:

Hey Ben,

<= div>After talking with Cullen, I am now the stuckee for this.=C2=A0 I'v= e filed a PR at:


Comments inline below.

<= div class=3D"gmail_quote">
On Tue, Jun 5, 2018 at 12:40 AM = Ben Campbell <ben@n= ostrum.com> wrote:
Hi,

This is my AD Evaluation of draft-ietf-perc-double-09. Thanks for this work= ; I think it is important and on the right track, but suffers from some rea= dability issues, especially from =C2=A77 onwards. I=E2=80=99d like to discu= ss my comments prior to IETF last call.

Thanks!

Ben.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94

*** Substantive Comments ***

General: Does it make sense to progress this prior to draft-ietf-perc-priva= te-media-framework rather than wait and progress them together? it seems li= ke one really needs to read the framework to understand at least parts of t= his draft. (Which would, btw, suggest making the framework a normative refe= rence.)

I think at this point, -framewo= rk has caught up a bit (I understand it's awaiting your review), so thi= s seems OBE.=C2=A0 I agree that it will make easier reading for ADs to read= the three docs (this, framework, and EKT) on the same telechat.
<= div>
=C2=A0
=C2=A72, Media Distributor: Should this be defined as switch-based? Otherwi= se it seems circular.

I've copied d= own the definition =C2=A71, which explicitly says that the MD does not need= to interpret or change media content.=C2=A0 Also added a ref to -framework= at this point.

=C2=A0
=C2=A75 and subsections: These sections are confusing in the treatment of e= xtensions. =C2=A75.1 step 3 says to truncate the header to remove any exten= sions. Yet other sections of text repeatedly mention the handling of extens= ions. I think the document needs a paragraph or two to describe the handlin= g of RTP extensions at a high level.

I&= #39;ve added an overview of the transform, including thoughts on extensions= , to the top of =C2=A75.
=C2=A0
=C2=A0
Along those lines, it=E2=80=99s not entirely clear what is meant by putting= =E2=80=9C (12 + 4 * CC bytes)=E2=80=9D in parentheses after the guidance t= o truncate in =C2=A75.1. Is that the amount to be truncated? Amount left af= ter truncation? (Same question for =C2=A75.3)

Clarified that this is the amount left after truncation, i.e., take = the first N bytes, in both places.

=C2=A0
=C2=A75.2: It would be helpful to include a paragraph or two to describe th= e impact if multiple MDs modify the same field(s). I can infer that, but it= would be better to be explicit. (IIRC, there is a passing mention in the s= ecurity considerations, but it would be better to have more here.)

Added a paragraph.

=C2= =A0
=C2=A78: Can you offer any guidance about selecting 128 vs 256?

I don't really think there's much to say h= ere; it's up to the user of the transform.=C2=A0 Use 128 unless you'= ;re paranoid, then use 256?=C2=A0 :)=C2=A0 Note that RFC 7714, which define= s the AES-GCM transforms, does not provide similar guidance.
=
=C2=A0
*** Editorial comments and nits ***

There are a number of abbreviations that need to be expanded on first use. = Please remember that abbreviations should be expanded both in the abstract = and the body.

- SRTP
- SSRC
- SEQ
- ROC
- PRF
- PT
- SEQ
- RTX
- RED
- FEC

I've expanded most of these.= =C2=A0 I have left SSRC, SEQ, ROC, and PT, since in this context, they are = basically opaque labels for RTP header fields.=C2=A0

=C2=A0
=C2=A72:
- Please use the boilerplate from RFC8174. There are a number of lower case= instances of normative keywords.

Done.=
=C2=A0
=C2=A73,

- " Generate key and salt values of the length required for the combin= ed inner (end-to-end) and outer (hop-by-hop) algorithms.=E2=80=9D: The docu= ment is inconsistent in whether it describes a single key with inner and ou= ter halves, or separate inner and outer keys. I realize that this is an art= ifact of syntax, but it is likely to confuse a reader new to the topic.
=

The very next bullet says to glue them tog= ether.=C2=A0 Not sure how else to say this.
=C2=A0
- Paragraph starting with =E2=80=9CObviously, if the Media Distributor=E2= =80=A6=E2=80=9D: =E2=80=9CObviously=E2=80=9D is a null word in context.
=

Deleted.
=C2=A0
=C2=A73.1: This section would be much more approachable if you defined the = terms (such as n, k, and x), rather than forcing readers to look them up in= 3711. Also, the doubled crypto suite IDs are likely to be confusing to the= reader who sees them here without the explanation later in the draft.
<= /blockquote>

Done.
=C2=A0
=C2=A75.2, step 2: =E2=80=9CChange any parts of the RTP packet=E2=80=A6=E2= =80=9D -The MS is limited to changing the 3 fields defined for the OHB, rig= ht, at least as defined in this draft? Not just anything it wants?

Correct.=C2=A0 Done.
=C2=A0
=
=C2=A75.3, last two paragraphs: It=E2=80=99s sort of an odd construction to= talk about =E2=80=9Cany of the following=E2=80=9D with a single entry list= ..

Revised to clarify.
= =C2=A0
=C2=A77 and subsections: These could use another proofreading pass. In part= icular, it is imprecise about inner vs outer encryption, which actors do wh= at, and has a number of pronouns with ambiguous antecedents. The heavy use = of passive voice obscures the actors in multiple places. I will call out so= me specifics, but please do not treat my comments as exhaustive.

Did a revision pass, let me know what you think.<= br>
=C2=A0
=C2=A77: =E2=80=9C The repair mechanism, when used with double, typically o= perates on the double encrypted data and encrypts
=C2=A0 =C2=A0them using only the HBH key.=E2=80=9D Does =E2=80=9Cdouble enc= rypted=E2=80=9D mean =E2=80=9Couter encrypted=E2=80=9D? Also, while I recog= nize =E2=80=9Cdata=E2=80=9D as plural, it=E2=80=99s plural in a non-countab= le sense; that is, s / them / it.

=C2=A77.1:
- =E2=80=9C =E2=80=A6 cached payloads MUST be the encrypted packets =E2=80= =A6=E2=80=9D - Inner or outer? What device enforces this? (Consider active = voice.)
- Which element represents =E2=80=9Cthe other side=E2=80=9D? Are we talking= about an endpoint or MD? (Please stick to the defined terminology)
- =E2=80=9C When encrypting a retransmission packet, it MUST be encrypted t= he packet in repair mode.=E2=80=9D - I can=E2=80=99t parse the phrase after= the comma. Also, what device MUST encrypt it?

=C2=A77.2:
- =E2=80=9Cthe primary encoding MAY contain=E2=80=A6=E2=80=9D - Is that MAY= a grant of permission or a statement of fact?

- " The sender takes encrypted payload from the cached packets=E2=80= =9D- Missing article for encrypted payload? Or should this say =E2=80=9C=E2= =80=A6 takes encrypted packets from the cached payload=E2=80=A6=E2=80=9D?
- =E2=80=9C Any header extensions from the primary encoding are copied to t= he RTP packet that will carry the RED payload and the other RTP header info= rmation such as SSRC, SEQ, CSRC, etc are set to the same as the primary pay= load.=C2=A0 The RED RTP packet is then encrypted in repair mode and sent.= =E2=80=9D: This is confusing; parts are copied from the primary encoding an= d others are the same as in the primary encoding? Don=E2=80=99t both of tho= se mean the same thing?

- =E2=80=9C The receiver decrypts the payload=E2=80=A6=E2=80=9D: Endpoint o= r MD? Is this inner or outer encryption?

- Last paragraph: Seems like that belongs in the FEC section. Also, does th= is document really need to make that sort of recommendation? It seems like = a general statement about RED and FEC that is not specific to double.


=C2=A77.3:

- "When using Flex FEC [I-D.ietf-payload-flexible-fec-scheme] with dou= ble, the negotiation of double for the crypto is the out of band signaling = that indicates that the repair packets MUST use the order of operations of = SRTP followed by FEC when encrypting.=E2=80=9D - The sentence is hard to pa= rse. Also, is MUST a normative requirement or a statement of fact? (It seem= s odd to signal that you MUST do something).
- =E2=80=9C=E2=80=A6=C2=A0 data, which is already encrypted, it MUST be enc= rypted in repair mode packet.=E2=80=9D s/ =E2=80=9C, which=E2=80=9D / =E2= =80=9Cthat=E2=80=9D. Also, what actor MUST encrypt the data in repair mode?= (Consider active voice.)

- =E2=80=9C The algorithm recommend=E2=80=A6=E2=80=9D s / recommend / recom= mended

Done.
=C2=A0
=
=C2=A77.4:
- s/ "sent with [RFC4733]=E2=80=9D / =E2=80=9Csent using the mechanism= in [RFC4733]=E2=80=9D
- =E2=80=9C and the relay can not read it so it cannot be used=E2=80=9D - m= issing comma between =E2=80=9Cit=E2=80=9D and =E2=80=9Cso=E2=80=9D.

Done.
=C2=A0
=C2=A78, last paragraph: =E2=80=9C For packets in repair mode, the data the= y are caring is often already encrypted further increasing the size.=E2=80= =9D - I assume =E2=80=9Ccaring=E2=80=9D is not the intended word. Did you m= ean =E2=80=9Ccarrying=E2=80=9D? If so, consider s / =E2=80=9Cdata they are = carrying=E2=80=9D / =E2=80=9Cdata they carry=E2=80=9D

=
Revised.
_______________________________________________
Perc mailing list
Perc@ietf.org
https://= www.ietf.org/mailman/listinfo/perc


--000000000000a1c44605784dceca-- From nobody Wed Oct 17 14:20:27 2018 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDC9130DF0; Wed, 17 Oct 2018 14:20:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: perc@ietf.org Message-ID: <153981122102.27457.5209239058211139090@ietfa.amsl.com> Date: Wed, 17 Oct 2018 14:20:21 -0700 Archived-At: Subject: [Perc] I-D Action: draft-ietf-perc-double-10.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 21:20:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Privacy Enhanced RTP Conferencing WG of the IETF. Title : SRTP Double Encryption Procedures Authors : Cullen Jennings Paul E. Jones Richard Barnes Adam Roach Filename : draft-ietf-perc-double-10.txt Pages : 18 Date : 2018-10-17 Abstract: In some conferencing scenarios, it is desirable for an intermediary to be able to manipulate some parameters in Real Time Protocol (RTP) packets, while still providing strong end-to-end security guarantees. This document defines a cryptographic transform for the Secure Real Time Protocol (SRTP) that uses two separate but related cryptographic operations to provide hop-by-hop and end-to-end security guarantees. Both the end-to-end and hop-by-hop cryptographic algorithms can utilize an authenticated encryption with associated data scheme or take advantage of future SRTP transforms with different properties. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-perc-double/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-perc-double-10 https://datatracker.ietf.org/doc/html/draft-ietf-perc-double-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-double-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 17 14:34:26 2018 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1A0130E03; Wed, 17 Oct 2018 14:34:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: perc@ietf.org Message-ID: <153981205687.27640.17992942799834135678@ietfa.amsl.com> Date: Wed, 17 Oct 2018 14:34:16 -0700 Archived-At: Subject: [Perc] I-D Action: draft-ietf-perc-srtp-ekt-diet-09.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 21:34:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Privacy Enhanced RTP Conferencing WG of the IETF. Title : Encrypted Key Transport for DTLS and Secure RTP Authors : Cullen Jennings John Mattsson David A. McGrew Dan Wing Flemming Andreason Filename : draft-ietf-perc-srtp-ekt-diet-09.txt Pages : 24 Date : 2018-10-17 Abstract: Encrypted Key Transport (EKT) is an extension to DTLS (Datagram Transport Layer Security) and Secure Real-time Transport Protocol (SRTP) that provides for the secure transport of SRTP master keys, rollover counters, and other information within SRTP. This facility enables SRTP for decentralized conferences by distributing a common key to all of the conference endpoints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-perc-srtp-ekt-diet-09 https://datatracker.ietf.org/doc/html/draft-ietf-perc-srtp-ekt-diet-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-srtp-ekt-diet-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 17 14:37:56 2018 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A87E130E13 for ; Wed, 17 Oct 2018 14:37:54 -0700 (PDT) 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=ham 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 nDvKl5QA70kF for ; Wed, 17 Oct 2018 14:37:52 -0700 (PDT) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (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 3B8CF130DFF for ; Wed, 17 Oct 2018 14:37:52 -0700 (PDT) Received: by mail-oi1-x22b.google.com with SMTP id a203-v6so22366009oib.0 for ; Wed, 17 Oct 2018 14:37:52 -0700 (PDT) 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; bh=jX6gsX5aWak5sntNgbkY92t0mKyOpTh1Bbwk8e3YsYQ=; b=gE4eNslebvagDog22F9dGXdzBkRYJntDwUIW92TEzbDe+tLDIU7tyaNnzQVoBFm+3l aMlmtZX1ktVMemesaA5Dvl3H3YxyLzPW2OtGb9hTzKOnNP62dVRZyMXA6CyKaufiZ4Xw 92N9MqYIQ6CZ3HRippcnTDjLxeNO1yd7cVk0XRrU1VlkdaLpQilpNt9Y6DEFnlV5QA3c +wlHsm/4Y9wqQYOE1oyfzW6e1OABEgpmUz+Q8H8OzE5FRoqT8dRm3r09pO9zLmkZDU0Z YiprYIfWDC7Tah51JJE6YkXQjaMY5IcUy8gCke9bOzM/VmLmKUix7jQwAiWqiYsPSCOi VKFA== 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; bh=jX6gsX5aWak5sntNgbkY92t0mKyOpTh1Bbwk8e3YsYQ=; b=XhX3ES/PLKiB1dne77P+HkzQfjnYX4tulZk1Dg0esqDYGpuPMD119tcMKBIqUzKsxM KqyYhuTJHgo+TjC6Q0TEJxo2a36mphME5bUrj4vFYrbjlbZYEK+H8+iQkKzlQsIRPqV2 hs5+MnJ1FgQSeMke31Zwg4Y8hRmHdKXDtmZvYEeTJxG9+0OlPaa6na9o6lR6FBL7qVpj 5LHq1E0SO82tO1TO895Rqqq5v0DnvCcXiK7VNS5Yef6MOsP2nGD+z/A4QEHwzkESMwz4 FqbxLq9nqAb++aNsJRHwamBVppMh2hdAD98QpVG2WzYM+jZUHD+xJPxkJEqCrl3ty8rt WiIg== X-Gm-Message-State: ABuFfogEgcqPkI7ibP6hIMEbJSCyJGMAZU0HhLPe3gnXmfgZwwBAzs7C TNmvEV+lR+4nmI3y5yslWycIasuDN+KATYWZ35jV0H9e X-Google-Smtp-Source: ACcGV62FVtKXSwry8i3AGqgW5dTiyBDtMkXI0prhBXVYyYbFZaTPLFrbr5uktSb2hlT1CU7Vo/yp3DZXsz9EFLFt9Io= X-Received: by 2002:aca:d05c:: with SMTP id h89-v6mr14327233oig.199.1539812271122; Wed, 17 Oct 2018 14:37:51 -0700 (PDT) MIME-Version: 1.0 References: <153981205687.27640.17992942799834135678@ietfa.amsl.com> In-Reply-To: <153981205687.27640.17992942799834135678@ietfa.amsl.com> From: Richard Barnes Date: Wed, 17 Oct 2018 17:37:38 -0400 Message-ID: To: perc@ietf.org, Ben Campbell Content-Type: multipart/alternative; boundary="0000000000007101ef0578737bb9" Archived-At: Subject: Re: [Perc] I-D Action: draft-ietf-perc-srtp-ekt-diet-09.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 21:37:55 -0000 --0000000000007101ef0578737bb9 Content-Type: text/plain; charset="UTF-8" Ben: With this revision, and the one of -double just posted, I think these two are ready for LC. On Wed, Oct 17, 2018, 17:34 wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Privacy Enhanced RTP Conferencing WG of > the IETF. > > Title : Encrypted Key Transport for DTLS and Secure RTP > Authors : Cullen Jennings > John Mattsson > David A. McGrew > Dan Wing > Flemming Andreason > Filename : draft-ietf-perc-srtp-ekt-diet-09.txt > Pages : 24 > Date : 2018-10-17 > > Abstract: > Encrypted Key Transport (EKT) is an extension to DTLS (Datagram > Transport Layer Security) and Secure Real-time Transport Protocol > (SRTP) that provides for the secure transport of SRTP master keys, > rollover counters, and other information within SRTP. This facility > enables SRTP for decentralized conferences by distributing a common > key to all of the conference endpoints. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-perc-srtp-ekt-diet-09 > https://datatracker.ietf.org/doc/html/draft-ietf-perc-srtp-ekt-diet-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-srtp-ekt-diet-09 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --0000000000007101ef0578737bb9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ben: With this revision, and the one of -double just post= ed, I think these two are ready for LC.

On Wed, Oct 17, 2018, 17:34 <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Privacy Enhanced RTP Conferencing=C2=A0 WG= of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Encrypted Key Transport for DTLS and Secure RTP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Cull= en Jennings
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Mattsson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 David A. McGrew
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Dan Wing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Flemming Andreason
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-perc-srtp-ekt-diet-09.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 24
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-10-17

Abstract:
=C2=A0 =C2=A0Encrypted Key Transport (EKT) is an extension to DTLS (Datagra= m
=C2=A0 =C2=A0Transport Layer Security) and Secure Real-time Transport Proto= col
=C2=A0 =C2=A0(SRTP) that provides for the secure transport of SRTP master k= eys,
=C2=A0 =C2=A0rollover counters, and other information within SRTP.=C2=A0 Th= is facility
=C2=A0 =C2=A0enables SRTP for decentralized conferences by distributing a c= ommon
=C2=A0 =C2=A0key to all of the conference endpoints.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.o= rg/doc/draft-ietf-perc-srtp-ekt-diet/

There are also htmlized versions available at:
https://tools.ietf.org/html/d= raft-ietf-perc-srtp-ekt-diet-09
https://datatracker= .ietf.org/doc/html/draft-ietf-perc-srtp-ekt-diet-09

A diff from the previous version is available at:
https://www.ietf.org/= rfcdiff?url2=3Ddraft-ietf-perc-srtp-ekt-diet-09


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org<= /a>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Perc mailing list
Perc@= ietf.org
https://www.ietf.org/mailman/listinfo/perc<= br>
--0000000000007101ef0578737bb9-- From nobody Wed Oct 17 14:52:12 2018 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D14130E00 for ; Wed, 17 Oct 2018 14:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 5Db9-dpWUf2L for ; Wed, 17 Oct 2018 14:52:08 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 2FE8D130DFF for ; Wed, 17 Oct 2018 14:52:07 -0700 (PDT) Received: from [10.0.1.27] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w9HLq6Kh052355 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 17 Oct 2018 16:52:07 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.27] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A219A879-3179-4DD1-9C11-DC567FC295F7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Wed, 17 Oct 2018 16:52:05 -0500 In-Reply-To: Cc: perc@ietf.org To: Richard Barnes References: <153981205687.27640.17992942799834135678@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [Perc] I-D Action: draft-ietf-perc-srtp-ekt-diet-09.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 21:52:11 -0000 --Apple-Mail=_A219A879-3179-4DD1-9C11-DC567FC295F7 Content-Type: multipart/alternative; boundary="Apple-Mail=_EB8DFBD6-9123-47DE-83E8-1D565832228A" --Apple-Mail=_EB8DFBD6-9123-47DE-83E8-1D565832228A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks! I am in the process of reviewing the framework draft. I notice it has = some normative language may conflict with this draft concerning = rekeying. =46rom our previous discussion: >=20 > - Next Sentence: "Outbound packets SHOULD continue to use the old SRTP = Master Key for 250 ms after=E2=80=9D Does that imply a normative = requirement for recipients to keep old keys around for at least that = long? There=E2=80=99s currently an implementation suggestion about that, = but it doesn=E2=80=99t use MUST or SHOULD. > (Editorial: The sentence seems to belong in the =E2=80=9Coutbound=E2=80=9D= section, not the =E2=80=9Cinbound=E2=80=9D section.) >=20 > Yeah, moved this to the outbound section. Added MAY-level inbound = considerations to the implementation notes -- either the receiver can = accept packet loss or do trial decryption. If I am reading correctly, the framework (=C2=A74.5.2) says senders = MUST delay before sending media with the new key. Is that a conflict? If = so, which is correct? Also, the framework does not specify the length of = the delay. Does it make sense for this to be specified in both places? Ben. > On Oct 17, 2018, at 4:37 PM, Richard Barnes wrote: >=20 > Ben: With this revision, and the one of -double just posted, I think = these two are ready for LC. >=20 > On Wed, Oct 17, 2018, 17:34 > wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Privacy Enhanced RTP Conferencing WG = of the IETF. >=20 > Title : Encrypted Key Transport for DTLS and Secure = RTP > Authors : Cullen Jennings > John Mattsson > David A. McGrew > Dan Wing > Flemming Andreason > Filename : draft-ietf-perc-srtp-ekt-diet-09.txt > Pages : 24 > Date : 2018-10-17 >=20 > Abstract: > Encrypted Key Transport (EKT) is an extension to DTLS (Datagram > Transport Layer Security) and Secure Real-time Transport Protocol > (SRTP) that provides for the secure transport of SRTP master keys, > rollover counters, and other information within SRTP. This = facility > enables SRTP for decentralized conferences by distributing a common > key to all of the conference endpoints. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/ = >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-perc-srtp-ekt-diet-09 = > https://datatracker.ietf.org/doc/html/draft-ietf-perc-srtp-ekt-diet-09 = >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-perc-srtp-ekt-diet-09 = >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org = . >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ = >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc = --Apple-Mail=_EB8DFBD6-9123-47DE-83E8-1D565832228A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks!

I = am in the process of reviewing the framework draft. I notice it has some = normative language may conflict with this draft concerning rekeying. = =46rom our previous discussion:

 
- Next = Sentence: "Outbound packets SHOULD continue to use the old SRTP Master = Key for 250 ms after=E2=80=9D Does that imply a normative requirement = for recipients to keep old keys around for at least that long? There=E2=80= =99s currently an implementation suggestion about that, but it doesn=E2=80= =99t use MUST or SHOULD.
(Editorial: The sentence seems to = belong in the =E2=80=9Coutbound=E2=80=9D section, not the =E2=80=9Cinbound= =E2=80=9D section.)

Yeah, moved this to the outbound = section.  Added MAY-level inbound considerations to the = implementation notes -- either the receiver can accept packet loss or do = trial decryption.

If I am reading = correctly, the framework (=C2=A74.5.2)  says senders MUST delay = before sending media with the new key. Is that a conflict? If so, which = is correct? Also, the framework does not specify the length of the = delay.

Does it = make sense for this to be specified in both places?

Ben.

On Oct = 17, 2018, at 4:37 PM, Richard Barnes <rlb@ipv.sx> wrote:

Ben: With this revision, and the one of -double just posted, = I think these two are ready for LC.

On Wed, Oct 17, 2018, = 17:34 <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the Privacy Enhanced RTP Conferencing  = WG of the IETF.

        Title          =  : Encrypted Key Transport for DTLS and Secure RTP
        Authors         : = Cullen Jennings
                    =       John Mattsson
                    =       David A. McGrew
                    =       Dan Wing
                    =       Flemming Andreason
        Filename        : = draft-ietf-perc-srtp-ekt-diet-09.txt
        Pages          =  : 24
        Date          =   : 2018-10-17

Abstract:
   Encrypted Key Transport (EKT) is an extension to DTLS = (Datagram
   Transport Layer Security) and Secure Real-time Transport = Protocol
   (SRTP) that provides for the secure transport of SRTP = master keys,
   rollover counters, and other information within SRTP.  = This facility
   enables SRTP for decentralized conferences by distributing = a common
   key to all of the conference endpoints.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/=

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-perc-srtp-ekt-diet-09
https://datatracker.ietf.org/doc/html/draft-ietf-perc-srtp-ekt-= diet-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-perc-srtp-ekt-di= et-09


Please note that it may take a couple of minutes from the time of = submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

= --Apple-Mail=_EB8DFBD6-9123-47DE-83E8-1D565832228A-- --Apple-Mail=_A219A879-3179-4DD1-9C11-DC567FC295F7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlvHrwUACgkQgFZKbJXz 1A0M1g/+OjCqn3pyGZzJzgrYZqobOnt+7U7b3s3C2rkFe7kL7wCXuZEpm5TmUFHm 6ooQcuEYkD34DO9TGoQQANy/yZREHE8hTa6jHc0lBOAjr3JLO5V9dunJZINDvzyH DyYyyz5WdEQN/Q9+mjM2fEX/rqXc7lFgqxTkn/ujbzbPAhiysEFC7z6ZreCySo/U AowTqS1tVRV1xIynaHdV9+SXauh/oTgmVM+15lIRz00khedCTSX8dbxnDRFTs4BF MbieI8dPCzDqT1uOU6hVKUU7HJuuLLcTECd+VSHJx/XltYHxnkZ4fDTR9Wtg/Chd ynBjFo807WkQZz+72unpl5RF6mmdUcklexwqFhFI7C6Afw+f4lgkIAuiV37zoBOz yWs9r7hvHpLMYyvtic9Gvn6Var6/Aqaw7DdGtDgdOJLLxBVLbyoFsBm1PfyRDX6T UTRnL48muvrpuuy/zgY/ksd3qKYIrfBSsnHI7QEcbfwIjU8LKwISWbkNqy9BRYLy r/cDrULU4C0mK4W3IQUH/YfCx+9inSJOJ8piB9WGxkjWMLo6ptTvb2elUoSi5mg9 2BlbvpefcRjUYtmn50vnZQBvALUGmjQrKYcIjWLRBMLyLGG6H1kZL3QGt9br3ORv ojoQB2sWLV4n/bE3I/7DvLzpPBW12X4w9XiBPvLE8LUjJWg3w58= =pIFe -----END PGP SIGNATURE----- --Apple-Mail=_A219A879-3179-4DD1-9C11-DC567FC295F7-- From nobody Wed Oct 17 20:46:00 2018 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00301252B7 for ; Wed, 17 Oct 2018 20:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 MW0UXVkeOfqn for ; Wed, 17 Oct 2018 20:45:55 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 39BE2120072 for ; Wed, 17 Oct 2018 20:45:55 -0700 (PDT) Received: from [10.0.1.27] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w9I3jrZv007575 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 17 Oct 2018 22:45:54 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.27] From: Ben Campbell Message-Id: <0F10F185-1A45-450A-8C3A-766EF481B2EB@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_466EC64E-1695-4E0E-B949-82E05835AD61"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Wed, 17 Oct 2018 22:45:53 -0500 In-Reply-To: Cc: perc@ietf.org To: Richard Barnes References: <153981205687.27640.17992942799834135678@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [Perc] I-D Action: draft-ietf-perc-srtp-ekt-diet-09.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 03:45:58 -0000 --Apple-Mail=_466EC64E-1695-4E0E-B949-82E05835AD61 Content-Type: multipart/alternative; boundary="Apple-Mail=_120B1AD3-1A19-4DD1-8321-E96A1C540230" --Apple-Mail=_120B1AD3-1A19-4DD1-8321-E96A1C540230 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99ve requested IETF LC for both. Thanks! Ben. > On Oct 17, 2018, at 4:37 PM, Richard Barnes wrote: >=20 > Ben: With this revision, and the one of -double just posted, I think = these two are ready for LC. >=20 > On Wed, Oct 17, 2018, 17:34 > wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Privacy Enhanced RTP Conferencing WG = of the IETF. >=20 > Title : Encrypted Key Transport for DTLS and Secure = RTP > Authors : Cullen Jennings > John Mattsson > David A. McGrew > Dan Wing > Flemming Andreason > Filename : draft-ietf-perc-srtp-ekt-diet-09.txt > Pages : 24 > Date : 2018-10-17 >=20 > Abstract: > Encrypted Key Transport (EKT) is an extension to DTLS (Datagram > Transport Layer Security) and Secure Real-time Transport Protocol > (SRTP) that provides for the secure transport of SRTP master keys, > rollover counters, and other information within SRTP. This = facility > enables SRTP for decentralized conferences by distributing a common > key to all of the conference endpoints. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/ = >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-perc-srtp-ekt-diet-09 = > https://datatracker.ietf.org/doc/html/draft-ietf-perc-srtp-ekt-diet-09 = >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-perc-srtp-ekt-diet-09 = >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org = . >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ = >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc = --Apple-Mail=_120B1AD3-1A19-4DD1-8321-E96A1C540230 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80=99ve requested IETF LC for both.

Thanks!

Ben.

On Oct = 17, 2018, at 4:37 PM, Richard Barnes <rlb@ipv.sx> wrote:

Ben: With this revision, and the one of -double just posted, = I think these two are ready for LC.

On Wed, Oct 17, 2018, = 17:34 <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the Privacy Enhanced RTP Conferencing  = WG of the IETF.

        Title          =  : Encrypted Key Transport for DTLS and Secure RTP
        Authors         : = Cullen Jennings
                    =       John Mattsson
                    =       David A. McGrew
                    =       Dan Wing
                    =       Flemming Andreason
        Filename        : = draft-ietf-perc-srtp-ekt-diet-09.txt
        Pages          =  : 24
        Date          =   : 2018-10-17

Abstract:
   Encrypted Key Transport (EKT) is an extension to DTLS = (Datagram
   Transport Layer Security) and Secure Real-time Transport = Protocol
   (SRTP) that provides for the secure transport of SRTP = master keys,
   rollover counters, and other information within SRTP.  = This facility
   enables SRTP for decentralized conferences by distributing = a common
   key to all of the conference endpoints.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/=

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-perc-srtp-ekt-diet-09
https://datatracker.ietf.org/doc/html/draft-ietf-perc-srtp-ekt-= diet-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-perc-srtp-ekt-di= et-09


Please note that it may take a couple of minutes from the time of = submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

= --Apple-Mail=_120B1AD3-1A19-4DD1-8321-E96A1C540230-- --Apple-Mail=_466EC64E-1695-4E0E-B949-82E05835AD61 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlvIAfEACgkQgFZKbJXz 1A2njg//V6PiGgNyzWj83G54tihm4PSWHnAhySPxnMtaTF5cbCv5oQgDb5dqHpfv GnY7hZBm+p5iGPoiEK1a6MEzmBnUxBFI7nZ/TGlC3OaG394S57xoSOPc2gko5qdd XQ+RoxhyybrQ9pafCIXvgBB/iAnolBB/GLOcVxXPUpbK9vBrtKW1XquyDHc8/eW8 ThPvB+81oYLdrqa/qa0ObCzqN+S2WdKOvVZ3JU6JEwrt5UGARGtTY8OBFm9eNqw7 MHkfAXKRuQSzoiObTDM/LP0Kbqjt2UMKeprX2ZYyaFvKo8ePgwpk/uVurvaY3DXb fS5MYdAGgTaCOzm7VUaB8/sNOW3Bmivpot+Xl6sORdxkrAzQV4hSunqsB5eAQNZq ObNBG3f4BqemNEV2ySU6DIcLf31PMbJKq7PBhDyeoyQZMAP5MXE/yl6j6Wbi9suT WpMRbBxahwIqeQJPeXPnVrAgYjsZ/I8Sy8W2Fz8FnVyp1oPaD/5spv7v1sULg6ct cOQJMe5swedJRcROPY1HUuZJ4QrlsoUQS2mkgSsEQFcZyDoIu3wBEB0qTZ5TZkYP Asyim6xk4gjOgymhsvuIO0pM/tAHdq2n+QMj5GjC+Th+S2TH54sPWOQU3aa2zA8f Gr0obzV2WLPDsQMPgFmYCo6BoLkqygCNuIEE1XnF3A0J97WPEt8= =ZwOD -----END PGP SIGNATURE----- --Apple-Mail=_466EC64E-1695-4E0E-B949-82E05835AD61-- From nobody Thu Oct 18 05:53:12 2018 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C7D12D4EE; Thu, 18 Oct 2018 05:53:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk CC: ben@nostrum.com, draft-ietf-perc-double@ietf.org, suhasietf@gmail.com, perc@ietf.org, Suhas Nandakumar , perc-chairs@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <153986719048.22172.16783347227743553477.idtracker@ietfa.amsl.com> Date: Thu, 18 Oct 2018 05:53:10 -0700 Archived-At: Subject: [Perc] Last Call: (SRTP Double Encryption Procedures) to Proposed Standard X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 12:53:10 -0000 The IESG has received a request from the Privacy Enhanced RTP Conferencing WG (perc) to consider the following document: - 'SRTP Double Encryption Procedures' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-11-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In some conferencing scenarios, it is desirable for an intermediary to be able to manipulate some parameters in Real Time Protocol (RTP) packets, while still providing strong end-to-end security guarantees. This document defines a cryptographic transform for the Secure Real Time Protocol (SRTP) that uses two separate but related cryptographic operations to provide hop-by-hop and end-to-end security guarantees. Both the end-to-end and hop-by-hop cryptographic algorithms can utilize an authenticated encryption with associated data scheme or take advantage of future SRTP transforms with different properties. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-perc-double/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-perc-double/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Oct 18 05:55:48 2018 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 704E9130E76; Thu, 18 Oct 2018 05:55:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk CC: ben@nostrum.com, suhasietf@gmail.com, perc@ietf.org, draft-ietf-perc-srtp-ekt-diet@ietf.org, Suhas Nandakumar , perc-chairs@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <153986733844.22204.13928411055026786582.idtracker@ietfa.amsl.com> Date: Thu, 18 Oct 2018 05:55:38 -0700 Archived-At: Subject: [Perc] Last Call: (Encrypted Key Transport for DTLS and Secure RTP) to Proposed Standard X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 12:55:46 -0000 The IESG has received a request from the Privacy Enhanced RTP Conferencing WG (perc) to consider the following document: - 'Encrypted Key Transport for DTLS and Secure RTP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-11-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Encrypted Key Transport (EKT) is an extension to DTLS (Datagram Transport Layer Security) and Secure Real-time Transport Protocol (SRTP) that provides for the secure transport of SRTP master keys, rollover counters, and other information within SRTP. This facility enables SRTP for decentralized conferences by distributing a common key to all of the conference endpoints. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3231/ From nobody Thu Oct 18 11:50:29 2018 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502031286D9 for ; Thu, 18 Oct 2018 11:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 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] autolearn=ham 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 z0F5craKKTMb for ; Thu, 18 Oct 2018 11:50:24 -0700 (PDT) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 99898127333 for ; Thu, 18 Oct 2018 11:50:24 -0700 (PDT) Received: by mail-oi1-x22c.google.com with SMTP id v69-v6so24899512oif.1 for ; Thu, 18 Oct 2018 11:50:24 -0700 (PDT) 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=+8Mo1KGVrpqYh7M0RIAI5AuBotN1Ksrg24LbXjz/+SQ=; b=ujT4f3Y/iwybu9KPAnY2cjzuvKgAuNLF31H442Lj41bZ5dJxrtEAe/io2qupGMG3K9 xp6ZhbWheDLlvBDrmGy+mwc+TUEhpGKXMaw+GlngtCRKgkdsAjQG6uhnYW2UVNgGxSWM IpN8mPmPuXEarUU2PppVFZQEhpLsEjEbIrr+afoSD4XJGDxXLVbKVPdk6Ulij0765XZ5 GaQpH3zIyhhePSU7jSTWFB9bWlwL3rFg4Oq52n0UXUNtT1XP7M5GxflcyAaH/23LvD3C 6QwStH/LB5AXsGHV2Q43Fzei4fPHgCqnyz2ISVitElFOyZhRekUHZUV8a7cXgG3PM9sg ENlg== 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=+8Mo1KGVrpqYh7M0RIAI5AuBotN1Ksrg24LbXjz/+SQ=; b=oktL8NFXy3MwxOMBBcDTcEfmi4DwNl2sGCvlFrXHmZ1uf3OHDPz0W+7ibELwIqn2L2 7ZIlhnAzjP2cd00CcETZtrwQnaxj8PLB8P2zDmf8Rsd6Sv6mMxkjBehQ9xPqhlyjagbM chQ+TM68j/YpmkiO5rLg2afqjPXc1/JhQ/O9BKOjS9HlxmkivsGureS5iJez8DtL7dG/ NHkxzYADEjPfYbu7f+EFRFzLF+P2FDrzFeS6XSh9WlpdnjLcE8DSRJfhlIGuPv/N75eG nEmq8i32vp1VyUDKXAN2gM7OaTE4iektUGRgZv9ZAjZMy7XB28U3BXr0Klv0wjLRUGQd cb5Q== X-Gm-Message-State: ABuFfoiZBO7jrwaPXow36lktwf5hGtBvo/YwHskbMRyFhRF9xtU0RMq7 1jgVd9UG4SIjNiY5OD22IGUw0eQR1Moj8VboSY1hpPbAhPE= X-Google-Smtp-Source: ACcGV63oJVyIEl3QIrLlk7RCKyFWWDfVLSMbamb3EJUzOWxH/r4YsoZg3H+Av4tKkGL/I8ISucTRRynYc0RjOmubb+Q= X-Received: by 2002:aca:d05c:: with SMTP id h89-v6mr16263760oig.199.1539888623697; Thu, 18 Oct 2018 11:50:23 -0700 (PDT) MIME-Version: 1.0 References: <153981205687.27640.17992942799834135678@ietfa.amsl.com> In-Reply-To: From: Richard Barnes Date: Thu, 18 Oct 2018 14:50:00 -0400 Message-ID: To: Ben Campbell Cc: perc@ietf.org Content-Type: multipart/alternative; boundary="00000000000068d51e05788542b4" Archived-At: Subject: Re: [Perc] I-D Action: draft-ietf-perc-srtp-ekt-diet-09.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 18:50:27 -0000 --00000000000068d51e05788542b4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for requesting LC for double and EKT. With regard to this issue... On Wed, Oct 17, 2018 at 5:52 PM Ben Campbell wrote: > Thanks! > > I am in the process of reviewing the framework draft. I notice it has som= e > normative language may conflict with this draft concerning rekeying. From > our previous discussion: > > > >> - Next Sentence: "Outbound packets SHOULD continue to use the old SRTP >> Master Key for 250 ms after=E2=80=9D Does that imply a normative require= ment for >> recipients to keep old keys around for at least that long? There=E2=80= =99s >> currently an implementation suggestion about that, but it doesn=E2=80=99= t use MUST >> or SHOULD. >> (Editorial: The sentence seems to belong in the =E2=80=9Coutbound=E2=80= =9D section, not >> the =E2=80=9Cinbound=E2=80=9D section.) >> > > Yeah, moved this to the outbound section. Added MAY-level inbound > considerations to the implementation notes -- either the receiver can > accept packet loss or do trial decryption. > > > If I am reading correctly, the framework (=C2=A74.5.2) says senders MUST= delay > before sending media with the new key. Is that a conflict? If so, which i= s > correct? Also, the framework does not specify the length of the delay. > > Does it make sense for this to be specified in both places? > There's sort of a conflict here. The crux is here: """ Since it may take some time for all of the endpoints in conference to finish re-keying, senders MUST delay a short period of time before sending media encrypted with the new master key, but it MUST be prepared to make use of the information from a new inbound EKT Key immediately. """ The first part talks about media keys, which conflicts with EKT; it should probably be deleted. The second part is about processing EKT tags, and should be kept. So we probably end up with something like the following: """ In order to allow time for all endpoints in the conference to receive the new keys, the sender should follow the recommendations in Section XXX of [I-D.ietf-perc-srtp-ekt-diet]. On receiving a new EKT Key, endpoints MUST be prepared to decrypt EKT tags using the new key. The EKT SPI field can be used to differentiate between tags encrypted with the old and new keys. """ Would you mind just including this in your review, to maximize the probability that Paul catches it? Thanks, --Richard > > Ben. > > On Oct 17, 2018, at 4:37 PM, Richard Barnes wrote: > > Ben: With this revision, and the one of -double just posted, I think thes= e > two are ready for LC. > > On Wed, Oct 17, 2018, 17:34 wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Privacy Enhanced RTP Conferencing WG o= f >> the IETF. >> >> Title : Encrypted Key Transport for DTLS and Secure RT= P >> Authors : Cullen Jennings >> John Mattsson >> David A. McGrew >> Dan Wing >> Flemming Andreason >> Filename : draft-ietf-perc-srtp-ekt-diet-09.txt >> Pages : 24 >> Date : 2018-10-17 >> >> Abstract: >> Encrypted Key Transport (EKT) is an extension to DTLS (Datagram >> Transport Layer Security) and Secure Real-time Transport Protocol >> (SRTP) that provides for the secure transport of SRTP master keys, >> rollover counters, and other information within SRTP. This facility >> enables SRTP for decentralized conferences by distributing a common >> key to all of the conference endpoints. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-perc-srtp-ekt-diet-09 >> https://datatracker.ietf.org/doc/html/draft-ietf-perc-srtp-ekt-diet-09 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-perc-srtp-ekt-diet-09 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >> > > --00000000000068d51e05788542b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for requesting LC for double = and EKT.

With regard to this issue...
On Wed, Oct 17, 2018 at 5:52 P= M Ben Campbell <ben@nostrum.com&g= t; wrote:
Thanks!

I am in the = process of reviewing the framework draft. I notice it has some normative la= nguage may conflict with this draft concerning rekeying. From our previous = discussion:

=C2=A0<= /div>
- Next Sentence: &qu= ot;Outbound packets SHOULD continue to use the old SRTP Master Key for 250 = ms after=E2=80=9D Does that imply a normative requirement for recipients to= keep old keys around for at least that long? There=E2=80=99s currently an = implementation suggestion about that, but it doesn=E2=80=99t use MUST or SH= OULD.
(Editorial: The sentence seems to belong in the =E2=80=9Coutbound= =E2=80=9D section, not the =E2=80=9Cinbound=E2=80=9D section.)

Yeah, moved this to the outbound section.=C2=A0 Add= ed MAY-level inbound considerations to the implementation notes -- either t= he receiver can accept packet loss or do trial decryption.

If I am reading correctly, the framewo= rk (=C2=A74.5.2) =C2=A0says senders MUST delay before sending media with th= e new key. Is that a conflict? If so, which is correct? Also, the framework= does not specify the length of the delay.

Does it= make sense for this to be specified in both places?

There's sort of a conflict here.=C2=A0 The = crux is here:

"""
=C2=A0= =C2=A0 Since it may take some time for all of the
=C2=A0=C2=A0 endpoints= in conference to finish re-keying, senders MUST delay a
=C2=A0=C2=A0 sh= ort period of time before sending media encrypted with the new
=C2=A0=C2= =A0 master key, but it MUST be prepared to make use of the information
= =C2=A0=C2=A0 from a new inbound EKT Key immediately.
"&q= uot;"

The first part talks about media ke= ys, which conflicts with EKT; it should probably be deleted.=C2=A0 The seco= nd part is about processing EKT tags, and should be kept.=C2=A0 So we proba= bly end up with something like the following:

&quo= t;""
=C2=A0=C2=A0 In order to allow time for all endpoi= nts in the conference to receive the new keys,
=C2=A0=C2=A0 the s= ender should follow the recommendations in Section XXX of [I-D.ietf-perc-sr= tp-ekt-diet].
=C2=A0=C2=A0 On receiving a new EKT Key, endpoints = MUST be prepared to decrypt EKT tags using the
=C2=A0=C2=A0 new k= ey.=C2=A0 The EKT SPI field can be used to differentiate between tags encry= pted with
=C2=A0=C2=A0 the old and new keys.
""= ;"

Would you mind just including this in your revie= w, to maximize the probability that Paul catches it?

Thanks,
--Richard

=C2=A0

Ben.

On Oct 17, 2018, at 4:37 PM, Richard Barnes <rlb@ipv.sx> wrote:

Ben: With this revision, and the one of -double just posted, I think= these two are ready for LC.

On Wed, Oct 17, 2018, 17:34 <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Privacy Enhanced RTP Conferencing=C2=A0 WG= of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Encrypted Key Transport for DTLS and Secure RTP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Cull= en Jennings
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Mattsson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 David A. McGrew
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Dan Wing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Flemming Andreason
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-perc-srtp-ekt-diet-09.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 24
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-10-17

Abstract:
=C2=A0 =C2=A0Encrypted Key Transport (EKT) is an extension to DTLS (Datagra= m
=C2=A0 =C2=A0Transport Layer Security) and Secure Real-time Transport Proto= col
=C2=A0 =C2=A0(SRTP) that provides for the secure transport of SRTP master k= eys,
=C2=A0 =C2=A0rollover counters, and other information within SRTP.=C2=A0 Th= is facility
=C2=A0 =C2=A0enables SRTP for decentralized conferences by distributing a c= ommon
=C2=A0 =C2=A0key to all of the conference endpoints.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.o= rg/doc/draft-ietf-perc-srtp-ekt-diet/

There are also htmlized versions available at:
https://tools.ietf.org/html/d= raft-ietf-perc-srtp-ekt-diet-09
https://datatracker= .ietf.org/doc/html/draft-ietf-perc-srtp-ekt-diet-09

A diff from the previous version is available at:
https://www.ietf.org/= rfcdiff?url2=3Ddraft-ietf-perc-srtp-ekt-diet-09


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org= .

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Perc mailing list
Perc@= ietf.org
https://www.ietf.org/mailman/listinfo/perc<= br>

--00000000000068d51e05788542b4-- From nobody Thu Oct 18 11:58:52 2018 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5636A1286D9 for ; Thu, 18 Oct 2018 11:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 jP5X05aDxljc for ; Thu, 18 Oct 2018 11:58:44 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 11F541293FB for ; Thu, 18 Oct 2018 11:58:44 -0700 (PDT) Received: from [10.0.1.27] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w9IIwg5c055067 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 18 Oct 2018 13:58:43 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.27] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_DAD78178-B98D-4DEE-A915-03503C71BB14"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Thu, 18 Oct 2018 13:58:41 -0500 In-Reply-To: Cc: perc@ietf.org To: Richard Barnes References: <153981205687.27640.17992942799834135678@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [Perc] I-D Action: draft-ietf-perc-srtp-ekt-diet-09.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 18:58:46 -0000 --Apple-Mail=_DAD78178-B98D-4DEE-A915-03503C71BB14 Content-Type: multipart/alternative; boundary="Apple-Mail=_D92B0CAE-9F36-4527-94F2-5363F3BEE34F" --Apple-Mail=_D92B0CAE-9F36-4527-94F2-5363F3BEE34F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 18, 2018, at 1:50 PM, Richard Barnes wrote: >=20 > Would you mind just including this in your review, to maximize the = probability that Paul catches it? >=20 I will do so. I=E2=80=99ve already captured it in my notes, but will = adjust based on your comments. Ben. --Apple-Mail=_D92B0CAE-9F36-4527-94F2-5363F3BEE34F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Oct 18, 2018, at 1:50 PM, Richard Barnes <rlb@ipv.sx> wrote:

Would = you mind just including this in your review, to maximize the probability = that Paul catches it?


I will do so. I=E2=80=99ve already captured = it in my notes, but will adjust based on your comments.

Ben.
= --Apple-Mail=_D92B0CAE-9F36-4527-94F2-5363F3BEE34F-- --Apple-Mail=_DAD78178-B98D-4DEE-A915-03503C71BB14 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlvI1+EACgkQgFZKbJXz 1A3wvA//bI9SSxaPcR8/qWDmH6Q2pNBISriizIOMFVqw54eWeQb31h72FdN4Demp KKYKn1IXlE1o+h7dGmdniecpyCR6SVMXgRcDk/IrbD+CZHiXQQozbTPSmgFRT/uD n+EGB03xJxMyTzGvd2ylAarJq8EreVlUzjl9V/6zph3VF1cOEE1iV1I8GnCJ2vRN c0bFIXZRqzP90hyYOZARo8ILanwSTA1Iou8ly0r3mg83ParLuT+cK8Ro8Y9Yob7a Nfd2HS88FZEA8edxPq0Xe5tkf7cAhVn5cycCKT8mmGPlSdfB4Li1SwsuxL9w4vFc CQqs3hMpA+fJDbYX5EOSLiaAiSalpy3F4N9TdpNBfRX8cHF3yXZZM6lYOlg2MDLf Hf5+F/06wMGqqsExZkL40ZLBvaHfyY7ggcmdzf297NHbHnxguRReaGGx5PaRfEZn 59l1HJsodDrgoTio4FUyIXDXyonHnX54aGTWQd+fjG0ImHPlLCZbGXe5Ks07B+Qe eiZ+lLoqE5RpLHx+0n+q1fgyAgp4AH4oIGs6r8oXk5Z395V4lv0Cv/MUHV/rzYvn iUKVvLpE6SRv56Hi88+qUGDvlFVJVcJmZ2uD0T0Mox5aVr2q1hJE8t8oz9M8z0+f wVt3SHVJJ57H258fLnc5Sb0pvsE8RGepUNsjZTg8OTuUAJxWIO4= =WvFs -----END PGP SIGNATURE----- --Apple-Mail=_DAD78178-B98D-4DEE-A915-03503C71BB14-- From nobody Sat Oct 20 01:24:32 2018 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 261AE128C65; Sat, 20 Oct 2018 01:24:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley To: Cc: perc@ietf.org, ietf@ietf.org, draft-ietf-perc-double.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 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: Subject: [Perc] Genart last call review of draft-ietf-perc-double-10 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2018 08:24:17 -0000 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 . 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/ From nobody Sat Oct 20 12:50:55 2018 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9E8130DF7; Sat, 20 Oct 2018 12:50:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: perc@ietf.org Message-ID: <154006504674.13611.9469075213761279069@ietfa.amsl.com> Date: Sat, 20 Oct 2018 12:50:46 -0700 Archived-At: Subject: [Perc] I-D Action: draft-ietf-perc-dtls-tunnel-04.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2018 19:50:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Privacy Enhanced RTP Conferencing WG of the IETF. Title : DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange Authors : Paul E. Jones Paul M. Ellenbogen Nils H. Ohlmeier Filename : draft-ietf-perc-dtls-tunnel-04.txt Pages : 17 Date : 2018-10-20 Abstract: This document defines a DTLS tunneling protocol for use in multimedia conferences that enables a Media Distributor to facilitate key exchange between an endpoint in a conference and the Key Distributor. The protocol is designed to ensure that the keying material used for hop-by-hop encryption and authentication is accessible to the media distributor, while the keying material used for end-to-end encryption and authentication is inaccessible to the media distributor. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-perc-dtls-tunnel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-perc-dtls-tunnel-04 https://datatracker.ietf.org/doc/html/draft-ietf-perc-dtls-tunnel-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-dtls-tunnel-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Oct 20 15:06:19 2018 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B0F130DF5; Sat, 20 Oct 2018 15:06:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christer Holmberg To: Cc: draft-ietf-perc-srtp-ekt-diet.all@ietf.org, ietf@ietf.org, perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154007316490.13794.11476150183128445420@ietfa.amsl.com> Date: Sat, 20 Oct 2018 15:06:04 -0700 Archived-At: Subject: [Perc] Genart last call review of draft-ietf-perc-srtp-ekt-diet-09 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2018 22:06:05 -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 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. 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. 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. 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. 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? 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? 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. 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. 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. 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. 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. 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. 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? 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"). Q4-6_1: I think the text in section 4.6 should be placed in the Applicability section I suggested earlier (Q4_1). Q5_1: In section 5, I suggest to change the section name to "DTLS-SRTP Considerations". From nobody Mon Oct 22 12:47:27 2018 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B932A12D7EA; Mon, 22 Oct 2018 12:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 XTkuN9951WmT; Mon, 22 Oct 2018 12:47:21 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 AF2511292AD; Mon, 22 Oct 2018 12:47:18 -0700 (PDT) Received: from [10.0.1.27] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w9MJlHfX089140 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 22 Oct 2018 14:47:18 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.27] From: Ben Campbell Content-Type: multipart/signed; boundary="Apple-Mail=_7F2BB38A-A36D-415E-B8CF-935270FA782A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Message-Id: <8F9C11FD-9CCD-48DD-96E8-286CA2569626@nostrum.com> Date: Mon, 22 Oct 2018 14:47:16 -0500 Cc: perc@ietf.org To: draft-ietf-perc-private-media-framework.all@ietf.org X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: [Perc] AD Evaluation of draft-ietf-perc-private-media-framework-07 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 19:47:25 -0000 --Apple-Mail=_7F2BB38A-A36D-415E-B8CF-935270FA782A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, This is my AD Evaluation of draft-ietf-perc-private-media-framework-07. I appreciate all the work that has gone into this, but I think this = draft still needs some work before the IETF last call. I have some = substantive and significant editorial comments that I would like to = resolve prior to the LC. Thanks! Ben. ------------------------- Substantive Comments: =C2=A71, 2nd paragraph: This paragraph needs to tie the ideas together = better. It says the ability to deploy in virtual environments is an = advantage, but the rest of the paragraph seems to argue why doing so is = insecure. I _think_ the idea is to say that this draft helps improve = that security, thus helping remove a barrier to taking advantage of = virtual/cloud environments? If so, please say so. =C2=A72: Please use the new boilerplate from RFC 8174. There are = multiple uses of lower-case =E2=80=9Cmust=E2=80=9D and =E2=80=9Cshould=E2=80= =9D in the document that don=E2=80=99t appear to be intended as = normative. =C2=A72, definition of MD: It seems like this definition is a little too = focused on the PERC trust model, and leaves out the definition of it as = a middlebox that forwards the active stream without modification. (I = guess that=E2=80=99s caught in the reference to 7667, but it would be = better to include the core of the definition here, rather than imply it = by reference. =C2=A73.1.1: "The actual media content MUST NOT not be decryptable by a Media Distributor, so it is untrusted to have access to the E2E media encryption keys.=E2=80=9D I=E2=80=99m not sure that MUST NOT should be stated normatively, as = it=E2=80=99s really a statement of fact, or at least a foundational = assumption. =C2=A73.1.1, paragraph 3: "A Media Distributor MUST perform its role in = properly forwarding media packets while taking measures to mitigate the adverse effects of denial of service attacks (refer to Section 6), etc, to a level equal to or better than traditional conferencing (i.e. non-PERC) deployments.=E2=80=9D That requirement is too vague for a normative MUST. Consider leaving the = normative language to section 6. =C2=A73.1.2, last paragraph: "In any deployment scenario where the call = processing function is considered trusted, the call processing function MUST ensure the integrity of received messages before forwarding to other entities.=E2=80=9D= Please describe why that is important in a PERC environment. =C2=A74.2, first paragraph: "participants in the conference MUST keep track of the E2E keys=E2=80=9D This seems redundant to similar requirement in 4.3. The requirements in = 4.3 are more precise, so I suggest stating this one descriptively. =C2=A74.3: "prior E2E keys SHOULD be retained=E2=80=9D I think there=E2=80=99s some disagreement internal to this document, and = between this and EKT (and maybe double?). Please see related comment 0n = section 4.5.2: =C2=A74.4: First paragraph: "this framework requires that every packet = be authenticated=E2=80=9D: Is that a statement of fact that this = framework states a normative requirement elsewhere, or is it this = intended to be a normative requirement in itself? =C2=A74.4, 2nd paragraph: "Using hop-by-hop authentication gives the = Media Distributor the ability to change certain RTP header values.=E2=80=9D That=E2=80=99s not really a true statement. It=E2=80=99s the lack of E2E = authentication that enables that. It seems like the real point is that, = since we can=E2=80=99t use E2E authentication, HBH authentication is = better than nothing. =C2=A74.4, 3rd paragraph: "If there is a need to encrypt one or more RTP = header extensions hopby- hop, ...=E2=80=9D : Is that optional? =C2=A74.4, last paragraph: "Note that when RTP header extensions are = encrypted, all hops - in the untrusted domain at least - will need to decrypt and re-encrypt these encrypted header extensions.=E2=80=9D I=E2=80=99m confused by this; the document requires distinct keys for = each hop. is there an exception for trusted MDs? =C2=A74.5.1, - 2nd to last paragraph: "Endpoints MAY use the DTLSSRTP generated E2E key for transmission or MAY generate a fresh E2E key.=E2=80=9D: They have to do one or the other, right? That wording = allows then to do neither. - Last paragraph: It would be helpful to describe the security = associations involved. Do I understand correctly that an endpoint has an = SA with the KD, but not the MD? But peer MDs do have SAs with each = other? =C2=A74.5.2, 3rd paragraph: I think there=E2=80=99s some disagreement on the normative keywords for = delaying the switch to new keys. I discussed this offline with Richard, = and he replied with the following: > There's sort of a conflict here. The crux is here: >=20 > """ > Since it may take some time for all of the > endpoints in conference to finish re-keying, senders MUST delay a > short period of time before sending media encrypted with the new > master key, but it MUST be prepared to make use of the information > from a new inbound EKT Key immediately. > """ >=20 > The first part talks about media keys, which conflicts with EKT; it = should probably be deleted. The second part is about processing EKT = tags, and should be kept. So we probably end up with something like the = following: >=20 > """ > In order to allow time for all endpoints in the conference to = receive the new keys, > the sender should follow the recommendations in Section XXX of = [I-D.ietf-perc-srtp-ekt-diet]. > On receiving a new EKT Key, endpoints MUST be prepared to decrypt = EKT tags using the > new key. The EKT SPI field can be used to differentiate between = tags encrypted with > the old and new keys. > """ =C2=A75.2, 2nd paragraph: If the fingerprint is signed, does the entire = signaling network still need to be trusted? Also, should the reference = to 4474 be 8224? =C2=A76: This is written in forward-looking language about how the = framework needs to be designed. That design is complete now, what are = the considerations for it=E2=80=99s use as designed? Also, there are considerations for attacks other than DOS attacks, = right? =C2=A76.2.1: This section seems odd to me. I understand not trusting = the MD to keep communication confidential or to not tamper with it, etc. = But if the MD wants to deny service, it can find much easier ways. For = example, simply not forwarding packets. =C2=A7A.1: "Assuming the use of Double...=E2=80=9D Is that optional? - "The media distributor doesn=E2=80=99t perform DTLS-SRTP,...=E2=80=9D The document describes one case where it does (connections between peer = MDs) =C2=A7A.3: "To reduce complexity, PERC *RECOMMENDS* that endpoints create random SRTP master keys locally to be used for E2E encryption.=E2=80=9D Is RECOMMENDS intended as normative? If not, where is the actual = recommendation? Editorial Comments: - General: I found the draft to have some issues with flow and = fragmentation. I expected this draft give a big-picture overview tying = together the moving parts of PERC in a way that tells me how they work = together. I was surprised to find that the text that does that was = relegated to the appendices, which I usually see reserved for more = optional reading. I recommend promoting the appendix text into a = non-normative introduction. (If you follow this recommendation, please = edit that text for tone; it veers a bit too far on the casual side in = places for a standards track RFC.) - General: Please be consistent between using =E2=80=9CE2E" or = "end-to-end=E2=80=9D when referring to keys. (Same with HBH and = "hop-by-hop") - General: Please be consistent in using present vs future tense when = describing procedures. Present tense is usually more readable for that = sort of thing. =C2=A71, first paragraph: - "Instead, media flows transmitted by conference participants are simply forwarded by the Media Distributor to each of the other participants, often forwarding only a subset of flows based on voice activity detection or other criteria.=E2=80=9D The sentence seems to switch subjects half way through. Suggest breaking = into two sentences, with the second starting with =E2=80=9CMedia = Distributors often forward only a subset..=E2=80=9D =C2=A71, 2nd paragraph: This paragraph needs to tie the ideas together = better. It says the ability to deploy in virtual environments is an = advantage, but the rest of the paragraph seems to argue why doing so is = insecure. I _think_ the idea is to say that this draft helps improve = that security, thus helping remove a barrier to taking advantage of = virtual/cloud environments? If so, please say so. =C2=A73.1.1, 2nd paragraph: "An endpoint=E2=80=99s ability to join a = conference hosted by a Media Distributor MUST NOT alone be interpreted as being authorized to have access to the E2E media encryption keys, as the Media Distributor does not have the ability to determine whether an endpoint is authorized.=E2=80=9D MUST NOT be interpreted by what? (consider active voice). Also, I=E2=80=99= m not sure what it means for "the ability to join a conference" to be = authorized. Consider something to the effect of =E2=80=9C... to imply = that the endpoint is authorized...=E2=80=9D =C2=A74.1, first paragraph: "access of the end-to- end key information=E2=80=9D s/of/to =C2=A74.2, first paragraph: Please expand =E2=80=9CSSRC" on first = mention. =C2=A74.3: - 2nd paragraph:"Receiving endpoints MUST discard old E2E keys no later than when it leaves the conference.=E2=80=9D: singular/plural disagreement. -3rd paragraph:"an encryption key is derived=E2=80=9D: Derived by what? = (consider active voice). =C2=A74.4, section title: should =E2=80=9CHop Operations=E2=80=9D be = =E2=80=9CPer-hop Operations=E2=80=9D? =C2=A74.4, last paragraph: "an encryption key is derived=E2=80=9D: = derived by what? (consider active voice.) =C2=A74.5.2, last paragraph: "Endpoints are at liberty to change the E2E = encryption key used at any time. Endpoints MUST generate a new E2E encryption key whenever it receives a new EKT Key.=E2=80=9D To be consistent with the =E2=80=9CMUST" in the 2nd sentence, it seems = like =E2=80=9Care at liberty to=E2=80=9D should be =E2=80=9CMAY=E2=80=9D. =C2=A75: =E2=80=9CThe key requirements is...=E2=80=9D : plural = disagreement. =C2=A76.1, 2nd paragraph: "If not making use of HBH authentication on the Media Distributor, such an attack could only be detected in the receiving endpoints where the forged packets would finally be dropped.=E2=80=9D The sentence suggests that an attack might make use of HBH = authentication. I don=E2=80=99t think that=E2=80=99s the intent. =C2=A76.2.2: Missing article before =E2=80=9CReplay=E2=80=9D Appendix A: -- "The time required to retain old keys (either EKT Keys or SRTP master keys) is not specified, but they should be retained at least for the period of time required to re-key the conference or handle latearriving or out-of-order packets. A period of 60s should be considered a generous retention period, but endpoints may keep old keys on hand until the end of the conference.=E2=80=9D That should be stated in the main body. -- "Or more detailed explanation of each of the keys follows.=E2=80=9D Sentence fragment. Appendix B: It really seems like the packet format should go in the main body (if = it=E2=80=99s needed in this document at all.) Also, is there really anything called a PERC packet? That would be" SRTP = with double", or something like that, right? --Apple-Mail=_7F2BB38A-A36D-415E-B8CF-935270FA782A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlvOKUQACgkQgFZKbJXz 1A2zzxAAzj5J5HRXbLp5fPbOuSXFweCX3HGHnMGNtCDpttwhc1/bmxIEzT64tuVj MYjGzy800O0tXUGpo9yEyyO0nAyb8oXQNndY+IHl6rk7TkF5YESe6NusjUh6RiTk nJPgnpyDkiFdF4tUnyldFVEvMhNqqrfkqSFEOd0kdef9NraESYjBNBxyyhxQfhTS u+guxSG1/lO1ubo6tBSAO0gQbxa4AbCmM89qEr9Dy+UkJQA2/h52YsFjcE1lik9p VOSXBomV/RSjGyet2iu/OOBmBo86OjIbF+wgTbzVtv/srICaByj50qO1opTrbLcF eZGtu1e4pMPCblLy2LAPp/u3zsO/jkN/8RQh9m92yO/CbCVdrUAuleXaSds8pFjJ cil/48EtnttpnYq+GolTfz3v8Y2C87zlImCKykjYwvl5QEubmWAGuIhFw6NoWEUl k3LsK/PfN9/rGoXRh//UFpxlZLEklyGP+HqsIKQyuo3ZrPVnkYy20W4/Rv7REjU3 s8Wq3VewXdQ7VNwmC5KE22LAfx2Q3XHl3p3Rfh+M6zIVX/tVin6ArUt8QFm9aJsh utDb8SJotTdh0hFYISXGo3/B6bjD41Qf21hhXsqiZXCJB1gyJJ8Av9SguaqeRVBE GAJrtIrGmzNhvgebP3fQn3ScSvigILHHqlPVMqrQGD7R3SSNY0Q= =cIrq -----END PGP SIGNATURE----- --Apple-Mail=_7F2BB38A-A36D-415E-B8CF-935270FA782A--