From nobody Mon May 3 11:06:41 2021 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 E3D483A1EE6 for ; Mon, 3 May 2021 11:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.397 X-Spam-Level: X-Spam-Status: No, score=-4.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.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 cNQNmtRVH_DX for ; Mon, 3 May 2021 11:06:29 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D83D43A1EB4 for ; Mon, 3 May 2021 11:06:28 -0700 (PDT) Received: from authuser (localhost [127.0.0.1]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1620065186; bh=roZsqLe+xfKULkl6aoWW0c/cfbKw3HKM1TxNCdB22pM=; h=From:To:Subject:Date:In-Reply-To:References:Reply-To; b=p5729ZxSC8Tg2JwJu81FPRixoyA5oGEl7SsOV2c1k6LlzXwDBAaFXSx3w2krkXTxJ p7fTnyPyqXUhpOOVCkSNt26oKa2SNs1GW+qfNCZcIHV5vKuOMeshxQj9zZGQ5NGl1T Xq3ZJ5AK+lUZbXYq6cJZH4iT8zQbJqWay3PqYH0Y= From: "Paul E. Jones" To: "Russ Housley" , perc@ietf.org Date: Mon, 03 May 2021 18:06:20 +0000 Message-Id: In-Reply-To: References: Reply-To: "Paul E. Jones" User-Agent: eM_Client/8.2.1237.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB80A23DF4-59A6-4457-B6E4-BA0E542822F6" Archived-At: Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel 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, 03 May 2021 18:06:40 -0000 --------=_MB80A23DF4-59A6-4457-B6E4-BA0E542822F6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Russ, I apologize for the late reply. Reply below: ------ Original Message ------ From: "Russ Housley" To: perc@ietf.org Sent: 4/19/2021 2:19:17 PM Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel >Section 2: Your reference to BCP 14 does not include "NOT RECOMMENDED".=20 >Please use: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all > capitals, as shown here. Corrected. >Section 4: I do not know the meaning of "abbrev" in: "... inside abbrev=20 >"TunneledDtls" message." Please clarify. Should just be "a". That is a keyword used in the document template I=20 use, so I think my editor decided to expand that for me. Very odd,=20 indeed. >Section 5.3: Please reference Section 4.4 of [RFC4122] for random UUID=20 >creation. I'll make the change as you suggest. >Section 5.4 says: "The key distributor MUST correlate the certificate=20 >fingerprint ...". What does correlate mean? I was expecting a=20 >requirement for exact match? What hash algorithm(s) are used for=20 >fingerprints? Match is a better word. I don't think we should prescribe hashing=20 algorithms to use in this document. >Section 6.1: MKI is optional in RFC 3711. What is carried in MediaKeys=20 >when there is no MKI present? MediaKeys is a structure with a number of elements inside, and MKI is=20 optional. The other things include an association ID, SRTP protection=20 profile, master keys, and salt values. >NITS: > >The document uses "hop-by-hop" and "HBH" in many places. Please pick=20 >one and use it everywhere. OK, will do. Thanks! Paul > > > > >Russ > >>On Apr 1, 2021, at 4:44 PM, Suhas Nandakumar =20 >>wrote: >> >>Hello All >>We totally missed on finishing one last Informational WG document : "DTLS = Tunnel between a Media Distributor and Key Distributor to Facilitate Key E= xchange" >>This is an announcement for the WGLC for the same, the document is availa= ble for inspection here: >>https://datatracker.ietf.org/doc/html/draft-ietf-perc-dtls-tunnel-07 >> >>Please help review the document and send your comments by April 16, 2021= . >> >>Please Note there are IPR declaration at https://datatracker.ietf.org/ipr= /search/?submit=3Ddraft&id=3Ddraft-ietf-perc-dtls-tunnel >> >>Suhas Nandakumar >>For the Chairs > --------=_MB80A23DF4-59A6-4457-B6E4-BA0E542822F6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Russ,

I apologize for the late reply.=C2=A0 Reply below:

------ Original Message ------
From: "Russ Housley" <housl= ey@vigilsec.com>
Sent: 4/19/2021 2:19:17 PM
Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel

Section 2: Your reference to BCP 14 does not include "NOT R= ECOMMENDED". Please use:

=C2=A0 =C2=A0The key words "MUST", "MUST NOT", "REQUIRED", "SHALL= ", "SHALL NOT",
=C2=A0 =C2=A0"SHOULD", "SHOULD NOT", "= RECOMMENDED", "NOT RECOMMENDED", "MAY", and
=C2=A0 =C2= =A0"OPTIONAL" in this document are to be interpreted as described in
<= div class=3D"">=C2=A0 =C2=A0BCP 14 [RFC2119] [RFC8174] when, and only when, = they appear in all
=C2=A0 =C2=A0capitals, as shown he= re.

Corrected.

Sectio= n 4: I do not know the meaning of "abbrev" in: "...=C2=A0inside abbrev "Tun= neledDtls" message." =C2=A0Please clarify.

Should just be "a".=C2=A0 That is a keyword used in the d= ocument template I use, so I think my editor decided to expand that for me.= =C2=A0 Very odd, indeed.
<= br />

Section 5.3: Please reference Section 4.4 of [RFC4122] for = random UUID creation.

I'= ll make the change as you suggest.


Section 5.4 says: "The key distributor MUST cor= relate the certificate fingerprint ...". =C2=A0What does correlate mean?= =C2=A0I was expecting a requirement for exact match? =C2=A0What hash algorith= m(s) are used for fingerprints?

Match is a better word.=C2=A0 I don't think we should prescribe hash= ing algorithms to use in this document.


<= span style=3D"font-size: 11pt;">Section 6.1: MKI is optional in RFC 3711. = =C2=A0What is carried in=C2=A0MediaKeys when there is no MKI present?

MediaKeys is a structure with = a number of elements inside, and MKI is optional.=C2=A0 The other things i= nclude an association ID, SRTP protection profile, master keys, and salt va= lues.

NITS:

<= div class=3D"">The document uses "hop-by-hop" and "HBH" in many places. =C2= =A0Please pick one and use it everywhere.

OK, will do.

Thanks!
Paul







Russ

On Apr 1, 202= 1, at 4:44 PM, Suhas Nandakumar <suhasietf@gmail.com> wrote:

Hello All
We tot= ally missed on finishing one last Informational WG document : "DTLS Tunnel= between a Media Distributor and Key Distributor to Facilitate Key Exchange"=
This is an announcement for the WGLC for the same, the d=
ocument is available for inspection here:
https://datatra=
cker.ietf.org/doc/html/draft-ietf-perc-dtls-tunnel-07

Please help review the document and send your comments by  Ap=
ril 16, 2021.

Please Note there are IPR declaration at=C2=A0https://datatracker.=
ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf-perc-dtls-tunnel

Suhas Nandakumar
For the Chairs

--------=_MB80A23DF4-59A6-4457-B6E4-BA0E542822F6-- From nobody Mon May 3 11:15:20 2021 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 812263A1F1F for ; Mon, 3 May 2021 11:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.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 9zvC9Q_5x2w8 for ; Mon, 3 May 2021 11:15:13 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87DAB3A1F17 for ; Mon, 3 May 2021 11:15:13 -0700 (PDT) Received: from authuser (localhost [127.0.0.1]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1620065711; bh=/gWVclU/T0jMARrxJC9LZWwz0OHpC3ynyjkDy9Dag1A=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=m/m19qS200PRXRKTD0E79FnjHtEBzfqaACYWWJNaVdel7nqAKOZZJNSqFsOnRmUck 8elgyJgR99bRnXsoxc53YzKvZlkDrIffIv6FW39fxGsar+0lqIvoAGQYW+SMY6Sp8j D6qEKJoOHUPb6v9217bdEPWCZ8hwPr5LfMBo3G/E= From: "Paul E. Jones" To: "Cullen Jennings" , perc@ietf.org Cc: "Suhas Nandakumar" Date: Mon, 03 May 2021 18:15:07 +0000 Message-Id: In-Reply-To: <84CD7A1C-C383-48F4-95D5-2561F6694E9C@iii.ca> References: <84CD7A1C-C383-48F4-95D5-2561F6694E9C@iii.ca> Reply-To: "Paul E. Jones" User-Agent: eM_Client/8.2.1237.0 Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel 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, 03 May 2021 18:15:19 -0000 Cullen, Comments below: ------ Original Message ------ From: "Cullen Jennings" To: perc@ietf.org Cc: "Suhas Nandakumar" ; "Paul Jones"=20 Sent: 4/26/2021 7:26:35 PM Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel > >This document is easy to understand and very detailed. I think it is ready = for publication. > >There are a few small changes I would recommend: > >1. The way SDP is used, I think RFC 4566 needs to be a normative reference = ( it is currently an informative reference ) OK, I'll move that reference. >2. I would sugest that the IANA section say that the update procedure for= the table is "IETF Review" as defined in RFC 8126. (and add normative ref). = This is not much of a change from what is there but I think it makes it mo= re concrete and clear. OK, I'll make that comment. > >3. In section 5.1 when talking about the tls-id, the document should inclu= de a normative reference to RFC 8842 I'll update that, as well as the other draft reference that is now an=20 RFC. Thanks! Paul From nobody Mon May 3 11:19:29 2021 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 2F5DB3A1F3B for ; Mon, 3 May 2021 11:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 EcQxlgqkAl2t for ; Mon, 3 May 2021 11:19:23 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149763A1F3E for ; Mon, 3 May 2021 11:19:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1D202300BE4 for ; Mon, 3 May 2021 14:19:21 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id A9eTRYwRIS5t for ; Mon, 3 May 2021 14:19:16 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id DFCC3300BDE; Mon, 3 May 2021 14:19:15 -0400 (EDT) From: Russ Housley Message-Id: <9890A9B8-1B59-449A-A049-2A6941AD4691@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_05FBAF7F-0CDF-46D7-AB51-4EB568BB89C8" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\)) Date: Mon, 3 May 2021 14:19:16 -0400 In-Reply-To: Cc: perc@ietf.org To: "Paul E. Jones" References: X-Mailer: Apple Mail (2.3445.104.20) Archived-At: Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel 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, 03 May 2021 18:19:28 -0000 --Apple-Mail=_05FBAF7F-0CDF-46D7-AB51-4EB568BB89C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> Section 6.1: MKI is optional in RFC 3711. What is carried in = MediaKeys when there is no MKI present? >=20 > MediaKeys is a structure with a number of elements inside, and MKI is = optional. The other things include an association ID, SRTP protection = profile, master keys, and salt values. You answered the wrong question. I know that there are other elements = in MediaKeys. However, if the MKI element is absent, what is used in = Section 6.1. Russ --Apple-Mail=_05FBAF7F-0CDF-46D7-AB51-4EB568BB89C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Section 6.1: MKI is optional in = RFC 3711.  What is carried in MediaKeys when there is no MKI = present?

MediaKeys is a structure with a number of elements inside, = and MKI is optional.  The other things include an association ID, = SRTP protection profile, master keys, and salt = values.

You answered = the wrong question.  I know that there are other elements in = MediaKeys.  However, if the MKI element is absent, what is used in = Section 6.1.

Russ

= --Apple-Mail=_05FBAF7F-0CDF-46D7-AB51-4EB568BB89C8-- From nobody Mon May 3 12:05:52 2021 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 CE6C13A07F0 for ; Mon, 3 May 2021 12:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.398 X-Spam-Level: X-Spam-Status: No, score=-4.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.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 bE6BiID9pYLU for ; Mon, 3 May 2021 12:05:45 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA23D3A07EA for ; Mon, 3 May 2021 12:05:45 -0700 (PDT) Received: from authuser (localhost [127.0.0.1]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1620068739; bh=EF6vO/CUm4QT3ubCHygqGzRvw0oP3U40Ak4XaUjZcJQ=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=Y733hNVqjTpeQFiig1/529rw0jnvx6Z23+9BSEVmeC39HL9Fx01c8XlErgN5JLHfH j6hbeIjG6sZWz1aaEZ0Xnq9khhHIgPU0VGZqQ6xsCICM4AsIxDjO5yuS8y9MbmkF7a LiqaFA/tIh4XZas9urRz/CT4/3dUrFjAvpFm/1To= From: "Paul E. Jones" To: "Russ Housley" Cc: perc@ietf.org Date: Mon, 03 May 2021 19:05:36 +0000 Message-Id: In-Reply-To: <9890A9B8-1B59-449A-A049-2A6941AD4691@vigilsec.com> References: <9890A9B8-1B59-449A-A049-2A6941AD4691@vigilsec.com> Reply-To: "Paul E. Jones" User-Agent: eM_Client/8.2.1237.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBB851AAB3-362B-4C13-8970-72F42AEB82A5" Archived-At: Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel 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, 03 May 2021 19:05:51 -0000 --------=_MBB851AAB3-362B-4C13-8970-72F42AEB82A5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Russ, The MediaKeys structure would carry all the other useful bits for SRTP=20 keying material even if the MediaKeys.mki field contains no data. I=20 guess I still do not understand the question. Paul ------ Original Message ------ From: "Russ Housley" To: "Paul E. Jones" Cc: perc@ietf.org Sent: 5/3/2021 2:19:16 PM Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel > >>>Section 6.1: MKI is optional in RFC 3711. What is carried in=20 >>>MediaKeys when there is no MKI present? >> >>MediaKeys is a structure with a number of elements inside, and MKI is=20 >>optional. The other things include an association ID, SRTP protection=20 >>profile, master keys, and salt values. > >You answered the wrong question. I know that there are other elements=20 >in MediaKeys. However, if the MKI element is absent, what is used in=20 >Section 6.1. > >Russ > --------=_MBB851AAB3-362B-4C13-8970-72F42AEB82A5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Russ,

The MediaKeys structure would carry all the other useful=C2=A0<= span>bits=C2=A0for SRTP keying material even if t= he MediaKeys.mki field contains no data.=C2=A0=C2=A0I guess I= still do not understand the question.

<= /div>
Paul

------ Original Message ------
To: "Paul E. Jones" <paule= j@packetizer.com>
Sent: 5/3/2021 2:19:16 PM
Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel


= Section 6.1: MKI is optional in RFC 3711. =C2=A0What is carried in=C2=A0Med= iaKeys when there is no MKI present?

MediaKeys is a structure with= a number of elements inside, and MKI is optional.=C2=A0 The other things in= clude an association ID, SRTP protection profile, master keys, and salt val= ues.

You answered the w= rong question. =C2=A0I know that there are other elements in MediaKeys. =C2= =A0However, if the MKI element is absent, what is used in Section 6.1.

Russ

--------=_MBB851AAB3-362B-4C13-8970-72F42AEB82A5-- From nobody Mon May 3 13:12:34 2021 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 825F43A0D9A for ; Mon, 3 May 2021 13:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 ffrcGeheyy9b for ; Mon, 3 May 2021 13:12:27 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A51C3A0D97 for ; Mon, 3 May 2021 13:12:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D42A8300BE2 for ; Mon, 3 May 2021 16:12:25 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gMK18yLaRmbt for ; Mon, 3 May 2021 16:12:20 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 6C271300AEF; Mon, 3 May 2021 16:12:20 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D8298B39-F7B5-4E22-8762-3939688E7811" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\)) Date: Mon, 3 May 2021 16:12:20 -0400 In-Reply-To: Cc: perc@ietf.org To: "Paul E. Jones" References: <9890A9B8-1B59-449A-A049-2A6941AD4691@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.20) Archived-At: Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel 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, 03 May 2021 20:12:33 -0000 --Apple-Mail=_D8298B39-F7B5-4E22-8762-3939688E7811 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Paul: Section 6.1 says: struct { uuid association_id; SRTPProtectionProfile protection_profile; opaque mki<0..255>; opaque client_write_SRTP_master_key<1..255>; opaque server_write_SRTP_master_key<1..255>; opaque client_write_SRTP_master_salt<1..255>; opaque server_write_SRTP_master_salt<1..255>; } MediaKeys; If the MRI is absent, I am assuming that a zero-length value goes in = this structure, but the spec does not say one way or the other. If the MRI is absent, then there is not anything that is present here to = provide binding. Russ > On May 3, 2021, at 3:05 PM, Paul E. Jones = wrote: >=20 > Russ, >=20 > The MediaKeys structure would carry all the other useful bits for SRTP = keying material even if the MediaKeys.mki field contains no data. I = guess I still do not understand the question. >=20 > Paul >=20 > ------ Original Message ------ > From: "Russ Housley" > > To: "Paul E. Jones" > > Cc: perc@ietf.org > Sent: 5/3/2021 2:19:16 PM > Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel >=20 >>=20 >>>> Section 6.1: MKI is optional in RFC 3711. What is carried in = MediaKeys when there is no MKI present? >>>=20 >>> MediaKeys is a structure with a number of elements inside, and MKI = is optional. The other things include an association ID, SRTP = protection profile, master keys, and salt values. >>=20 >> You answered the wrong question. I know that there are other = elements in MediaKeys. However, if the MKI element is absent, what is = used in Section 6.1. >>=20 >> Russ --Apple-Mail=_D8298B39-F7B5-4E22-8762-3939688E7811 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Paul:

Section 6.1 says:

   struct {
       uuid association_id;
       SRTPProtectionProfile = protection_profile;
      =  opaque mki<0..255>;
    =    opaque = client_write_SRTP_master_key<1..255>;
  =      opaque = server_write_SRTP_master_key<1..255>;
  =      opaque = client_write_SRTP_master_salt<1..255>;
  =      opaque = server_write_SRTP_master_salt<1..255>;
  =  } MediaKeys;

If the MRI is absent, I am assuming that a zero-length value = goes in this structure, but the spec does not say one way or the = other.

If the = MRI is absent, then there is not anything that is present here to = provide binding.

Russ


On May = 3, 2021, at 3:05 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Russ,

The MediaKeys structure would carry all the other = useful bits for SRTP keying material even = if the MediaKeys.mki field contains no data.  I guess I still do not understand the = question.

Paul

------ = Original Message ------
From: "Russ Housley" <housley@vigilsec.com>
To: = "Paul E. Jones" <paulej@packetizer.com>
Sent: 5/3/2021 2:19:16 PM
Subject: Re: [Perc] WGLC for = draft-ietf-perc-dtls-tunnel


Section 6.1: MKI is optional in RFC 3711. =  What is carried in MediaKeys when there is no MKI = present?

MediaKeys is a structure with a number = of elements inside, and MKI is optional.  The other things include = an association ID, SRTP protection profile, master keys, and salt = values.

You = answered the wrong question.  I know that there are other elements = in MediaKeys.  However, if the MKI element is absent, what is used = in Section 6.1.

Russ

= --Apple-Mail=_D8298B39-F7B5-4E22-8762-3939688E7811-- From nobody Mon May 3 13:32:19 2021 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 F21863A0EA0; Mon, 3 May 2021 13:32:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suhas Nandakumar via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Cc: iesg-secretary@ietf.org, perc-chairs@ietf.org, perc@ietf.org, suhasietf@gmail.com Message-ID: <162007393697.23922.15931583160742200508@ietfa.amsl.com> Date: Mon, 03 May 2021 13:32:16 -0700 Archived-At: Subject: [Perc] Publication has been requested for draft-ietf-perc-dtls-tunnel-07 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: Mon, 03 May 2021 20:32:17 -0000 Suhas Nandakumar has requested publication of draft-ietf-perc-dtls-tunnel-07 as Informational on behalf of the PERC working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-perc-dtls-tunnel/ From nobody Mon May 3 13:46:31 2021 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 174493A104A for ; Mon, 3 May 2021 13:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.397 X-Spam-Level: X-Spam-Status: No, score=-4.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.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 5fsObLu3HFRj for ; Mon, 3 May 2021 13:46:25 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8CED3A1045 for ; Mon, 3 May 2021 13:46:25 -0700 (PDT) Received: from authuser (localhost [127.0.0.1]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1620074774; bh=N8ESuy8bV1lpFN/Atj9E4qZ9Llyx0XEvW5P+iCU7D7E=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=i1PLWB92TkfUhuoioIKnzOJhbdXnvmF5gFNz47A/wLpfoZnD5i98+MkgPux5KkWhi cN3+btqjb41AMIT4F6sEONRNAzSB9trUpbXF6ifTp+WJEVR1RxYcXFFIdOn/z6dWgV shN+BPEJiv0TugpJVpiDJNAHDmTN9GX9qpkWhXQo= From: "Paul E. Jones" To: "Russ Housley" Cc: perc@ietf.org Date: Mon, 03 May 2021 20:46:10 +0000 Message-Id: In-Reply-To: References: <9890A9B8-1B59-449A-A049-2A6941AD4691@vigilsec.com> Reply-To: "Paul E. Jones" User-Agent: eM_Client/8.2.1237.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBAE4D4DC4-F6D0-4C21-876F-1906F91BA0C4" Archived-At: Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel 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, 03 May 2021 20:46:30 -0000 --------=_MBAE4D4DC4-F6D0-4C21-876F-1906F91BA0C4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Russ, The zero-length would indicate there is no MKI. Section 5.4 mentions=20 the values in that structure and says "MKI value (if any)". The field=20 itself cannot be optional in the syntax (as far as I know), but a=20 zero-length would indicate there is no value present. There is a=20 one-octet length field that would be set to zero. Are you suggesting a=20 different syntax or an explicit statement in the MKI field description=20 that says "a zero-length MKI value indicates absence of an MKI value" or=20 similar? Paul ------ Original Message ------ From: "Russ Housley" To: "Paul E. Jones" Cc: perc@ietf.org Sent: 5/3/2021 4:12:20 PM Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel >Paul: > >Section 6.1 says: > > struct { > uuid association_id; > SRTPProtectionProfile protection_profile; > opaque mki<0..255>; > opaque client_write_SRTP_master_key<1..255>; > opaque server_write_SRTP_master_key<1..255>; > opaque client_write_SRTP_master_salt<1..255>; > opaque server_write_SRTP_master_salt<1..255>; > } MediaKeys; > >If the MRI is absent, I am assuming that a zero-length value goes in=20 >this structure, but the spec does not say one way or the other. > >If the MRI is absent, then there is not anything that is present here=20 >to provide binding. > >Russ > > >>On May 3, 2021, at 3:05 PM, Paul E. Jones =20 >>wrote: >> >>Russ, >> >>The MediaKeys structure would carry all the other useful bits for SRTP=20 >>keying material even if the MediaKeys.mki field contains no data. I=20 >>guess I still do not understand the question. >> >>Paul >> >>------ Original Message ------ >>From: "Russ Housley" >>To: "Paul E. Jones" >>Cc: perc@ietf.org >>Sent: 5/3/2021 2:19:16 PM >>Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel >> >>> >>>>>Section 6.1: MKI is optional in RFC 3711. What is carried in=20 >>>>>MediaKeys when there is no MKI present? >>>> >>>>MediaKeys is a structure with a number of elements inside, and MKI=20 >>>>is optional. The other things include an association ID, SRTP=20 >>>>protection profile, master keys, and salt values. >>> >>>You answered the wrong question. I know that there are other=20 >>>elements in MediaKeys. However, if the MKI element is absent, what=20 >>>is used in Section 6.1. >>> >>>Russ > --------=_MBAE4D4DC4-F6D0-4C21-876F-1906F91BA0C4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Russ,

The zero-length would indicate there is no MKI.=C2=A0 Section 5= .4 mentions the values in that structure and says "MKI value (if any)".=C2= =A0 The field itself cannot be optional in the syntax (as far as I know), b= ut a zero-length would indicate there is no value present.=C2=A0 There is a = one-octet length field that would be set to zero.=C2=A0 Are you suggesting = a different syntax or an explicit statement in the MKI field description t= hat says "a zero-length MKI value indicates absence of an MKI value" or sim= ilar?

Paul

------ Original Message ------
From: "Russ Housley" <housl= ey@vigilsec.com>
To: "Paul E. Jones" <paule= j@packetizer.com>
Sent: 5/3/2021 4:12:20 PM
Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel

Paul:

Section 6.1 say= s:

= =C2=A0 =C2=A0struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0uuid= association_id;
=C2=A0 =C2=A0 =C2=A0 =C2=A0SRTPProtect= ionProfile protection_profile;
=C2=A0 =C2=A0 =C2=A0= =C2=A0opaque mki<0..255>;
=C2=A0 =C2=A0 =C2=A0 =C2= =A0opaque client_write_SRTP_master_key<1..255>;
= =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque server_write_SRTP_master_key<1..255>= ;;
=C2=A0 =C2=A0 =C2=A0 =C2=A0opaque client_write_SRTP= _master_salt<1..255>;
=C2=A0 =C2=A0 =C2=A0 =C2= =A0opaque server_write_SRTP_master_salt<1..255>;
=C2=A0 =C2=A0} MediaKeys;

If the MRI is absent, I am assuming that a zero-length value go= es in this structure, but the spec does not say one way or the other.
=

If the MRI is absent= , then there is not anything that is present here to provide binding.
=

Russ


On May 3, 2021, at 3:05 PM, Paul E. Jones <= paulej@packetizer.com> wrote:

Russ,

The MediaKeys structure wou= ld carry all the other useful=C2=A0bits=C2=A0for SRTP keying material even if the Me= diaKeys.mki field contains no data.=C2=A0=C2=A0I gu= ess I still do not understand the question.

Paul
<= br class=3D"" />
------ Original Message ------
To: "Paul E. Jones" <paulej@packetizer.com>
Sent: = 5/3/2021 2:19:16 PM
Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel


Section 6.1: MKI is optional in RFC 3= 711. =C2=A0What is carried in=C2=A0MediaKeys when there is no MKI present?<= /span>

MediaKeys is a structure with a number of elements inside, and MK= I is optional.=C2=A0 The other things include an association ID, SRTP prote= ction profile, master keys, and salt values.

You answered the wrong question. =C2=A0I k= now that there are other elements in MediaKeys. =C2=A0However, if the MKI e= lement is absent, what is used in Section 6.1.

Russ

--------=_MBAE4D4DC4-F6D0-4C21-876F-1906F91BA0C4-- From nobody Mon May 3 13:51:36 2021 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 D80F23A0B69 for ; Mon, 3 May 2021 13:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 tX8X5GbWCn3i for ; Mon, 3 May 2021 13:51:30 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ED913A107D for ; Mon, 3 May 2021 13:51:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 09158300B82 for ; Mon, 3 May 2021 16:51:29 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id EROpucaI4-ln for ; Mon, 3 May 2021 16:51:23 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 4E379300AEF; Mon, 3 May 2021 16:51:23 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9ECE6F43-FE24-4958-967D-5DA03778225C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\)) Date: Mon, 3 May 2021 16:51:23 -0400 In-Reply-To: Cc: perc@ietf.org To: "Paul E. Jones" References: <9890A9B8-1B59-449A-A049-2A6941AD4691@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.20) Archived-At: Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel 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, 03 May 2021 20:51:35 -0000 --Apple-Mail=_9ECE6F43-FE24-4958-967D-5DA03778225C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Paul: Yes, I think that an explicit statement is needed. I am not suggesting = a syntax change. However, if the MRI is absent, there may be something = to say in the security considerations. Russ > On May 3, 2021, at 4:46 PM, Paul E. Jones = wrote: >=20 > Russ, >=20 > The zero-length would indicate there is no MKI. Section 5.4 mentions = the values in that structure and says "MKI value (if any)". The field = itself cannot be optional in the syntax (as far as I know), but a = zero-length would indicate there is no value present. There is a = one-octet length field that would be set to zero. Are you suggesting a = different syntax or an explicit statement in the MKI field description = that says "a zero-length MKI value indicates absence of an MKI value" or = similar? >=20 > Paul >=20 > ------ Original Message ------ > From: "Russ Housley" > > To: "Paul E. Jones" > > Cc: perc@ietf.org > Sent: 5/3/2021 4:12:20 PM > Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel >=20 >> Paul: >>=20 >> Section 6.1 says: >>=20 >> struct { >> uuid association_id; >> SRTPProtectionProfile protection_profile; >> opaque mki<0..255>; >> opaque client_write_SRTP_master_key<1..255>; >> opaque server_write_SRTP_master_key<1..255>; >> opaque client_write_SRTP_master_salt<1..255>; >> opaque server_write_SRTP_master_salt<1..255>; >> } MediaKeys; >>=20 >> If the MRI is absent, I am assuming that a zero-length value goes in = this structure, but the spec does not say one way or the other. >>=20 >> If the MRI is absent, then there is not anything that is present here = to provide binding. >>=20 >> Russ >>=20 >>=20 >>> On May 3, 2021, at 3:05 PM, Paul E. Jones > wrote: >>>=20 >>> Russ, >>>=20 >>> The MediaKeys structure would carry all the other useful bits for = SRTP keying material even if the MediaKeys.mki field contains no data. = I guess I still do not understand the question. >>>=20 >>> Paul >>>=20 >>> ------ Original Message ------ >>> From: "Russ Housley" > >>> To: "Paul E. Jones" > >>> Cc: perc@ietf.org >>> Sent: 5/3/2021 2:19:16 PM >>> Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel >>>=20 >>>>=20 >>>>>> Section 6.1: MKI is optional in RFC 3711. What is carried in = MediaKeys when there is no MKI present? >>>>>=20 >>>>> MediaKeys is a structure with a number of elements inside, and MKI = is optional. The other things include an association ID, SRTP = protection profile, master keys, and salt values. >>>>=20 >>>> You answered the wrong question. I know that there are other = elements in MediaKeys. However, if the MKI element is absent, what is = used in Section 6.1. >>>>=20 >>>> Russ --Apple-Mail=_9ECE6F43-FE24-4958-967D-5DA03778225C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Paul:

Yes, = I think that an explicit statement is needed.  I am not suggesting = a syntax change.  However, if the MRI is absent, there may be = something to say in the security considerations.

Russ


On May 3, 2021, at 4:46 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Russ,

The zero-length would indicate there is no MKI.  = Section 5.4 mentions the values in that structure and says "MKI value = (if any)".  The field itself cannot be optional in the syntax (as = far as I know), but a zero-length would indicate there is no value = present.  There is a one-octet length field that would be set to = zero.  Are you suggesting a different syntax or an explicit = statement in the MKI field description that says "a zero-length MKI = value indicates absence of an MKI value" or similar?

Paul

------ Original Message ------
From: "Russ Housley" <housley@vigilsec.com>
To: = "Paul E. Jones" <paulej@packetizer.com>
Sent: 5/3/2021 4:12:20 PM
Subject: Re: [Perc] WGLC for = draft-ietf-perc-dtls-tunnel

Paul:

Section 6.1 says:

   struct = {
       uuid = association_id;
      =  SRTPProtectionProfile protection_profile;
       opaque = mki<0..255>;
      =  opaque client_write_SRTP_master_key<1..255>;
       opaque = server_write_SRTP_master_key<1..255>;
  =      opaque = client_write_SRTP_master_salt<1..255>;
  =      opaque = server_write_SRTP_master_salt<1..255>;
  =  } MediaKeys;

If the MRI is absent, I am assuming that a zero-length value = goes in this structure, but the spec does not say one way or the = other.

If the = MRI is absent, then there is not anything that is present here to = provide binding.

Russ


On May 3, 2021, at 3:05 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Russ,

The MediaKeys structure would carry all the other = useful bits for SRTP keying material even = if the MediaKeys.mki field contains no data.  I guess I still do not understand the = question.

Paul

------ Original = Message ------
From: "Russ Housley" <housley@vigilsec.com>
To: "Paul E. Jones" <paulej@packetizer.com>
Sent: 5/3/2021 2:19:16 PM
Subject: Re: [Perc] WGLC for = draft-ietf-perc-dtls-tunnel


Section 6.1: MKI is optional in RFC 3711. =  What is carried in MediaKeys when there is no MKI = present?

MediaKeys is a structure with a number = of elements inside, and MKI is optional.  The other things include = an association ID, SRTP protection profile, master keys, and salt = values.

You = answered the wrong question.  I know that there are other elements = in MediaKeys.  However, if the MKI element is absent, what is used = in Section 6.1.

Russ

= --Apple-Mail=_9ECE6F43-FE24-4958-967D-5DA03778225C-- From nobody Mon May 3 14:00:11 2021 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 400C83A10E6 for ; Mon, 3 May 2021 14:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.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 Put8xLyTpZ67 for ; Mon, 3 May 2021 14:00:04 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F263E3A10E3 for ; Mon, 3 May 2021 14:00:03 -0700 (PDT) Received: from authuser (localhost [127.0.0.1]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1620075598; bh=LtFCaXC0ernK1B7L70uhxK3exL8FIM0337eTgvgBsdI=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=hZKHshxTit5esmB52CmV27kUxFNgAx4HcYcTYc/OVftz9uUZVyZQPy8Wr3wxQDsW2 ajRm8DDtxl5vZ90uYnDJC1/jIs96frtcNIkoqrRzDxxOrLq6epA56Wufp/3YS4f1yM loys/WdU1cdeIl4vNM4XknLCC2N2yCj48Gbb36nI= From: "Paul E. Jones" To: "Russ Housley" Cc: perc@ietf.org Date: Mon, 03 May 2021 20:59:54 +0000 Message-Id: In-Reply-To: References: <9890A9B8-1B59-449A-A049-2A6941AD4691@vigilsec.com> Reply-To: "Paul E. Jones" User-Agent: eM_Client/8.2.1237.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBBEDAE807-556A-4D13-80FE-ADB570FE8457" Archived-At: Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel 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, 03 May 2021 21:00:09 -0000 --------=_MBBEDAE807-556A-4D13-80FE-ADB570FE8457 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Russ, OK, I'll add this to the syntax section: "A zero-length field indicates that no MKI value is present." What security consideration do you think is needed? Presence or=20 absence, either way, is normal. Paul ------ Original Message ------ From: "Russ Housley" To: "Paul E. Jones" Cc: perc@ietf.org Sent: 5/3/2021 4:51:23 PM Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel >Paul: > >Yes, I think that an explicit statement is needed. I am not suggesting=20 >a syntax change. However, if the MRI is absent, there may be something=20 >to say in the security considerations. > >Russ > > >>On May 3, 2021, at 4:46 PM, Paul E. Jones =20 >>wrote: >> >>Russ, >> >>The zero-length would indicate there is no MKI. Section 5.4 mentions=20 >>the values in that structure and says "MKI value (if any)". The field=20 >>itself cannot be optional in the syntax (as far as I know), but a=20 >>zero-length would indicate there is no value present. There is a=20 >>one-octet length field that would be set to zero. Are you suggesting=20 >>a different syntax or an explicit statement in the MKI field=20 >>description that says "a zero-length MKI value indicates absence of an=20 >>MKI value" or similar? >> >>Paul >> >>------ Original Message ------ >>From: "Russ Housley" >>To: "Paul E. Jones" >>Cc: perc@ietf.org >>Sent: 5/3/2021 4:12:20 PM >>Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel >> >>>Paul: >>> >>>Section 6.1 says: >>> >>> struct { >>> uuid association_id; >>> SRTPProtectionProfile protection_profile; >>> opaque mki<0..255>; >>> opaque client_write_SRTP_master_key<1..255>; >>> opaque server_write_SRTP_master_key<1..255>; >>> opaque client_write_SRTP_master_salt<1..255>; >>> opaque server_write_SRTP_master_salt<1..255>; >>> } MediaKeys; >>> >>>If the MRI is absent, I am assuming that a zero-length value goes in=20 >>>this structure, but the spec does not say one way or the other. >>> >>>If the MRI is absent, then there is not anything that is present here=20 >>>to provide binding. >>> >>>Russ >>> >>> >>>>On May 3, 2021, at 3:05 PM, Paul E. Jones =20 >>>>wrote: >>>> >>>>Russ, >>>> >>>>The MediaKeys structure would carry all the other useful bits for=20 >>>>SRTP keying material even if the MediaKeys.mki field contains no=20 >>>>data. I guess I still do not understand the question. >>>> >>>>Paul >>>> >>>>------ Original Message ------ >>>>From: "Russ Housley" >>>>To: "Paul E. Jones" >>>>Cc: perc@ietf.org >>>>Sent: 5/3/2021 2:19:16 PM >>>>Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel >>>> >>>>> >>>>>>>Section 6.1: MKI is optional in RFC 3711. What is carried in=20 >>>>>>>MediaKeys when there is no MKI present? >>>>>> >>>>>>MediaKeys is a structure with a number of elements inside, and MKI=20 >>>>>>is optional. The other things include an association ID, SRTP=20 >>>>>>protection profile, master keys, and salt values. >>>>> >>>>>You answered the wrong question. I know that there are other=20 >>>>>elements in MediaKeys. However, if the MKI element is absent, what=20 >>>>>is used in Section 6.1. >>>>> >>>>>Russ > --------=_MBBEDAE807-556A-4D13-80FE-ADB570FE8457 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Russ,

OK, I'll add this to the syntax section:

=
"A zero-length field indicates that =C2=A0no MKI value is present."

What security consideration do you think is needed?= =C2=A0 Presence or absence, either way, is normal.

Paul

------ Original Message ------
From: "Russ Housley" <housl= ey@vigilsec.com>
To: "Paul E. Jones" <paule= j@packetizer.com>
Sent: 5/3/2021 4:51:23 PM
Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel

Paul:

Yes, I think th= at an explicit statement is needed. =C2=A0I am not suggesting a syntax chan= ge. =C2=A0However, if the MRI is absent, there may be something to say in t= he security considerations.

Russ


On May 3, 2021, at= 4:46 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Russ,
=
The zero-length would indicate there is no MKI.=C2=A0 Section 5.4 mention= s the values in that structure and says "MKI value (if any)".=C2=A0 The fie= ld itself cannot be optional in the syntax (as far as I know), but a zero-l= ength would indicate there is no value present.=C2=A0 There is a one-octet= length field that would be set to zero.=C2=A0 Are you suggesting a differen= t syntax or an explicit statement in the MKI field description that says "a = zero-length MKI value indicates absence of an MKI value" or similar?
=

Paul

------ Original Message ----= --
From: "Russ H= ousley" <housley@vigi= lsec.com>
To: "Paul E. Jones" <paulej@packetizer.com>
Cc:=C2=A0perc@ietf.org
Sent: 5/3/2021 4:12:20 PM
Subject: Re: [Perc] WGLC = for draft-ietf-perc-dtls-tunnel

Pa= ul:

Section 6.1 says:=

=C2= =A0 =C2=A0struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0uuid ass= ociation_id;
=C2=A0 =C2=A0 =C2=A0 =C2=A0SRTPProtection= Profile protection_profile;
=C2=A0 =C2=A0 =C2=A0 =C2= =A0opaque mki<0..255>;
=C2=A0 =C2=A0 =C2=A0 =C2= =A0opaque client_write_SRTP_master_key<1..255>;
= =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque server_write_SRTP_master_key<1..255>= ;;
=C2=A0 =C2=A0 =C2=A0 =C2=A0opaque client_write_SRTP= _master_salt<1..255>;
=C2=A0 =C2=A0 =C2=A0 =C2= =A0opaque server_write_SRTP_master_salt<1..255>;
=C2=A0 =C2=A0} MediaKeys;

If the MRI is absent, I am assuming that a zero-length value go= es in this structure, but the spec does not say one way or the other.
=

If the MRI is absent= , then there is not anything that is present here to provide binding.
=

Russ


On May 3, 2021, at 3:05 PM, Paul E. = Jones <paulej@packe= tizer.com> wrote:

Russ,

<= /div>
The MediaKeys st= ructure would carry all the other useful=C2=A0bits<= span class=3D"">=C2=A0for SRTP keying material even = if the MediaKeys.mki field contains no data.=C2=A0=C2=A0I guess I still do not understand the question.

Paul

------ Original Message ------
From: "Russ Housley" <housley@vigilsec.com>
To: "Paul E. Jones" <paulej@packetizer.com>
Cc:=C2=A0perc@ietf.org
Sent: 5/3/2021 2:19:16 PM
Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel


Section 6.1: MKI is optional = in RFC 3711. =C2=A0What is carried in=C2=A0MediaKeys when there is no MKI= present?

MediaKeys is a structure with a number of elements inside, = and MKI is optional.=C2=A0 The other things include an association ID, SRT= P protection profile, master keys, and salt values.

You answered the wrong question.= =C2=A0I know that there are other elements in MediaKeys. =C2=A0However, if th= e MKI element is absent, what is used in Section 6.1.
=
Russ
<= /blockquote>
<= br class=3D"" />
--------=_MBBEDAE807-556A-4D13-80FE-ADB570FE8457-- From nobody Mon May 3 15:14:14 2021 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 B31B33A15E7 for ; Mon, 3 May 2021 15:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 4QBtgSGbqav7 for ; Mon, 3 May 2021 15:14:07 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EE113A15E4 for ; Mon, 3 May 2021 15:14:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id BC1F0300BA0 for ; Mon, 3 May 2021 18:14:05 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JzDRbSvcZhAH for ; Mon, 3 May 2021 18:13:59 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 49778300AEF; Mon, 3 May 2021 18:13:59 -0400 (EDT) From: Russ Housley Message-Id: <2A270A9F-E8B4-4E40-A22A-19C25F012F41@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1D256029-E740-4B11-9A4D-61F1E725E222" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\)) Date: Mon, 3 May 2021 18:13:59 -0400 In-Reply-To: Cc: perc@ietf.org To: "Paul E. Jones" References: <9890A9B8-1B59-449A-A049-2A6941AD4691@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.20) Archived-At: Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel 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, 03 May 2021 22:14:13 -0000 --Apple-Mail=_1D256029-E740-4B11-9A4D-61F1E725E222 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Paul: The MKI, when present, identifies the master key from which the four = keys that follow are derived.=20 Is the key derivation completely a local matter? If so, please say = that. Is the technique in Appendix B.3 of RFC 3711 required? If so, = pleas say so. What are the consequences if the identified master key is disclosed? I = would guess that is equivalent to the disclosure of all keys that were = ever derived from it. Russ > On May 3, 2021, at 4:59 PM, Paul E. Jones = wrote: >=20 > Russ, >=20 > OK, I'll add this to the syntax section: >=20 > "A zero-length field indicates that no MKI value is present." >=20 > What security consideration do you think is needed? Presence or = absence, either way, is normal. >=20 > Paul >=20 > ------ Original Message ------ > From: "Russ Housley" > > To: "Paul E. Jones" > > Cc: perc@ietf.org > Sent: 5/3/2021 4:51:23 PM > Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel >=20 >> Paul: >>=20 >> Yes, I think that an explicit statement is needed. I am not = suggesting a syntax change. However, if the MRI is absent, there may be = something to say in the security considerations. >>=20 >> Russ >>=20 >>=20 >>> On May 3, 2021, at 4:46 PM, Paul E. Jones > wrote: >>>=20 >>> Russ, >>>=20 >>> The zero-length would indicate there is no MKI. Section 5.4 = mentions the values in that structure and says "MKI value (if any)". = The field itself cannot be optional in the syntax (as far as I know), = but a zero-length would indicate there is no value present. There is a = one-octet length field that would be set to zero. Are you suggesting a = different syntax or an explicit statement in the MKI field description = that says "a zero-length MKI value indicates absence of an MKI value" or = similar? >>>=20 >>> Paul >>>=20 >>> ------ Original Message ------ >>> From: "Russ Housley" > >>> To: "Paul E. Jones" > >>> Cc: perc@ietf.org >>> Sent: 5/3/2021 4:12:20 PM >>> Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel >>>=20 >>>> Paul: >>>>=20 >>>> Section 6.1 says: >>>>=20 >>>> struct { >>>> uuid association_id; >>>> SRTPProtectionProfile protection_profile; >>>> opaque mki<0..255>; >>>> opaque client_write_SRTP_master_key<1..255>; >>>> opaque server_write_SRTP_master_key<1..255>; >>>> opaque client_write_SRTP_master_salt<1..255>; >>>> opaque server_write_SRTP_master_salt<1..255>; >>>> } MediaKeys; >>>>=20 >>>> If the MRI is absent, I am assuming that a zero-length value goes = in this structure, but the spec does not say one way or the other. >>>>=20 >>>> If the MRI is absent, then there is not anything that is present = here to provide binding. >>>>=20 >>>> Russ >>>>=20 >>>>=20 >>>>> On May 3, 2021, at 3:05 PM, Paul E. Jones > wrote: >>>>>=20 >>>>> Russ, >>>>>=20 >>>>> The MediaKeys structure would carry all the other useful bits for = SRTP keying material even if the MediaKeys.mki field contains no data. = I guess I still do not understand the question. >>>>>=20 >>>>> Paul >>>>>=20 >>>>> ------ Original Message ------ >>>>> From: "Russ Housley" > >>>>> To: "Paul E. Jones" > >>>>> Cc: perc@ietf.org >>>>> Sent: 5/3/2021 2:19:16 PM >>>>> Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel >>>>>=20 >>>>>>=20 >>>>>>>> Section 6.1: MKI is optional in RFC 3711. What is carried in = MediaKeys when there is no MKI present? >>>>>>>=20 >>>>>>> MediaKeys is a structure with a number of elements inside, and = MKI is optional. The other things include an association ID, SRTP = protection profile, master keys, and salt values. >>>>>>=20 >>>>>> You answered the wrong question. I know that there are other = elements in MediaKeys. However, if the MKI element is absent, what is = used in Section 6.1. >>>>>>=20 >>>>>> Russ >>=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc = --Apple-Mail=_1D256029-E740-4B11-9A4D-61F1E725E222 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Paul:

The MKI, = when present, identifies the master key from which the four keys that = follow are derived. 

Is the key derivation completely a local matter?  If so, = please say that.  Is the technique in Appendix B.3 of RFC 3711 = required?  If so, pleas say so.

What are the consequences if the = identified master key is disclosed?  I would guess that is = equivalent to the disclosure of all keys that were ever derived from = it.

Russ


On May 3, 2021, at 4:59 PM, = Paul E. Jones <paulej=3D40packetizer.com@dmarc.ietf.org> = wrote:

Russ,

OK, I'll add this to the syntax section:

"A = zero-length field indicates that  no MKI value is present."

What = security consideration do you think is needed?  Presence or = absence, either way, is normal.

Paul

------ Original Message = ------
From: "Russ Housley" <housley@vigilsec.com>
To: = "Paul E. Jones" <paulej@packetizer.com>
Sent: 5/3/2021 4:51:23 PM
Subject: Re: [Perc] WGLC for = draft-ietf-perc-dtls-tunnel

Paul:

Yes, I think that an explicit statement = is needed.  I am not suggesting a syntax change.  However, if = the MRI is absent, there may be something to say in the security = considerations.

Russ


On May = 3, 2021, at 4:46 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Russ,

The zero-length would indicate there is no MKI.  Section 5.4 = mentions the values in that structure and says "MKI value (if = any)".  The field itself cannot be optional in the syntax (as far = as I know), but a zero-length would indicate there is no value = present.  There is a one-octet length field that would be set to = zero.  Are you suggesting a different syntax or an explicit = statement in the MKI field description that says "a zero-length MKI = value indicates absence of an MKI value" or similar?

Paul

------ Original = Message ------
From: "Russ Housley" <housley@vigilsec.com>
To: "Paul E. Jones" <paulej@packetizer.com>
Sent: 5/3/2021 4:12:20 PM
Subject: Re: [Perc] WGLC for = draft-ietf-perc-dtls-tunnel

Paul:

Section 6.1 says:

   struct = {
       uuid = association_id;
      =  SRTPProtectionProfile protection_profile;
       opaque = mki<0..255>;
      =  opaque client_write_SRTP_master_key<1..255>;
       opaque = server_write_SRTP_master_key<1..255>;
  =      opaque = client_write_SRTP_master_salt<1..255>;
  =      opaque = server_write_SRTP_master_salt<1..255>;
  =  } MediaKeys;

If the MRI is absent, I am assuming that a zero-length value = goes in this structure, but the spec does not say one way or the = other.

If the = MRI is absent, then there is not anything that is present here to = provide binding.

Russ


On May 3, 2021, at 3:05 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Russ,

The MediaKeys structure would carry all the other = useful bits for SRTP keying material even = if the MediaKeys.mki field contains no data.  I guess I still do not understand the = question.

Paul

------ Original = Message ------
From: "Russ Housley" <housley@vigilsec.com>
To: "Paul E. Jones" <paulej@packetizer.com>
Sent: 5/3/2021 2:19:16 PM
Subject: Re: [Perc] WGLC for = draft-ietf-perc-dtls-tunnel


Section 6.1: MKI is optional in RFC 3711. =  What is carried in MediaKeys when there is no MKI = present?

MediaKeys is a structure with a number = of elements inside, and MKI is optional.  The other things include = an association ID, SRTP protection profile, master keys, and salt = values.

You = answered the wrong question.  I know that there are other elements = in MediaKeys.  However, if the MKI element is absent, what is used = in Section 6.1.

Russ

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

= --Apple-Mail=_1D256029-E740-4B11-9A4D-61F1E725E222-- From nobody Mon May 3 16:31:43 2021 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 63F643A18CD for ; Mon, 3 May 2021 16:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.397 X-Spam-Level: X-Spam-Status: No, score=-4.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.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 BGNlil0botsK for ; Mon, 3 May 2021 16:31:36 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A50B3A18CB for ; Mon, 3 May 2021 16:31:35 -0700 (PDT) Received: from authuser (localhost [127.0.0.1]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1620084689; bh=utumnnTwvEJI++CJ7A3orM6hgg+Q0tdSp1KIgJ4UTKg=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=B4p8fyYIspCCyOivT7BzpTmLFZ6pDUvhxJSfWS0It9O9e2nFQnqGvfLJtWuRoY1MX WGIWnNluHPCeg0z7BsLiSZ26gyiLRo+D0Eg9TTW7RPansV+9ctsB407uDzi8FrILwb InLnAYoqYJedz98oKwrUl5Wa8zxUEPjuq2WxIfZs= From: "Paul E. Jones" To: "Russ Housley" Cc: perc@ietf.org Date: Mon, 03 May 2021 23:31:22 +0000 Message-Id: In-Reply-To: <2A270A9F-E8B4-4E40-A22A-19C25F012F41@vigilsec.com> References: <9890A9B8-1B59-449A-A049-2A6941AD4691@vigilsec.com> <2A270A9F-E8B4-4E40-A22A-19C25F012F41@vigilsec.com> Reply-To: "Paul E. Jones" User-Agent: eM_Client/8.2.1237.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBD78FD0BE-A6DB-4059-ADFA-432C9BCB7344" Archived-At: Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel 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, 03 May 2021 23:31:41 -0000 --------=_MBD78FD0BE-A6DB-4059-ADFA-432C9BCB7344 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Russ, The tunneling procedures build on RFC 5764, which is where the key=20 derivation process is defined. What the tunneling spec says is that the=20 key distributor hands those keys and salt values to the media=20 distributor in a special message. That is necessary since the media=20 distributor is otherwise not party to the key exchange that preceded the=20 key generation and derivation steps. There is further key derivation from master keys to session keys and=20 salt described in RFC 3711 Section 4.3. However, we should not get into=20 that detail in this draft. This draft just explains how to convey the=20 information needed by an SRTP implementation, not how to implement SRTP. While MKI is encrypted in the message exchange in the tunneling spec, it=20 would not matter if it wasn't exposed. This value means nothing on its=20 own and is present in SRTP packets in the clear if used; it's not a=20 secret value (nor is the master salt). Paul ------ Original Message ------ From: "Russ Housley" To: "Paul E. Jones" Cc: perc@ietf.org Sent: 5/3/2021 6:13:59 PM Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel >Paul: > >The MKI, when present, identifies the master key from which the four=20 >keys that follow are derived. > >Is the key derivation completely a local matter? If so, please say=20 >that. Is the technique in Appendix B.3 of RFC 3711 required? If so,=20 >pleas say so. > >What are the consequences if the identified master key is disclosed? I=20 >would guess that is equivalent to the disclosure of all keys that were=20 >ever derived from it. > >Russ > > >>On May 3, 2021, at 4:59 PM, Paul E. Jones=20 >> wrote: >> >>Russ, >> >>OK, I'll add this to the syntax section: >> >>"A zero-length field indicates that no MKI value is present." >> >>What security consideration do you think is needed? Presence or=20 >>absence, either way, is normal. >> >>Paul >> >>------ Original Message ------ >>From: "Russ Housley" >>To: "Paul E. Jones" >>Cc: perc@ietf.org >>Sent: 5/3/2021 4:51:23 PM >>Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel >> >>>Paul: >>> >>>Yes, I think that an explicit statement is needed. I am not=20 >>>suggesting a syntax change. However, if the MRI is absent, there may=20 >>>be something to say in the security considerations. >>> >>>Russ >>> >>> >>>>On May 3, 2021, at 4:46 PM, Paul E. Jones =20 >>>>wrote: >>>> >>>>Russ, >>>> >>>>The zero-length would indicate there is no MKI. Section 5.4=20 >>>>mentions the values in that structure and says "MKI value (if any)".=20 >>>> The field itself cannot be optional in the syntax (as far as I=20 >>>>know), but a zero-length would indicate there is no value present. =20 >>>>There is a one-octet length field that would be set to zero. Are=20 >>>>you suggesting a different syntax or an explicit statement in the=20 >>>>MKI field description that says "a zero-length MKI value indicates=20 >>>>absence of an MKI value" or similar? >>>> >>>>Paul >>>> >>>>------ Original Message ------ >>>>From: "Russ Housley" >>>>To: "Paul E. Jones" >>>>Cc: perc@ietf.org >>>>Sent: 5/3/2021 4:12:20 PM >>>>Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel >>>> >>>>>Paul: >>>>> >>>>>Section 6.1 says: >>>>> >>>>> struct { >>>>> uuid association_id; >>>>> SRTPProtectionProfile protection_profile; >>>>> opaque mki<0..255>; >>>>> opaque client_write_SRTP_master_key<1..255>; >>>>> opaque server_write_SRTP_master_key<1..255>; >>>>> opaque client_write_SRTP_master_salt<1..255>; >>>>> opaque server_write_SRTP_master_salt<1..255>; >>>>> } MediaKeys; >>>>> >>>>>If the MRI is absent, I am assuming that a zero-length value goes=20 >>>>>in this structure, but the spec does not say one way or the other. >>>>> >>>>>If the MRI is absent, then there is not anything that is present=20 >>>>>here to provide binding. >>>>> >>>>>Russ >>>>> >>>>> >>>>>>On May 3, 2021, at 3:05 PM, Paul E. Jones =20 >>>>>>wrote: >>>>>> >>>>>>Russ, >>>>>> >>>>>>The MediaKeys structure would carry all the other useful bits for=20 >>>>>>SRTP keying material even if the MediaKeys.mki field contains no=20 >>>>>>data. I guess I still do not understand the question. >>>>>> >>>>>>Paul >>>>>> >>>>>>------ Original Message ------ >>>>>>From: "Russ Housley" >>>>>>To: "Paul E. Jones" >>>>>>Cc: perc@ietf.org >>>>>>Sent: 5/3/2021 2:19:16 PM >>>>>>Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel >>>>>> >>>>>>> >>>>>>>>>Section 6.1: MKI is optional in RFC 3711. What is carried in=20 >>>>>>>>>MediaKeys when there is no MKI present? >>>>>>>> >>>>>>>>MediaKeys is a structure with a number of elements inside, and=20 >>>>>>>>MKI is optional. The other things include an association ID,=20 >>>>>>>>SRTP protection profile, master keys, and salt values. >>>>>>> >>>>>>>You answered the wrong question. I know that there are other=20 >>>>>>>elements in MediaKeys. However, if the MKI element is absent,=20 >>>>>>>what is used in Section 6.1. >>>>>>> >>>>>>>Russ >>> >>_______________________________________________ >>Perc mailing list >>Perc@ietf.org >>https://www.ietf.org/mailman/listinfo/perc > --------=_MBD78FD0BE-A6DB-4059-ADFA-432C9BCB7344 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Russ,

The tunneling procedures build on RFC 5764, which is where the= key derivation process is defined.=C2=A0 What the tunneling spec says is th= at the key distributor hands those keys and salt values to the media distri= butor in a special message.=C2=A0 That is necessary since the media distrib= utor is otherwise not party to the key exchange that preceded the key gener= ation and derivation steps.

There is further key = derivation from master keys to session keys and salt described in RFC 3711 = Section 4.3.=C2=A0 However, we should not get into that detail in this dra= ft.=C2=A0 This draft just explains how to convey the information needed by= an SRTP implementation, not how to implement SRTP.

While MKI is encrypted in the message exchange in the tunneling spec, it = would not matter if it wasn't exposed.=C2=A0 This value means nothing on i= ts own and is present in SRTP packets in the clear if used; it's not a secr= et value (nor is the master salt).

Paul

------ Original Message ------
From: "Russ Housley" <housl= ey@vigilsec.com>
To: "Paul E. Jones" <paule= j@packetizer.com>
Sent: 5/3/2021 6:13:59 PM
Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel

Paul:

The MKI, when present= , identifies the master key from which the four keys that follow are derive= d.=C2=A0

Is the = key derivation completely a local matter? =C2=A0If so, please say that.= =C2=A0Is the technique in Appendix B.3 of RFC 3711 required? =C2=A0If so, ple= as say so.

What = are the consequences if the identified master key is disclosed? =C2=A0I wo= uld guess that is equivalent to the disclosure of all keys that were ever d= erived from it.

Russ<= /div>


On May 3, 2021, at 4:59 PM, Pau= l E. Jones <paulej=3D40packetizer.com@dmarc.ietf.org> wrote:

Russ,

OK, I'll add this to the syntax section:

<= div style=3D"caret-color: rgb(0, 0, 0); font-family: Calibri; font-size: 14= .666666984558105px; font-style: normal; font-variant-caps: normal; font-wei= ght: normal; letter-spacing: normal; text-align: start; text-indent: 0px; t= ext-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-s= troke-width: 0px; text-decoration: none;" class=3D"">"A zero-length field i= ndicates that =C2=A0no MKI valu= e is present."

What security consideration do you think is needed?=C2=A0 Presence= or absence, either way, is normal.

Paul

------ Original Message ------
From: "Russ Housley" <housley@vigilsec.com>
To: "Paul E. Jones" <paulej@packetizer.com>
Cc:=C2=A0perc@ietf.org
Sent: 5/3/2021 4:51:23 PM
Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel<= /div>

Paul:

Yes, I think that an explicit statement is needed. = =C2=A0I am not suggesting a syntax change. =C2=A0However, if the MRI is ab= sent, there may be something to say in the security considerations.

Russ


On May 3, 2021, at 4:46 PM, Paul E. Jones = <paulej@packetizer.= com> wrote:

Russ,

<= div class=3D"" style=3D"caret-color: rgb(0, 0, 0); font-family: Calibri; fo= nt-size: 14.666666984558105px; font-style: normal; font-variant-caps: norma= l; font-weight: normal; letter-spacing: normal; text-align: start; text-ind= ent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -we= bkit-text-stroke-width: 0px; text-decoration: none;">The zero-length would= indicate there is no MKI.=C2=A0 Section 5.4 mentions the values in that str= ucture and says "MKI value (if any)".=C2=A0 The field itself cannot be opti= onal in the syntax (as far as I know), but a zero-length would indicate the= re is no value present.=C2=A0 There is a one-octet length field that would= be set to zero.=C2=A0 Are you suggesting a different syntax or an explicit= statement in the MKI field description that says "a zero-length MKI value i= ndicates absence of an MKI value" or similar?

Paul

------ Original Message ------
From: "Russ Housley" <housley@vigilsec.com>
<= div class=3D"" style=3D"caret-color: rgb(0, 0, 0); font-family: Calibri; fo= nt-size: 14.666666984558105px; font-style: normal; font-variant-caps: norma= l; font-weight: normal; letter-spacing: normal; text-align: start; text-ind= ent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -we= bkit-text-stroke-width: 0px; text-decoration: none;">To: "Paul E. Jones" &l= t;paulej@packetizer.com= >
Cc:=C2=A0perc@ietf.org
Sent: 5/3/2021 4:12:20 PM
Subject: Re: [Perc] WGLC for draft-ietf-perc-dt= ls-tunnel

Paul:

Section 6.1 says:

=C2=A0 =C2=A0struct {
<= div class=3D"">=C2=A0 =C2=A0 =C2=A0 =C2=A0uuid association_id;
=C2=A0 =C2=A0 =C2=A0 =C2=A0SRTPProtectionProfile protection_profil= e;
=C2=A0 =C2=A0 =C2=A0 =C2=A0opaque mki<0..255>= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0opaque client_write_SRTP_= master_key<1..255>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0o= paque server_write_SRTP_master_key<1..255>;
=C2= =A0 =C2=A0 =C2=A0 =C2=A0opaque client_write_SRTP_master_salt<1..255>;=
=C2=A0 =C2=A0 =C2=A0 =C2=A0opaque server_write_SRTP_m= aster_salt<1..255>;
=C2=A0 =C2=A0} MediaKeys;

If the MRI is abs= ent, I am assuming that a zero-length value goes in this structure, but the = spec does not say one way or the other.

If the MRI is absent, then there is not anything= that is present here to provide binding.

Russ

=

On May 3, 2021, at 3:05 PM, Paul E. Jones <paulej@packetizer.com> wrote:
Russ,

The MediaKeys structure would carry all the o= ther useful=C2=A0bits=C2=A0= for SRTP keying material even if the MediaKeys.mki field c= ontains no data.=C2=A0=C2=A0I guess I still do not= understand the question.

Paul

<= /div>
------ Original= Message ------
F= rom: "Russ Housley" <= housley@vigilsec.com>
To: "Paul E. Jones" <paulej@packetizer.com>
Cc:=C2=A0= perc@ietf.org
<= div class=3D"" style=3D"caret-color: rgb(0, 0, 0); font-family: Calibri; fo= nt-size: 14.666666984558105px; font-style: normal; font-variant-caps: norma= l; font-weight: normal; letter-spacing: normal; text-align: start; text-ind= ent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -we= bkit-text-stroke-width: 0px; text-decoration: none;">Sent: 5/3/2021 2:19:16 = PM
Subject: Re: = [Perc] WGLC for draft-ietf-perc-dtls-tunnel


Section 6.1: MKI is optional in RFC 3711. =C2=A0What= is carried in=C2=A0MediaKeys when there is no MKI present?

MediaK= eys is a structure with a number of elements inside, and MKI is optional.= =C2=A0 The other things include an association ID, SRTP protection profile, = master keys, and salt values.
You answered the wrong question. =C2=A0I know that there = are other elements in MediaKeys. =C2=A0However, if the MKI element is abse= nt, what is used in Section 6.1.

Russ

__________________________________= _____________
= Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc
--------=_MBD78FD0BE-A6DB-4059-ADFA-432C9BCB7344-- From nobody Mon May 3 17:40:49 2021 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 A5E933A1B49 for ; Mon, 3 May 2021 17:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 ZktAencWIypT for ; Mon, 3 May 2021 17:40:43 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81A143A1B47 for ; Mon, 3 May 2021 17:40:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A3DA9300BDF for ; Mon, 3 May 2021 20:40:41 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RhUNnPyIJ3om for ; Mon, 3 May 2021 20:40:34 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 390C63000B9; Mon, 3 May 2021 20:40:34 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_BC55DBA3-F3FC-47ED-909F-7FB24C5F9681" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\)) Date: Mon, 3 May 2021 20:40:34 -0400 In-Reply-To: Cc: perc@ietf.org To: "Paul E. Jones" References: <9890A9B8-1B59-449A-A049-2A6941AD4691@vigilsec.com> <2A270A9F-E8B4-4E40-A22A-19C25F012F41@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.20) Archived-At: Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel 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, 04 May 2021 00:40:49 -0000 --Apple-Mail=_BC55DBA3-F3FC-47ED-909F-7FB24C5F9681 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Paul: I asked about disclosure of the master key, not the MKI. Russ > On May 3, 2021, at 7:31 PM, Paul E. Jones = wrote: >=20 > Russ, >=20 > The tunneling procedures build on RFC 5764, which is where the key = derivation process is defined. What the tunneling spec says is that the = key distributor hands those keys and salt values to the media = distributor in a special message. That is necessary since the media = distributor is otherwise not party to the key exchange that preceded the = key generation and derivation steps. >=20 > There is further key derivation from master keys to session keys and = salt described in RFC 3711 Section 4.3. However, we should not get into = that detail in this draft. This draft just explains how to convey the = information needed by an SRTP implementation, not how to implement SRTP. >=20 > While MKI is encrypted in the message exchange in the tunneling spec, = it would not matter if it wasn't exposed. This value means nothing on = its own and is present in SRTP packets in the clear if used; it's not a = secret value (nor is the master salt). >=20 > Paul >=20 > ------ Original Message ------ > From: "Russ Housley" > > To: "Paul E. Jones" > > Cc: perc@ietf.org > Sent: 5/3/2021 6:13:59 PM > Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel >=20 >> Paul: >>=20 >> The MKI, when present, identifies the master key from which the four = keys that follow are derived.=20 >>=20 >> Is the key derivation completely a local matter? If so, please say = that. Is the technique in Appendix B.3 of RFC 3711 required? If so, = pleas say so. >>=20 >> What are the consequences if the identified master key is disclosed? = I would guess that is equivalent to the disclosure of all keys that were = ever derived from it. >>=20 >> Russ >>=20 >>=20 >>> On May 3, 2021, at 4:59 PM, Paul E. Jones = > wrote: >>>=20 >>> Russ, >>>=20 >>> OK, I'll add this to the syntax section: >>>=20 >>> "A zero-length field indicates that no MKI value is present." >>>=20 >>> What security consideration do you think is needed? Presence or = absence, either way, is normal. >>>=20 >>> Paul >>>=20 >>> ------ Original Message ------ >>> From: "Russ Housley" > >>> To: "Paul E. Jones" > >>> Cc: perc@ietf.org >>> Sent: 5/3/2021 4:51:23 PM >>> Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel >>>=20 >>>> Paul: >>>>=20 >>>> Yes, I think that an explicit statement is needed. I am not = suggesting a syntax change. However, if the MRI is absent, there may be = something to say in the security considerations. >>>>=20 >>>> Russ >>>>=20 >>>>=20 >>>>> On May 3, 2021, at 4:46 PM, Paul E. Jones > wrote: >>>>>=20 >>>>> Russ, >>>>>=20 >>>>> The zero-length would indicate there is no MKI. Section 5.4 = mentions the values in that structure and says "MKI value (if any)". = The field itself cannot be optional in the syntax (as far as I know), = but a zero-length would indicate there is no value present. There is a = one-octet length field that would be set to zero. Are you suggesting a = different syntax or an explicit statement in the MKI field description = that says "a zero-length MKI value indicates absence of an MKI value" or = similar? >>>>>=20 >>>>> Paul >>>>>=20 >>>>> ------ Original Message ------ >>>>> From: "Russ Housley" > >>>>> To: "Paul E. Jones" > >>>>> Cc: perc@ietf.org >>>>> Sent: 5/3/2021 4:12:20 PM >>>>> Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel >>>>>=20 >>>>>> Paul: >>>>>>=20 >>>>>> Section 6.1 says: >>>>>>=20 >>>>>> struct { >>>>>> uuid association_id; >>>>>> SRTPProtectionProfile protection_profile; >>>>>> opaque mki<0..255>; >>>>>> opaque client_write_SRTP_master_key<1..255>; >>>>>> opaque server_write_SRTP_master_key<1..255>; >>>>>> opaque client_write_SRTP_master_salt<1..255>; >>>>>> opaque server_write_SRTP_master_salt<1..255>; >>>>>> } MediaKeys; >>>>>>=20 >>>>>> If the MRI is absent, I am assuming that a zero-length value goes = in this structure, but the spec does not say one way or the other. >>>>>>=20 >>>>>> If the MRI is absent, then there is not anything that is present = here to provide binding. >>>>>>=20 >>>>>> Russ >>>>>>=20 >>>>>>=20 >>>>>>> On May 3, 2021, at 3:05 PM, Paul E. Jones > wrote: >>>>>>>=20 >>>>>>> Russ, >>>>>>>=20 >>>>>>> The MediaKeys structure would carry all the other useful bits = for SRTP keying material even if the MediaKeys.mki field contains no = data. I guess I still do not understand the question. >>>>>>>=20 >>>>>>> Paul >>>>>>>=20 >>>>>>> ------ Original Message ------ >>>>>>> From: "Russ Housley" > >>>>>>> To: "Paul E. Jones" > >>>>>>> Cc: perc@ietf.org >>>>>>> Sent: 5/3/2021 2:19:16 PM >>>>>>> Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel >>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> Section 6.1: MKI is optional in RFC 3711. What is carried in = MediaKeys when there is no MKI present? >>>>>>>>>=20 >>>>>>>>> MediaKeys is a structure with a number of elements inside, and = MKI is optional. The other things include an association ID, SRTP = protection profile, master keys, and salt values. >>>>>>>>=20 >>>>>>>> You answered the wrong question. I know that there are other = elements in MediaKeys. However, if the MKI element is absent, what is = used in Section 6.1. >>>>>>>>=20 >>>>>>>> Russ >>>>=20 >>> _______________________________________________ >>> Perc mailing list >>> Perc@ietf.org >>> https://www.ietf.org/mailman/listinfo/perc = > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc = --Apple-Mail=_BC55DBA3-F3FC-47ED-909F-7FB24C5F9681 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Paul:

I = asked about disclosure of the master key, not the MKI.

Russ


On May 3, 2021, at 7:31 PM, Paul E. Jones = <paulej=3D40packetizer.com@dmarc.ietf.org> = wrote:

Russ,

The tunneling procedures build on RFC 5764, which is = where the key derivation process is defined.  What the tunneling = spec says is that the key distributor hands those keys and salt values = to the media distributor in a special message.  That is necessary = since the media distributor is otherwise not party to the key exchange = that preceded the key generation and derivation steps.

There = is further key derivation from master keys to session keys and salt = described in RFC 3711 Section 4.3.  However, we should not get into = that detail in this draft.  This draft just explains how to convey = the information needed by an SRTP implementation, not how to implement = SRTP.

While MKI is encrypted in the message exchange in the = tunneling spec, it would not matter if it wasn't exposed.  This = value means nothing on its own and is present in SRTP packets in the = clear if used; it's not a secret value (nor is the master = salt).

Paul

------ Original Message ------
From: "Russ Housley" <housley@vigilsec.com>
To: = "Paul E. Jones" <paulej@packetizer.com>
Sent: 5/3/2021 6:13:59 PM
Subject: Re: [Perc] WGLC for = draft-ietf-perc-dtls-tunnel

Paul:

The MKI, when present, identifies the master = key from which the four keys that follow are derived. 

Is the key derivation = completely a local matter?  If so, please say that.  Is the = technique in Appendix B.3 of RFC 3711 required?  If so, pleas say = so.

What are = the consequences if the identified master key is disclosed?  I = would guess that is equivalent to the disclosure of all keys that were = ever derived from it.

Russ


On May 3, 2021, at 4:59 PM, Paul E. Jones <paulej=3D40packetizer.com@dmarc.ietf.org> = wrote:

Russ,

OK, I'll add this to the syntax section:

"A zero-length = field indicates that  no MKI value is present."

What security = consideration do you think is needed?  Presence or absence, either = way, is normal.

Paul

------ Original Message ------
From: "Russ Housley" <housley@vigilsec.com>
To: "Paul E. Jones" <paulej@packetizer.com>
Sent: 5/3/2021 4:51:23 PM
Subject: Re: [Perc] WGLC for = draft-ietf-perc-dtls-tunnel

Paul:

Yes, I think that an explicit statement = is needed.  I am not suggesting a syntax change.  However, if = the MRI is absent, there may be something to say in the security = considerations.

Russ


On May = 3, 2021, at 4:46 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Russ,

The zero-length would indicate there is no MKI.  Section 5.4 = mentions the values in that structure and says "MKI value (if = any)".  The field itself cannot be optional in the syntax (as far = as I know), but a zero-length would indicate there is no value = present.  There is a one-octet length field that would be set to = zero.  Are you suggesting a different syntax or an explicit = statement in the MKI field description that says "a zero-length MKI = value indicates absence of an MKI value" or similar?

Paul

------ Original = Message ------
From: "Russ Housley" <housley@vigilsec.com>
To: "Paul E. Jones" <paulej@packetizer.com>
Sent: 5/3/2021 4:12:20 PM
Subject: Re: [Perc] WGLC for = draft-ietf-perc-dtls-tunnel

Paul:

Section 6.1 says:

   struct = {
       uuid = association_id;
      =  SRTPProtectionProfile protection_profile;
       opaque = mki<0..255>;
      =  opaque client_write_SRTP_master_key<1..255>;
       opaque = server_write_SRTP_master_key<1..255>;
  =      opaque = client_write_SRTP_master_salt<1..255>;
  =      opaque = server_write_SRTP_master_salt<1..255>;
  =  } MediaKeys;

If the MRI is absent, I am assuming that a zero-length value = goes in this structure, but the spec does not say one way or the = other.

If the = MRI is absent, then there is not anything that is present here to = provide binding.

Russ


On May 3, 2021, at 3:05 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Russ,

The MediaKeys structure would carry all the other = useful bits for SRTP keying material even = if the MediaKeys.mki field contains no data.  I guess I still do not understand the = question.

Paul

------ Original = Message ------
From: "Russ Housley" <housley@vigilsec.com>
To: "Paul E. Jones" <paulej@packetizer.com>
Sent: 5/3/2021 2:19:16 PM
Subject: Re: [Perc] WGLC for = draft-ietf-perc-dtls-tunnel


Section 6.1: MKI is optional in RFC 3711. =  What is carried in MediaKeys when there is no MKI = present?

MediaKeys is a structure with a number = of elements inside, and MKI is optional.  The other things include = an association ID, SRTP protection profile, master keys, and salt = values.

You = answered the wrong question.  I know that there are other elements = in MediaKeys.  However, if the MKI element is absent, what is used = in Section 6.1.

Russ

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

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

= --Apple-Mail=_BC55DBA3-F3FC-47ED-909F-7FB24C5F9681-- From nobody Tue May 4 11:07:53 2021 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 AF0563A086E for ; Tue, 4 May 2021 11:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.398 X-Spam-Level: X-Spam-Status: No, score=-4.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.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 xLeXlSSgEK7S for ; Tue, 4 May 2021 11:07:46 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF863A085C for ; Tue, 4 May 2021 11:07:46 -0700 (PDT) Received: from authuser (localhost [127.0.0.1]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1620151664; bh=0D2Jsw54zHWUm8Y8Y6w86sQMDxLQJt2qxnUaQo8wnv8=; h=From:To:Subject:Date:Reply-To; b=GK44AQn3xKNI7mpi3WJqx9OpDXk0VIC7IQWvrdO8+6Rj3CsLpZl2DIU7Q59No/jfB P4bLNj5OrxThBR9WF3jgCbLH5mSzlv+gL6YVg+jQJqA9Zq2r/dyvFCZMlxyuVdf4FM EExPhg/+/jbz8D6qCrrkUGotcwJBf3H46AMfdxRw= From: "Paul E. Jones" To: "perc@ietf.org" Date: Tue, 04 May 2021 18:07:39 +0000 Message-Id: Reply-To: "Paul E. Jones" User-Agent: eM_Client/8.2.1237.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBC57F0910-B6D7-40A8-93DA-1F2F9FA7C306" Archived-At: Subject: [Perc] Review comments branch for Tunnel draft 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, 04 May 2021 18:07:52 -0000 --------=_MBC57F0910-B6D7-40A8-93DA-1F2F9FA7C306 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Folks, This is the branch where I have captured review comments thus far: https://github.com/percwg/perc-wg/tree/paulej_review_comments Paul --------=_MBC57F0910-B6D7-40A8-93DA-1F2F9FA7C306 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Folks,

This is the branch where I have captured= review comments thus far:

Paul

--------=_MBC57F0910-B6D7-40A8-93DA-1F2F9FA7C306-- From nobody Wed May 19 19:06:53 2021 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 6E8D33A28E7; Wed, 19 May 2021 19:06:51 -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: 7.29.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: perc@ietf.org Message-ID: <162147641138.28696.11113653733811787023@ietfa.amsl.com> Date: Wed, 19 May 2021 19:06:51 -0700 Archived-At: Subject: [Perc] I-D Action: draft-ietf-perc-dtls-tunnel-08.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: Thu, 20 May 2021 02:06:52 -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-08.txt Pages : 17 Date : 2021-05-19 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 is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-perc-dtls-tunnel-08.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-dtls-tunnel-08 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 Thu May 20 00:21:11 2021 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 4B4A13A0E5B; Thu, 20 May 2021 00:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 avbnyaNty1qY; Thu, 20 May 2021 00:21:08 -0700 (PDT) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (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 929483A0E59; Thu, 20 May 2021 00:21:08 -0700 (PDT) Received: by mail-ua1-x930.google.com with SMTP id d30so5248503uae.13; Thu, 20 May 2021 00:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=DJbi+mCMD/ZgEpOVITX6Er8I8cPifspsX7uGBKem8ro=; b=iQWhc4rUq6yL5IM85R1Tp656EXLUBfvs40El7DPD/LG5wq2FHIycXdcjPzLtegc4Bf rYF7b+QoJUGlSFoFGIlF6kL4b0jNYAjEV2xwLofHRQ6JT2RwYl2IWrrTuFkfVlvEnIdE IYWzO1EHUjXPpkcZkYYbrl/mi1XHHikOH8c0NUulPHIEx1e8rH77jIwLF9EtoycZ3udp EPWlzYUfbkdCAO99ADx+QEX/4sl6k+AUF3mWsb1XkutQkRw4fIcLIdiTSCC7LTRfyLpq eKkJ42hwitlHHME4hlG1iDTib6ZJ4hWwciSUxB6fBU93B2akSuPtEGIk2o3rDn2N9JIg 2cHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=DJbi+mCMD/ZgEpOVITX6Er8I8cPifspsX7uGBKem8ro=; b=IpDGDF6So6AqkGvfTtti6en0s+3Opy8z4pblXpyXCpVE6KC5z1wx8zYfIaRyIVx5GO lKZNb6OBp7QkDEN7mInYB0B3d/osG7IPi5U+teJL1MR06ZPQr9NZI2zWFmBdRf82Z34E 7e41EekGf9MPybhrNW9kkqJu9mLnGwPs7A7A10HJtbCO92qb7RDAl64Ij3ZwcTs+MVJK uuGvtA2EtgcxamQmxlDnbW3IwmExOY0uirqsL42FIsGSQr88qY4mIMFIXM6gdcTc+HC/ gyljwtDxXFv+eLFNilQRNuNIhZz92p/OaLL66PBai0Ub53FXp3QQ2QiOY6pUB8lw6KfN 4OYA== X-Gm-Message-State: AOAM533lNDdGHd5PCss9VlVMq/WfJuau4XMpNtvr4SDa9pgooEbYh93E EQapWowQdQvLQt5hKrhUHqXViFMdzILog4Zx6xeeE3gTOEY= X-Google-Smtp-Source: ABdhPJzavWMthoeU+DfketjEfgSBFfEf9u1H/3h0dnairf/JPjs6rt2gN0VKWbjbWuoun33scFoNsSTdkJBfpMiYJxw= X-Received: by 2002:ab0:44a6:: with SMTP id n35mr3008177uan.101.1621495265916; Thu, 20 May 2021 00:21:05 -0700 (PDT) MIME-Version: 1.0 From: "Murray S. Kucherawy" Date: Thu, 20 May 2021 00:20:54 -0700 Message-ID: To: perc@ietf.org, perc-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000054794105c2bdc9c3" Archived-At: Subject: [Perc] AD review of draft-ietf-perc-dtls-tunnel 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, 20 May 2021 07:21:10 -0000 --00000000000054794105c2bdc9c3 Content-Type: text/plain; charset="UTF-8" Hi all, I've completed my AD review of this document. The only feedback I think I'd like to call out here before issuing an IETF Last Call is a few points about Section 8: * the last line has an "if" instead of an "of" * the RFC reference right after that appears funny ("[!@RFC####]"); did it not render correctly? * saying the remaining range is "reserved for future reservations" seems contradictory to me; "reserved" usually means "not available", but I actually think you mean "available" for new registrations that pass IETF Review, correct? -MSK --00000000000054794105c2bdc9c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I've completed m= y AD review of this document.=C2=A0 The only feedback I think I'd like = to call out here before issuing an IETF Last Call is a few points about Sec= tion 8:

* the last line has an "if" instead of = an "of"

* the RFC reference right after that ap= pears funny ("[!@RFC####]"); did it not render correctly?

=
* saying the remaining range is "reserved for future reserv= ations" seems contradictory to me; "reserved" usually means = "not available", but I actually think you mean "available&qu= ot; for new registrations that pass IETF Review, correct?

-MSK
--00000000000054794105c2bdc9c3-- From nobody Mon May 24 07:39:06 2021 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 20B1D3A2B59; Mon, 24 May 2021 07:38:52 -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: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-perc-dtls-tunnel@ietf.org, perc-chairs@ietf.org, perc@ietf.org, suhasietf@gmail.com, superuser@gmail.com Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <162186713211.27485.12792937732931076484@ietfa.amsl.com> Date: Mon, 24 May 2021 07:38:52 -0700 Archived-At: Subject: [Perc] Last Call: (DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange) to Informational RFC 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: Mon, 24 May 2021 14:39:01 -0000 The IESG has received a request from the Privacy Enhanced RTP Conferencing WG (perc) to consider the following document: - 'DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange' as Informational RFC 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 last-call@ietf.org mailing lists by 2021-06-07. 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 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-perc-dtls-tunnel/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3586/ https://datatracker.ietf.org/ipr/3580/ From nobody Thu May 27 07:29:32 2021 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 80CBE3A0FDE; Thu, 27 May 2021 07:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.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 fJnmFWINQ_YU; Thu, 27 May 2021 07:29:26 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D8F3A0FDC; Thu, 27 May 2021 07:29:26 -0700 (PDT) Received: from authuser (localhost [127.0.0.1]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1622125763; bh=hYt5RZ58bbgxrewsF5iV4+C7VwetRTfMUQ7zBVrvDyg=; h=From:To:Subject:Date:In-Reply-To:References:Reply-To; b=BX24/USpFfmeHkcIkZnHX7Ns1cS0K8P4Yvp4XDiezYkr66uG12tOLhSb5zy/k6pmX PfK8CH/J+H0x2CpJxY2Ce5IbK6/vk5tOmTlDHWPEznBfTtMg5PtXnoxQP32FB9d+Ui ERq6HYEjZA/J5qVbcMuJOx/Geuk6B+WDOktgwJ8M= From: "Paul E. Jones" To: "Murray S. Kucherawy" , perc@ietf.org, perc-chairs@ietf.org Date: Thu, 27 May 2021 14:29:19 +0000 Message-Id: In-Reply-To: References: Reply-To: "Paul E. Jones" User-Agent: eM_Client/8.2.1237.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB64CBC011-E524-465A-A11C-19CC1AA47BFC" Archived-At: Subject: Re: [Perc] AD review of draft-ietf-perc-dtls-tunnel 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, 27 May 2021 14:29:32 -0000 --------=_MB64CBC011-E524-465A-A11C-19CC1AA47BFC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Murray, Thanks. The funny syntax has been fixed; user error. :) I changed the reserved language and moved two related paragraphs=20 together: >>> CHANGED The value 0x00 is reserved and all values in the range 0x06 to 0xFF are available for allocation. The procedures for updating this table are=20 those defined as "IETF Review" in section 4.8 of [@!RFC8126]. <<<< (That is the syntax that will produce the correct result.) I also renamed the table to be "Message Type Values" rather than "Data=20 Type Values". Everywhere else, these are described as "message types"=20 (and the table header said the same). Paul ------ Original Message ------ From: "Murray S. Kucherawy" To: perc@ietf.org; perc-chairs@ietf.org Sent: 5/20/2021 3:20:54 AM Subject: [Perc] AD review of draft-ietf-perc-dtls-tunnel >Hi all, > >I've completed my AD review of this document. The only feedback I=20 >think I'd like to call out here before issuing an IETF Last Call is a=20 >few points about Section 8: > >* the last line has an "if" instead of an "of" > >* the RFC reference right after that appears funny ("[!@RFC####]"); did=20 >it not render correctly? > >* saying the remaining range is "reserved for future reservations"=20 >seems contradictory to me; "reserved" usually means "not available",=20 >but I actually think you mean "available" for new registrations that=20 >pass IETF Review, correct? > >-MSK --------=_MB64CBC011-E524-465A-A11C-19CC1AA47BFC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Murray,

Thanks.=C2=A0 The funny syntax has been fixed; user error. :)=

I changed the reserved language and moved two r= elated paragraphs together:

>>> CHANGED=
The value 0x00 is reserved and all values in the range 0x06 to 0= xFF are
available for allocation.=C2=A0 The procedures for updating this = table are those
defined as "IETF Review" in section 4.8 of [@!RFC8126].
<<<<

(That i= s the syntax that will produce the correct result.)

<= div>I also renamed the table to be "Message Type Values" rather than "Data= Type Values".=C2=A0 Everywhere else, these are described as "message types" = (and the table header said the same).

Paul

------ Original Message ------
From: "Murray S. Kucherawy" <superuser@gmail.com>
Sent: 5/20/2021 3:20:54 AM
Subject: [Perc] AD review of draft-ietf-perc-dtls-tunnel

Hi all,

I've completed my= AD review of this document.=C2=A0 The only feedback I think I'd like to cal= l out here before issuing an IETF Last Call is a few points about Section 8= :

* the last line has an "if" instead of an "of"

* the RFC reference right after that appears funny ("[!@R= FC####]"); did it not render correctly?

* saying the= remaining range is "reserved for future reservations" seems contradictory t= o me; "reserved" usually means "not available", but I actually think you me= an "available" for new registrations that pass IETF Review, correct?
<= div>
-MSK
--------=_MB64CBC011-E524-465A-A11C-19CC1AA47BFC-- From nobody Thu May 27 08:30:51 2021 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 780433A1335; Thu, 27 May 2021 08:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 cFkSH3-aIxPX; Thu, 27 May 2021 08:30:44 -0700 (PDT) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 1DCA13A1332; Thu, 27 May 2021 08:30:43 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id m9so575077vsq.5; Thu, 27 May 2021 08:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5N6AZIIQBiwgTfC78Gj+sbpCGh72bxFeCrYXoom0Moo=; b=Z7wzvPuR8S3cDxWRxZBFJ5KQobxCh2Z1nNyEhWa5Kmd7nsyCIzjmGwWP7cGbFCpkwr K/sAi8iU00QRDAyHvl8nHi1nV7cFSs8QinSaM02j+7wCFRo9mzx1H6QN71wjonB6rGaP NQ4cX+LNr2Id5k7wxArBC3lb3/i53UrMpnj81IRQkipTNXm1R2iXACxJRRcHJctksP8l 2d+DrcHXT0G1mAwFEBjCE7fB8WQ5Ro4IyrNpUrdmSnbjCk9EPQMC2vG5mc5S6qfcGb3z jYRI418jjCIdwMCe2sgcfTcL5BUkMzLZJLcRUdoVm8aZzlfZI0L24Y65B9vUiG+MC9dT hnCg== 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=5N6AZIIQBiwgTfC78Gj+sbpCGh72bxFeCrYXoom0Moo=; b=AQ5tqGYTrW5F1Dz9Nhm6GAyEIK4unsndwIzxR7WKNUJ9cDnDOxlTzGWFeZNS6VYfEQ JelW+fIMk2skDfQcaoZvOWbNp4VOVLsqaMA+GH/0T0vCU3/JMpyPcsJ4OPNzVSlw6tW4 /dwS4oFkOs8g8QEOAaw4xCMGFXSx13vhYTcMnIUnHUmNxrvNdMfrM2pIwZ9MN/wvhsnh Oqr5v8rBLNoiKrAVj3SekVdPC3m1NAQ5Gsr7B1o4+nL6FrsLSDZbq/abH59Vgy8tGUET J6L0+yVKQAeL6s8Cv4xy+eo9Ik4jRDHEGPFOjnpEsJbGMzbg3e6oF9FRf/+x1TgWVqnf hJnA== X-Gm-Message-State: AOAM533LtennSKyqzgSHLlrgso6H2Yhki75HuYSKil4Ds5JI/FDCv2J5 KANH5GDg4YgizcSbVbGXomEWPKGeUsydXatElnFaAqtMl58= X-Google-Smtp-Source: ABdhPJxoHucmRJ88Ovv181WLPvIkXo7YXvwk1qGIMocXMhty124oMfQml/4POJ/PL3XWZ7Dvqmjr+gkcrCqtNj3O9nU= X-Received: by 2002:a67:f702:: with SMTP id m2mr3321298vso.40.1622129442279; Thu, 27 May 2021 08:30:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Thu, 27 May 2021 08:30:30 -0700 Message-ID: To: "Paul E. Jones" Cc: perc@ietf.org, perc-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000002fd5e305c35171b8" Archived-At: Subject: Re: [Perc] AD review of draft-ietf-perc-dtls-tunnel 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, 27 May 2021 15:30:49 -0000 --0000000000002fd5e305c35171b8 Content-Type: text/plain; charset="UTF-8" Great, thanks! On Thu, May 27, 2021 at 7:29 AM Paul E. Jones wrote: > Murray, > > Thanks. The funny syntax has been fixed; user error. :) > > I changed the reserved language and moved two related paragraphs together: > > >>> CHANGED > The value 0x00 is reserved and all values in the range 0x06 to 0xFF are > available for allocation. The procedures for updating this table are > those > defined as "IETF Review" in section 4.8 of [@!RFC8126]. > <<<< > > (That is the syntax that will produce the correct result.) > > I also renamed the table to be "Message Type Values" rather than "Data > Type Values". Everywhere else, these are described as "message types" (and > the table header said the same). > > Paul > > ------ Original Message ------ > From: "Murray S. Kucherawy" > To: perc@ietf.org; perc-chairs@ietf.org > Sent: 5/20/2021 3:20:54 AM > Subject: [Perc] AD review of draft-ietf-perc-dtls-tunnel > > Hi all, > > I've completed my AD review of this document. The only feedback I think > I'd like to call out here before issuing an IETF Last Call is a few points > about Section 8: > > * the last line has an "if" instead of an "of" > > * the RFC reference right after that appears funny ("[!@RFC####]"); did it > not render correctly? > > * saying the remaining range is "reserved for future reservations" seems > contradictory to me; "reserved" usually means "not available", but I > actually think you mean "available" for new registrations that pass IETF > Review, correct? > > -MSK > > --0000000000002fd5e305c35171b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Great, thanks!

On Thu, May 27, 2021 at 7:29 AM Paul E.= Jones <paulej@packetizer.com> wrote:
Murray,

Thanks.=C2=A0 The funny syntax has= been fixed; user error. :)

I changed the reserved= language and moved two related paragraphs together:

>>> CHANGED
The value 0x00 is reserved and all values= in the range 0x06 to 0xFF are
available for allocation.=C2=A0 The procedures for updating this= table are those
defined as "IETF Review" in section 4.8 of [@!RFC8126]= .
<<<<

(That is = the syntax that will produce the correct result.)

= I also renamed the table to be "Message Type Values" rather than = "Data Type Values".=C2=A0 Everywhere else, these are described as= "message types" (and the table header said the same).
=
Paul

------ Original Message ------
Sent: 5/20/2021 3:20:54 AM
Subject: [Perc] AD review of draft-ietf-perc-dtls-tunnel
Hi all,

I've completed m= y AD review of this document.=C2=A0 The only feedback I think I'd like = to call out here before issuing an IETF Last Call is a few points about Sec= tion 8:

* the last line has an "if" instead of = an "of"

* the RFC reference right after that ap= pears funny ("[!@RFC####]"); did it not render correctly?

=
* saying the remaining range is "reserved for future reserv= ations" seems contradictory to me; "reserved" usually means = "not available", but I actually think you mean "available&qu= ot; for new registrations that pass IETF Review, correct?

-MSK
--0000000000002fd5e305c35171b8-- From nobody Fri May 28 08:16:15 2021 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 E4A7C3A2C0C; Fri, 28 May 2021 08:16:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley via Datatracker To: Cc: draft-ietf-perc-dtls-tunnel.all@ietf.org, last-call@ietf.org, perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162221496687.14173.2319711463541729432@ietfa.amsl.com> Reply-To: Russ Housley Date: Fri, 28 May 2021 08:16:06 -0700 Archived-At: Subject: [Perc] Genart last call review of draft-ietf-perc-dtls-tunnel-08 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: Fri, 28 May 2021 15:16:07 -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 wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-perc-dtls-tunnel-08 Reviewer: Russ Housley Review Date: 2021-05-28 IETF LC End Date: unknown IESG Telechat date: unknown Summary: Almost Ready Major Concerns: Section 9: The document has two different types of keying material: (1) keys for hop-by-hop encryption and authentication; and (2) keys for end-to-end encryption and authentication. The first two paragraphs of Section 9 talks about these two types of keying material. I think that the discussion should be expanded by a sentence or two to explain the security consequences of disclosure of each of theses keying material types. In addition, a pointer to the very extensive Security Consideration in RFC 8871 would he helpful. Minor Concerns: Section 5.4 says: "Each TLS tunnel established between the media distributor and the key distributor MUST be mutually authenticated." Is this a requirement to use DTLS client authentication? If so, please be explicit. If not, what other mechanisms for authentication are expected? Nits: Section 5.1, paragraph 2: s/[!@RFC4566]/[RFC4566]/ Section 5.5, paragraph 1: s/MUST utilize the same version/MUST contain the same version/ Section 8, last paragraph: s/section 4.8 if [!@RFC8126]/Section 4.8 of [RFC8126]/ Section 9, paragraph 1: s/keying material This does/keying material. This does/