From nobody Thu Aug 9 15:28:48 2018 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E0D12D949; Thu, 9 Aug 2018 15:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QBTSxOhtb90; Thu, 9 Aug 2018 15:28:44 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91505130DEA; Thu, 9 Aug 2018 15:28:41 -0700 (PDT) Received: from [10.0.1.95] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w79MSaP7048455 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 9 Aug 2018 17:28:40 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.95] From: Ben Campbell Content-Type: multipart/signed; boundary="Apple-Mail=_912B9659-E4CD-47EF-83EC-4B51CDD49520"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Thu, 9 Aug 2018 17:28:35 -0500 Cc: perc@ietf.org To: draft-ietf-perc-srtp-ekt-diet.all@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Perc] AD Evaluation of draft-ietf-perc-srtp-ekt-diet-08 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 22:28:47 -0000 --Apple-Mail=_912B9659-E4CD-47EF-83EC-4B51CDD49520 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, This is my AD Evaluation of draft-ietf-perc-srtp-ekt-diet-08. The document is mostly in good shape. It=E2=80=99s easy to read and = understand. However, I have a few substantive comments/questions and = some editorial comments. I would like to at least discuss the = substantive comments before going to IETF LC. Thanks! Ben. ---------- *** Substantive Comments: *** =C2=A73: Is there a reason not to use the RFC 8174 boilerplate? There = are at least a few instances of lowercase keywords in places that = don=E2=80=99t seem intended as normative. =C2=A74.2.1, first paragraph: Is there never a situation where you send = neither version? Also, did I miss a description of the purpose and = semantics for ShortEKTField, other than =E2=80=9Csend it when you = don=E2=80=99t send the full version=E2=80=9D? =C2=A74.2.2, step 3: "If the EKT decryption operation returns an = authentication failure, then the packet processing stops.=E2=80=9D ... and then what? - Step 6: "This applies in transforms such as [ I-D.ietf-perc-double] = for replacing just half the key, but SHOULD return a processing error = otherwise.=E2=80=9D I don=E2=80=99t understand that sentence. Is the point to say that using = a =E2=80=9Ctoo short=E2=80=9D key to replace part of the old key is only = valid for perc-double or similar transforms, and receiving one in other = contexts is an error? - Next Sentence: "Outbound packets SHOULD continue to use the old SRTP = Master Key for 250 ms after=E2=80=9D Does that imply a normative = requirement for recipients to keep old keys around for at least that = long? There=E2=80=99s currently an implementation suggestion about that, = but it doesn=E2=80=99t use MUST or SHOULD. (Editorial: The sentence seems to belong in the =E2=80=9Coutbound=E2=80=9D= section, not the =E2=80=9Cinbound=E2=80=9D section.) =C2=A74.3: - =E2=80=9C This ciphertext value MAY be cached by an SRTP receiver to minimize computational effort by noting when the SRTP master key is unchanged and avoiding repeating the steps defined in = .=E2=80=9D Are we really talking about the recipient? How would the recipient know = that the key has not changed without processing the ciphertext value? = (Also, the sentence is unfinished--maybe the answer would be clear if = the rest of the sentence came out of hiding :-) ) - =E2=80=9C The receiver may want to have a sliding window to retain old = SRTP Master Keys (and related context) for some brief period of time, so that out of order packets can be processed as well as packets sent during the time keys are changing.=E2=80=9D See comment to =C2=A74.2.2, step 6. =E2=80=9Cmay want=E2=80=9D seems = weak given that the sender SHOULD keep using the old key for a period of = time. =C2=A74.7: =E2=80=9CA new sender SHOULD send a packet containing the = FullEKTField as soon as possible...=E2=80=9D Why not MUST? Would it ever make sense not to do this? It seems like the = mechanism doesn=E2=80=99t work very well otherwise. =C2=A76, first paragraph: =E2=80=9Cor other=E2=80=9D - what other? - paragraph 8: =E2=80=9C An endpoint MUST NOT encrypt more than T = different FullEKTField values using the same EKTKey.=E2=80=9D Is there a reciprocal requirement for decryption? - last paragraph: =E2=80=9C...SHOULD be limited using the ekt_ttl=E2=80=9D= Why not MUST? =C2=A77.3: Should this cite RFC 5246 instead of RFC 4366? *** Editorial Comments: *** =C2=A72: =E2=80=9C...each endpoint picks there own SRTP master key...: s/their/its =C2=A74.1, first paragraph: Please reference figures by number. I can = imagine some future RFC rendering failing to maintain the relative = positions. (This occurs a few times throughout the document.) =C2=A74.2.2, step 3: Should "The EKTCiphertext authentication is checked and is decrypted=E2=80= =9D be something like =E2=80=9C The EKTCiphertext field authentication is checked and its contents = decrypted=E2=80=9D I assume you don=E2=80=99t mean to say its = authentication is decrypted. Also, there=E2=80=99s a number of occurrences of =E2=80=9CThe = [fieldname]...=E2=80=9D that should probably say =E2=80=9CThe = [fieldname] field...=E2=80=9D - Step 6: s/crypto/cryptographic - Step 7: is the replay protection part relevant to the step? =C2=A74.3, third paragraph: This is the first mention of ekt_ttl. It = would help to have a brief explanation or at least a forward reference. =C2=A74.6: s/ =E2=80=9Cother specification=E2=80=9D / =E2=80=9Canother = specification=E2=80=9D ; or =E2=80=9Cother specifications=E2=80=9D =C2=A74.7, third paragraph: Both occurrences of =E2=80=9Cwhich=E2=80=9D = need preceding commas. =C2=A75.2, paragraph after figure 4: =E2=80=9C ... the extensions = defined in this session allows the DTLS server...=E2=80=9D Defined in this =E2=80=9Csession=E2=80=9D or this =E2=80=9Csection=E2=80=9D= ? =C2=A7, paragraph 7: =E2=80=9C... causing the receiving system will = decrypt...=E2=80=9D s/will/to --Apple-Mail=_912B9659-E4CD-47EF-83EC-4B51CDD49520 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAltswBMACgkQgFZKbJXz 1A055xAArHBj6TR8KmzDn4Dwbof/YNhDB8fKZWFCO9QKCmvORiDjnNbWEuRUQSnK nLWYWD0MkotVrv4LTnN5exg+CInChLcdsGQgWNRcP8BNiXoeF/wIIrqfkjyhhyQE 6myeIZIF4pW+V8SCwyC7V+9e8AQrhmyKzKsdFF3MQ1TL1vvZqbSBpCkgO3ZyMzCu ie9SEkAHVxxjNUj9mMQ/c2q7f1PpZm2usydju7TOW2sd7hc/qhg1iBS+TMYIQEXE wkxG/kKjUqp9HlXd4Brpz4/9ddYxEsQCxUh3U2FECz+hp8W5VTfEHnC+qYTAVt4N vZdBpiwplPdY57Xz9cT7bbrbDMy24Y9EvXUsR5Ca0D87x146/Q5ErzQMlsGprUks 23VVYbJF4J0IBmkjFs6ateK7jAZUpp0hpKupkycxDr9Giq46xDYmRQuak9bVBdgr V7f1AYp9oAVHBSmvCPOjEAkMG+QbENo+Pxq1krLKaiFtDkhhRYcMc9bYEIzGEcVX 5aQ9cyukdcoXVmzP6cyDiyLUXzGnIs5875rPfxpuWraI+ElFxlY0VTF6uQ85puSq pDe6OWrFZLru0OB1btvYPsTvKgwRgHmISDt+fwnzHBMHUJHjeEwN3NVOGY1pvO0n 6mb+CWnFLfWK9cNhzZ8GwlJZAtI9x1DCxnVvFSP0DuHEdYBkhw8= =hEtU -----END PGP SIGNATURE----- --Apple-Mail=_912B9659-E4CD-47EF-83EC-4B51CDD49520-- From nobody Thu Aug 9 15:31:40 2018 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB16F130E25; Thu, 9 Aug 2018 15:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYp5yaTdSdeY; Thu, 9 Aug 2018 15:31:35 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9E1F1294D0; Thu, 9 Aug 2018 15:31:35 -0700 (PDT) Received: from [10.0.1.95] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w79MVUL2049117 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 9 Aug 2018 17:31:34 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.95] From: Ben Campbell Message-Id: <1E962CD5-74C9-403B-A909-F317425F9DEE@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_8F4103C9-E01D-4088-B570-7D2DEB0E7848"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 9 Aug 2018 17:31:29 -0500 In-Reply-To: Cc: perc@ietf.org To: draft-ietf-perc-srtp-ekt-diet.all@ietf.org References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Perc] AD Evaluation of draft-ietf-perc-srtp-ekt-diet-08 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 22:31:38 -0000 --Apple-Mail=_8F4103C9-E01D-4088-B570-7D2DEB0E7848 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Oops, missed a comment: Can we get an updated address and affiliation = for Dan Wing? Thanks! Ben. > On Aug 9, 2018, at 5:28 PM, Ben Campbell wrote: >=20 > Hi, >=20 > This is my AD Evaluation of draft-ietf-perc-srtp-ekt-diet-08. >=20 > The document is mostly in good shape. It=E2=80=99s easy to read and = understand. However, I have a few substantive comments/questions and = some editorial comments. I would like to at least discuss the = substantive comments before going to IETF LC. >=20 > Thanks! >=20 > Ben. >=20 > ---------- >=20 > *** Substantive Comments: *** >=20 >=20 > =C2=A73: Is there a reason not to use the RFC 8174 boilerplate? There = are at least a few instances of lowercase keywords in places that = don=E2=80=99t seem intended as normative. >=20 > =C2=A74.2.1, first paragraph: Is there never a situation where you = send neither version? Also, did I miss a description of the purpose and = semantics for ShortEKTField, other than =E2=80=9Csend it when you = don=E2=80=99t send the full version=E2=80=9D? >=20 > =C2=A74.2.2, step 3: "If the EKT decryption operation returns an = authentication failure, then the packet processing stops.=E2=80=9D >=20 > ... and then what? >=20 > - Step 6: "This applies in transforms such as [ I-D.ietf-perc-double] = for replacing just half the key, but SHOULD return a processing error = otherwise.=E2=80=9D >=20 > I don=E2=80=99t understand that sentence. Is the point to say that = using a =E2=80=9Ctoo short=E2=80=9D key to replace part of the old key = is only valid for perc-double or similar transforms, and receiving one = in other contexts is an error? >=20 > - Next Sentence: "Outbound packets SHOULD continue to use the old SRTP = Master Key for 250 ms after=E2=80=9D Does that imply a normative = requirement for recipients to keep old keys around for at least that = long? There=E2=80=99s currently an implementation suggestion about that, = but it doesn=E2=80=99t use MUST or SHOULD. > (Editorial: The sentence seems to belong in the =E2=80=9Coutbound=E2=80=9D= section, not the =E2=80=9Cinbound=E2=80=9D section.) >=20 > =C2=A74.3: >=20 > - =E2=80=9C This ciphertext value MAY be cached by an SRTP > receiver to minimize computational effort by noting when the SRTP > master key is unchanged and avoiding repeating the steps defined in = .=E2=80=9D >=20 > Are we really talking about the recipient? How would the recipient = know that the key has not changed without processing the ciphertext = value? (Also, the sentence is unfinished--maybe the answer would be = clear if the rest of the sentence came out of hiding :-) ) >=20 > - =E2=80=9C The receiver may want to have a sliding window to retain = old SRTP > Master Keys (and related context) for some brief period of time, so > that out of order packets can be processed as well as packets sent > during the time keys are changing.=E2=80=9D >=20 > See comment to =C2=A74.2.2, step 6. =E2=80=9Cmay want=E2=80=9D seems = weak given that the sender SHOULD keep using the old key for a period of = time. >=20 > =C2=A74.7: =E2=80=9CA new sender SHOULD send a packet containing the = FullEKTField as soon as possible...=E2=80=9D >=20 > Why not MUST? Would it ever make sense not to do this? It seems like = the mechanism doesn=E2=80=99t work very well otherwise. >=20 > =C2=A76, first paragraph: =E2=80=9Cor other=E2=80=9D - what other? >=20 > - paragraph 8: =E2=80=9C An endpoint MUST NOT encrypt more than T = different FullEKTField values using the same EKTKey.=E2=80=9D >=20 > Is there a reciprocal requirement for decryption? >=20 > - last paragraph: =E2=80=9C...SHOULD be limited using the ekt_ttl=E2=80=9D= >=20 > Why not MUST? >=20 > =C2=A77.3: Should this cite RFC 5246 instead of RFC 4366? >=20 > *** Editorial Comments: *** >=20 > =C2=A72: =E2=80=9C...each endpoint picks there own SRTP master key...: > s/their/its >=20 > =C2=A74.1, first paragraph: Please reference figures by number. I can = imagine some future RFC rendering failing to maintain the relative = positions. (This occurs a few times throughout the document.) >=20 > =C2=A74.2.2, step 3: > Should "The EKTCiphertext authentication is checked and is = decrypted=E2=80=9D be something like =E2=80=9C > The EKTCiphertext field authentication is checked and its contents = decrypted=E2=80=9D I assume you don=E2=80=99t mean to say its = authentication is decrypted. >=20 > Also, there=E2=80=99s a number of occurrences of =E2=80=9CThe = [fieldname]...=E2=80=9D that should probably say =E2=80=9CThe = [fieldname] field...=E2=80=9D >=20 > - Step 6: s/crypto/cryptographic >=20 > - Step 7: is the replay protection part relevant to the step? >=20 > =C2=A74.3, third paragraph: This is the first mention of ekt_ttl. It = would help to have a brief explanation or at least a forward reference. >=20 > =C2=A74.6: s/ =E2=80=9Cother specification=E2=80=9D / =E2=80=9Canother = specification=E2=80=9D ; or =E2=80=9Cother specifications=E2=80=9D >=20 > =C2=A74.7, third paragraph: Both occurrences of =E2=80=9Cwhich=E2=80=9D = need preceding commas. >=20 > =C2=A75.2, paragraph after figure 4: =E2=80=9C ... the extensions = defined in this session allows the DTLS server...=E2=80=9D > Defined in this =E2=80=9Csession=E2=80=9D or this =E2=80=9Csection=E2=80= =9D? >=20 > =C2=A7, paragraph 7: =E2=80=9C... causing the receiving system will = decrypt...=E2=80=9D > s/will/to >=20 >=20 >=20 >=20 --Apple-Mail=_8F4103C9-E01D-4088-B570-7D2DEB0E7848 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAltswMEACgkQgFZKbJXz 1A0WmA/+JALp0GGnaTcrOl32SvGkiylZ1ntMBd0wagWUM8Sf1OrO/j9f/MNdlGg1 Anu1NRUxUrwvAJzVep88lhNR6ztRdyDRtqfTgZVAmSW6NR9qHIoEG8qTt0mbTI1G T9ScdWdnWHY8Mt7fTeR7mfR05syb+Cubof76w9P/rqg+gOlRevDbEKuE278m8Nin yYe3xsWBIo/v4VXRG74lukwFV7YDcxvBkIQ7yaElJgPIn7LnncwaoK/mt40WkGDy AY+7XIJ+0IX928dxHc30CEs4MMH4B4tFXy6sGwRSLH2CAdV+D2p2lj019wR08dNN d9P0O7EvYOu7nzCZW6xq2uyYt9hzy6u3squn2IB7DE55Yew8VjIuiou9kZSWaTBT uGs+6ufSuEzXjmogqgPvI6mSXR/2NugVxO1FnCkafKoVCEVl9BvLlsFAifZV4Wu5 AN4/9M1RpKS/VW4/HGj3HKVRnmV+u7tXYluOgu8y2t/TpQ/JurUd+ofCdR2mkgEn uhxxXlE/mRdNnABObEQL1dxwLc5/P/Ww+is2NRFR1R2TFT/Tysg83RbCUennrXvD MHEqmXKsagXQATgxJLJYIDSAFAv5AAjO3XELnK7v4l3qzROVsBEA/ytYeBMVepZ1 MqXvklGnJuyX2OduRjS5UAJX1dT/4i3evlv/8sK+q/TafroJ9C0= =2eqM -----END PGP SIGNATURE----- --Apple-Mail=_8F4103C9-E01D-4088-B570-7D2DEB0E7848--