From nobody Mon Apr 2 15:59:47 2018 Return-Path: X-Original-To: art@ietf.org Delivered-To: art@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 35FF11252BA; Mon, 2 Apr 2018 15:59:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Peter Saint-Andre To: Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152270998513.17947.16209089088681034529@ietfa.amsl.com> Date: Mon, 02 Apr 2018 15:59:45 -0700 Archived-At: Subject: [art] Artart telechat review of draft-ietf-tram-stunbis-16 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 22:59:45 -0000 Reviewer: Peter Saint-Andre Review result: Ready with Nits Section 1 states: Implementations and deployments of a STUN usage using TLS or DTLS should follow the recommendations in [RFC7525]. Wouldn't the security considerations be a better location for that text? And given that this specification cites RFC 8174, I suggest changing "should" to "SHOULD". (I suggest that the authors review the usage of lowercase and uppercase requirements keywords, because there might be inconsistencies, e.g., in the first paragraphs of Section 6.1 and Section 6.2.) In Section 4, please consider spelling out "SIP" on first use and including a reference to RFC 3261. The first paragaraph of Section 6.2.3 restates recommendations from RFC 7525; why not simply reference that specification? Section 6.3.4 states: o If the error code is 500 through 599, the client MAY resend the request; clients that do so MUST limit the number of times they do this. It is reasonable to provide guidance as to the number of re-sends? Section 9.1.1 and other sections invoke the OpaqueString profile of the PRECIS FreeformClass; it might be helpful to mention that the profile is used to handle Unicode characters outside the ASCII range, and that no changes result if only ASCII characters are used. In Section 14.2, please consider spelling out "ALG" on first use. A reference to RFC 6151 seems appropriate regarding the fact that this specification retains the use of MD5; in particular, the usage here is actually HMAC-MD5, which is still sanctioned by RFC 6151. From nobody Mon Apr 16 16:43:44 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A82E12D77B; Mon, 16 Apr 2018 16:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 g7WVbaKAuQe4; Mon, 16 Apr 2018 16:43:36 -0700 (PDT) Received: from implementers.org (unknown [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7778C12D72F; Mon, 16 Apr 2018 16:43:36 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:f993:3fc0:2548:9f56] (unknown [IPv6:2601:648:8301:730f:f993:3fc0:2548:9f56]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 03A18AE844; Tue, 17 Apr 2018 01:43:32 +0200 (CEST) To: Peter Saint-Andre , art@ietf.org Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> From: Marc Petit-Huguenin Message-ID: Date: Mon, 16 Apr 2018 16:43:25 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <152270998513.17947.16209089088681034529@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wrT326OxbEtRBMlcX6rsyVx2RhvLD8BXB" Archived-At: Subject: Re: [art] Artart telechat review of draft-ietf-tram-stunbis-16 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 23:43:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wrT326OxbEtRBMlcX6rsyVx2RhvLD8BXB Content-Type: multipart/mixed; boundary="Jt9A28QuWskETTzYamIOMBVhRqz92RFHA"; protected-headers="v1" From: Marc Petit-Huguenin To: Peter Saint-Andre , art@ietf.org Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org Message-ID: Subject: Re: Artart telechat review of draft-ietf-tram-stunbis-16 References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> In-Reply-To: <152270998513.17947.16209089088681034529@ietfa.amsl.com> --Jt9A28QuWskETTzYamIOMBVhRqz92RFHA Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Peter, Thanks for the review and sorry for the delay in responding, I was travel= ing for the last 4 weeks. See my responses inline. On 04/02/2018 03:59 PM, Peter Saint-Andre wrote: > Reviewer: Peter Saint-Andre > Review result: Ready with Nits >=20 > Section 1 states: >=20 > Implementations and deployments of a STUN usage using TLS or DTLS > should follow the recommendations in [RFC7525]. >=20 > Wouldn't the security considerations be a better location for that text= ? Moved there. >=20 > And given that this specification cites RFC 8174, I suggest changing > "should" to "SHOULD". Done. >=20 > (I suggest that the authors review the usage of lowercase and uppercase= > requirements keywords, because there might be inconsistencies, e.g., in= > the first paragraphs of Section 6.1 and Section 6.2.) These sections are identical to RFC 5389 and so I am reluctant to modify = them as they already went through an IESG review. I reviewed the lowerca= se keywords in these two sections and did not find any specific case that= would create an interoperability issue, but please let me know if you th= ink otherwise. >=20 > In Section 4, please consider spelling out "SIP" on first use and > including a reference to RFC 3261. Done. >=20 > The first paragaraph of Section 6.2.3 restates recommendations from RFC= > 7525; why not simply reference that specification? The original text in RFC5389 said this: " When STUN is run by itself over TLS-over-TCP, the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented at a minimum. [...]" The new text is an attempt at updating it in the same spirit of giving mi= nimal instructions and complementing them with a reference to RFC 7525 - = which was the reason for the reference to RFC 7525 there. So I kept the text there, followed by the following paragraph, in additio= n of moving the original last paragraph in the Security Consideration sec= tion: " These recommendations are just a part of the the recommendations in [RFC7525] that implementations and deployments of a STUN usage using TLS or DTLS SHOULD follow." >=20 > Section 6.3.4 states: >=20 > o If the error code is 500 through 599, the client MAY resend the > request; clients that do so MUST limit the number of times they d= o > this. >=20 > It is reasonable to provide guidance as to the number of re-sends? Same issue here, that's a section that is unmodified from RFC 5389. As l= ong as the client does not enter an endless loop of retransmission, choos= ing different numbers of re-sends does not affect interoperability. >=20 > Section 9.1.1 and other sections invoke the OpaqueString profile of the= > PRECIS FreeformClass; it might be helpful to mention that the profile i= s > used to handle Unicode characters outside the ASCII range, and that no > changes result if only ASCII characters are used. Hmm. But in that case the application has first to test that the string = is in the ASCII range. Isn't that better to always assume that the input= string will contain Unicode, and let the implementation of OpaqueString = short-circuit the processing in the case of an all-ASCII string? >=20 > In Section 14.2, please consider spelling out "ALG" on first use. Done. >=20 > A reference to RFC 6151 seems appropriate regarding the fact that this > specification retains the use of MD5; in particular, the usage here is > actually HMAC-MD5, which is still sanctioned by RFC 6151. >=20 Done. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --Jt9A28QuWskETTzYamIOMBVhRqz92RFHA-- --wrT326OxbEtRBMlcX6rsyVx2RhvLD8BXB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlrVNR0ACgkQKcRFldZq fsSY2A/+JtNnslRVcf0zfAQbJvF9TXncq2p2Iv8inXLQQfv4rMj4FXI150HzxhYU ytUUN6s/I2gcjD+AERjXwyCjsU36W6SVwkfFVPwPzYh4J4Z1LLd6nJCGbmyf2J8W R2P+hkS7PI2zZNkLXzrK0nDFKfV6ZtXlWxVrd7HPyuYcgVw+V6nxrinlfNRbt3Oq qNdtpg1Qrp4M27Y/NWVVc3GUTFx3cGGwhlpBNvySyCtKk05uyEJuA22X7EZT9DFp OwcHUX/y7TFw/PFmBYSIUOaOhaH7PutwU+tsEaTQ/UssH/hDBe430N9KEmV/S3GK m6y0O8Mdr4yGHHoBFS8UOcpWmT1xA37fDE0MUiggvZwCtJI4C3IPjRZwhoYXGQxf mxBL+wP4tun+EWThqblmJYLm3AAmw8sfcj0TSj+A34FERweZUYu/6cKfNN9n71HB 0ofxfupxAJZakAGHld0mkmkinak8h79yK5rfWbj9T/5wnyyPhMlfa3WSkVj5BE+b bnPs28GX5dz/avDYVtjTkuE4QMIdNFU7cqhf//Kq302bKNTt9VdlLnqc+mXXq1e9 yC4Tx+nRDOGgv9YYXyXZ7f4XsBRGf26SJtM7jszsgOEQm8ccUjtfDzlGgAKd6qeZ Nu3e3LKJnFUApWptbgesoy1RxKFXge/QwAUFK6HisDAhFt92s7o= =1oCQ -----END PGP SIGNATURE----- --wrT326OxbEtRBMlcX6rsyVx2RhvLD8BXB-- From nobody Mon Apr 16 17:22:23 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3106712D94D for ; Mon, 16 Apr 2018 17:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 N5HWBRsQb2O8 for ; Mon, 16 Apr 2018 17:22:20 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 EDAC8127873 for ; Mon, 16 Apr 2018 17:22:19 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id s14so3532197ioc.0 for ; Mon, 16 Apr 2018 17:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=7+ws6D50gwwfnkvNh0mrKwGqev3OS2PSkvow0Cb3YLw=; b=IGGSzjJe5nor2jsbqbYfw0LxZClJdrUPwN4L109paW1y7aiIbhrsfdRcFgZTJr8Csh QoqBvncH0DKx6Xp/7fAfrwrMHegN2JZwq33j09++FBi5oKJFTk9UgXQIdJ/t+tIICN7s cyEUzt1GrCm+oFGMv266Hmv/x2YBSucVHkIxI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=7+ws6D50gwwfnkvNh0mrKwGqev3OS2PSkvow0Cb3YLw=; b=hYXQ6cW1Rh9+44JoFqViriC8CiIvWvuJQxH9+8WqVnIzfXlsoFZRv60wEkSJMbPPxu 10HsbCgEYTRwpJFWPN9FLe8N+zWMrHVmvoWVPb53TKoGKu0gmYZSggz5PvBzUxzsF0Sl zTNVlNSuVyGAnPCqEfqIyREpvxxOV8F+I78bTGTxm/MG+HSAoBkM0q9zUwpV1D/z/alr T5oquectUqTuhq6F4BpOxfPej46cATOTEWA3ywTBLiRuOOYCaUp3MVH2YK4PEJ2oYXAM bDKhDek61zg5FmgCGyirhQSvMYN9jeJiPKFt0QjwGA4mxKeVqntLSNFYoS5vxJh9O2w0 X1qg== X-Gm-Message-State: ALQs6tD0ZQz/kqMevHI85ddFV5ivNk9+ZXQO/Cjc/L8m79plwR3qSApJ L7uw13BKJBamj63fsBqQydEsDg== X-Google-Smtp-Source: AIpwx49FZRu0VJpi+P5nKrf1HtizWwZc7lmjyAMOOZ7FRLd1dVkwSugbqnTOgpnqHB3Q6j2ab7c3uw== X-Received: by 10.107.146.86 with SMTP id u83mr8089924iod.110.1523924539262; Mon, 16 Apr 2018 17:22:19 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id b195-v6sm5192192itb.22.2018.04.16.17.22.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Apr 2018 17:22:18 -0700 (PDT) To: Marc Petit-Huguenin , art@ietf.org Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: Date: Mon, 16 Apr 2018 18:22:17 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="yKq6lTWRoEdhfUFxtNTJ5NFOtrykyqKwH" Archived-At: Subject: Re: [art] Artart telechat review of draft-ietf-tram-stunbis-16 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 00:22:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --yKq6lTWRoEdhfUFxtNTJ5NFOtrykyqKwH Content-Type: multipart/mixed; boundary="lTWqg8rOIoLIFHGBTFCy5EECPoAVg8RYS"; protected-headers="v1" From: Peter Saint-Andre To: Marc Petit-Huguenin , art@ietf.org Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org Message-ID: Subject: Re: Artart telechat review of draft-ietf-tram-stunbis-16 References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> In-Reply-To: --lTWqg8rOIoLIFHGBTFCy5EECPoAVg8RYS Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Marc, a few further comments inline. On 4/16/18 5:43 PM, Marc Petit-Huguenin wrote: > Hi Peter, >=20 > Thanks for the review and sorry for the delay in responding, I was trav= eling for the last 4 weeks. >=20 > See my responses inline. >=20 > On 04/02/2018 03:59 PM, Peter Saint-Andre wrote: >> Reviewer: Peter Saint-Andre >> Review result: Ready with Nits >> >> The first paragaraph of Section 6.2.3 restates recommendations from RF= C >> 7525; why not simply reference that specification? >=20 > The original text in RFC5389 said this: >=20 > " When STUN is run by itself over TLS-over-TCP, the > TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented at a > minimum. [...]" >=20 > The new text is an attempt at updating it in the same spirit of giving = minimal instructions and complementing them with a reference to RFC 7525 = - which was the reason for the reference to RFC 7525 there. >=20 > So I kept the text there, followed by the following paragraph, in addit= ion of moving the original last paragraph in the Security Consideration s= ection: >=20 > " These recommendations are just a part of the the recommendations in > [RFC7525] that implementations and deployments of a STUN usage using > TLS or DTLS SHOULD follow." I would instead suggest that we do something like Section 2 of RFC 7590 for XMPP: The best current practices documented in the "Recommendations for Secure Use of TLS and DTLS" [RFC7525] are included here by reference. Instead of repeating those recommendations here, this document mostly provides supplementary information regarding secure implementation and deployment of XMPP technologies. Here's the rationale: RFC 7525 is likely to be updated/replaced more quickly than STUNbis. If STUNbis recommends a particular cipher suite that 7525bis stops recommending, in the absence of STUNter will STUN implementations keep following STUNbis or will they upgrade to whatever 7525bis recommends? I suggest it will be the former, which is not what we want. >> Section 6.3.4 states: >> >> o If the error code is 500 through 599, the client MAY resend the >> request; clients that do so MUST limit the number of times they = do >> this. >> >> It is reasonable to provide guidance as to the number of re-sends? >=20 > Same issue here, that's a section that is unmodified from RFC 5389.=20 I understand. Now is our chance to fix it. :-) > As long as the client does not enter an endless loop of retransmission= , choosing different numbers of re-sends does not affect interoperability= =2E Choosing different numbers is OK, but choosing an infinite number is not. Can we provide guidance as to how many is too many? 10? 50? 100? >> Section 9.1.1 and other sections invoke the OpaqueString profile of th= e >> PRECIS FreeformClass; it might be helpful to mention that the profile = is >> used to handle Unicode characters outside the ASCII range, and that no= >> changes result if only ASCII characters are used. >=20 > Hmm. But in that case the application has first to test that the strin= g is in the ASCII range. Isn't that better to always assume that the inp= ut string will contain Unicode, and let the implementation of OpaqueStrin= g short-circuit the processing in the case of an all-ASCII string? Yes, I meant that as an informational note to implementers so they would worry less. But it's not necessary and I think you can safely ignore it. Peter --lTWqg8rOIoLIFHGBTFCy5EECPoAVg8RYS-- --yKq6lTWRoEdhfUFxtNTJ5NFOtrykyqKwH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlrVPjkACgkQZWGMGH9o FKkiHQ/9Gcqq43e6sydBGErjTzpzLWp/zL4W9PtWZ2Ay7RQsyw5GbI6coS/5ifbA hjm6bqNlvZRf4z8WfHnZhw+0iIjXTFBDh7HaAFM9UR1pMSK/RGQOVo21E7LyIhmJ mSiVY5CgUSBnRNxw6VLxa22lnouUh/mlUK175rUsn/+l57GfC+lyIm1Qimhgx+ch Krt6S4YzeWgxSEZ0im7HQSa446Ok0UXopbFzusDEDW8SjOgsTUnJtCmq35YNE1rN FXlmLSewxEns4jXJIRHLXknSD9WZqeA4SH3zdY79kE0BW2JUW7UxuJj5oA0soKYo FYsl8ZlO0jhaX7o5kNJ+tfpJ2haJr1UedKOYrRa1AJ8ZeRVs3HpH8Ybt3IYfQyzX WvyZkfpafvf9JWrGja1ymRs0/+VuF3MndYx6XAF6QgSctuvf6IxUCv7i2tYGIRi4 TXmkwyrAt5x9VIoqL53m3auV817bXFyeswE+5db8RwGX8d3GXpVKFaJG0btGNPBs /kK0fKyflF4LOUOhoFquJgm+EdRdZOYoxgFi+tePjji9D0xRJrMY18RLrtz/aPZg fJ6QB/dM3CLsfG56Hc6OCNR6+R5ZTrg0kPiy5lnqt0b/d0C7oONnQayQxNomRzhG hhKOFItuwVrzbxBRQTa8XlDECAgO6OrPTS+Ummev8Tyj6Si6l2I= =kVa5 -----END PGP SIGNATURE----- --yKq6lTWRoEdhfUFxtNTJ5NFOtrykyqKwH-- From nobody Mon Apr 16 20:13:08 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FCE12D87D for ; Mon, 16 Apr 2018 20:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-R3aW6jsJQu for ; Mon, 16 Apr 2018 20:12:50 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 4CC3E12D889 for ; Mon, 16 Apr 2018 20:12:47 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id p62-v6so277770oie.10 for ; Mon, 16 Apr 2018 20:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IFyy3t3f0w0rhVjJObNoYJJtzFuxyS23dHdKVg3cEtI=; b=Uabz2hEV1L95r9xO7bk+BDXYHH6c/nNQ9J5k4y2jp8s8Gsfv+/V4uOfGyh4vO/n/pm JN7FD81Dxil+kCz7xPAqUQavF71zatXeB3mSd6J7qvc5kiYJ6IQ+/vB48B8rzDWtu6j6 llFMpKLPJptwQXtYyLHk7yY+FlasVQ9ayu0MogCe7/pJ0OAI/eSxmn2xKiF8M+OSX/qc 8LMyYN7p9BGGSksRucFfBemarC+6qp1RMyGw8TLnQTW1XghwH75QUzfHKvU8tfMNcyLZ ZmK1Led0y7/lgeKtone/5nefxM9kJufc0WdOQkQ0XyK/u6SAXSlAhL5PJL9gF9ZotvUe ZkIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IFyy3t3f0w0rhVjJObNoYJJtzFuxyS23dHdKVg3cEtI=; b=V5Sb+VBcpiAbphBGHxBVt9p/oFanRYuPgUm6NyPk/IDCDaP8cciFarVJptmW4olOoU B/knHJCTukfmpb7aYU430JsnW8FKl3njGQkKZqtybGqZRZZaoNFsVMcTKL1VkQG/EDFj Wd/0KhBGIUnxFkty6lgX53kQzJt/xqbZ6EB2SalFx3JTnlXqdQ+B9VTqq/waJ8tgD22W 9JBGncCLjOiqcutKhM+y4RZCFojS9GeoK0FJQK3VcA+W6OMUaaQSJpbOkBCyLLyE2giT nWBQuyWugR/UFLPVPAK2pJOBFQ31Y/o8y84gRmtZj1WbuRCW8LKjdVn5vJztx8BDJ3U9 mC7Q== X-Gm-Message-State: ALQs6tBsO8ZMP/BfZDImYUhyYtOc5OllP6Z6/IADrJrGvSlBQOPQwRms 1ROg4PI30A88KbfzOZ4daKafYjm40nqO4hMa6XhbLw== X-Google-Smtp-Source: AIpwx48gZ1dREmC4TUjWmRKeij2o3UNmiqYKklONGKzy+ZhTa0gkVk8QR50gvCjulj3ZWq8RC9bOoODT6hhGCnEnLw4= X-Received: by 2002:aca:4f46:: with SMTP id d67-v6mr184561oib.138.1523934766633; Mon, 16 Apr 2018 20:12:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.132 with HTTP; Mon, 16 Apr 2018 20:12:06 -0700 (PDT) In-Reply-To: References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> From: Eric Rescorla Date: Mon, 16 Apr 2018 20:12:06 -0700 Message-ID: To: Peter Saint-Andre Cc: Marc Petit-Huguenin , art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, IETF discussion list , tram@ietf.org Content-Type: multipart/alternative; boundary="0000000000006d32cd056a02b694" Archived-At: Subject: Re: [art] Artart telechat review of draft-ietf-tram-stunbis-16 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 03:12:52 -0000 --0000000000006d32cd056a02b694 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 16, 2018 at 5:22 PM, Peter Saint-Andre wrote: > Hi Marc, a few further comments inline. > > On 4/16/18 5:43 PM, Marc Petit-Huguenin wrote: > > Hi Peter, > > > > Thanks for the review and sorry for the delay in responding, I was > traveling for the last 4 weeks. > > > > See my responses inline. > > > > On 04/02/2018 03:59 PM, Peter Saint-Andre wrote: > >> Reviewer: Peter Saint-Andre > >> Review result: Ready with Nits > >> > > > > >> The first paragaraph of Section 6.2.3 restates recommendations from RFC > >> 7525; why not simply reference that specification? > > > > The original text in RFC5389 said this: > > > > " When STUN is run by itself over TLS-over-TCP, the > > TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented at a > > minimum. [...]" > > > > The new text is an attempt at updating it in the same spirit of giving > minimal instructions and complementing them with a reference to RFC 7525 - > which was the reason for the reference to RFC 7525 there. > > > > So I kept the text there, followed by the following paragraph, in > addition of moving the original last paragraph in the Security > Consideration section: > > > > " These recommendations are just a part of the the recommendations in > > [RFC7525] that implementations and deployments of a STUN usage using > > TLS or DTLS SHOULD follow." > > I would instead suggest that we do something like Section 2 of RFC 7590 > for XMPP: > > The best current practices documented in the "Recommendations for > Secure Use of TLS and DTLS" [RFC7525] are included here by reference. > Instead of repeating those recommendations here, this document mostly > provides supplementary information regarding secure implementation > and deployment of XMPP technologies. > > Here's the rationale: RFC 7525 is likely to be updated/replaced more > quickly than STUNbis. If STUNbis recommends a particular cipher suite > that 7525bis stops recommending, in the absence of STUNter will STUN > implementations keep following STUNbis or will they upgrade to whatever > 7525bis recommends? I suggest it will be the former, which is not what > we want. > I forgot about this in my review, but you should also profile ciphers for TLS 1.3. -Ekr >> Section 6.3.4 states: > >> > >> o If the error code is 500 through 599, the client MAY resend the > >> request; clients that do so MUST limit the number of times they do > >> this. > >> > >> It is reasonable to provide guidance as to the number of re-sends? > > > > Same issue here, that's a section that is unmodified from RFC 5389. > > I understand. Now is our chance to fix it. :-) > > > As long as the client does not enter an endless loop of retransmission, > choosing different numbers of re-sends does not affect interoperability. > > Choosing different numbers is OK, but choosing an infinite number is > not. Can we provide guidance as to how many is too many? 10? 50? 100? > > >> Section 9.1.1 and other sections invoke the OpaqueString profile of the > >> PRECIS FreeformClass; it might be helpful to mention that the profile is > >> used to handle Unicode characters outside the ASCII range, and that no > >> changes result if only ASCII characters are used. > > > > Hmm. But in that case the application has first to test that the string > is in the ASCII range. Isn't that better to always assume that the input > string will contain Unicode, and let the implementation of OpaqueString > short-circuit the processing in the case of an all-ASCII string? > > Yes, I meant that as an informational note to implementers so they would > worry less. But it's not necessary and I think you can safely ignore it. > > Peter > > --0000000000006d32cd056a02b694 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Apr 16, 2018 at 5:22 PM, Peter Saint-Andre &l= t;stpeter@mozilla.= com> wrote:
Hi Marc, a few = further comments inline.

On 4/16/18 5:43 PM, Marc Petit-Huguenin wrote:
> Hi Peter,
>
> Thanks for the review and sorry for the delay in responding, I was tra= veling for the last 4 weeks.
>
> See my responses inline.
>
> On 04/02/2018 03:59 PM, Peter Saint-Andre wrote:
>> Reviewer: Peter Saint-Andre
>> Review result: Ready with Nits
>>

<snip/>

>> The first paragaraph of Section 6.2.3 restates recommendations fro= m RFC
>> 7525; why not simply reference that specification?
>
> The original text in RFC5389 said this:
>
> " When STUN is run by itself over TLS-over-TCP, the
>=C2=A0 =C2=A0TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implement= ed at a
>=C2=A0 =C2=A0minimum. [...]"
>
> The new text is an attempt at updating it in the same spirit of giving= minimal instructions and complementing them with a reference to RFC 7525 -= which was the reason for the reference to RFC 7525 there.
>
> So I kept the text there, followed by the following paragraph, in addi= tion of moving the original last paragraph in the Security Consideration se= ction:
>
> " These recommendations are just a part of the the recommendation= s in
>=C2=A0 =C2=A0[RFC7525] that implementations and deployments of a STUN u= sage using
>=C2=A0 =C2=A0TLS or DTLS SHOULD follow."

I would instead suggest that we do something like Section 2 of RFC 7= 590
for XMPP:

=C2=A0 =C2=A0The best current practices documented in the "Recommendat= ions for
=C2=A0 =C2=A0Secure Use of TLS and DTLS" [RFC7525] are included here b= y reference.
=C2=A0 =C2=A0Instead of repeating those recommendations here, this document= mostly
=C2=A0 =C2=A0provides supplementary information regarding secure implementa= tion
=C2=A0 =C2=A0and deployment of XMPP technologies.

Here's the rationale: RFC 7525 is likely to be updated/replaced more quickly than STUNbis. If STUNbis recommends a particular cipher suite
that 7525bis stops recommending, in the absence of STUNter will STUN
implementations keep following STUNbis or will they upgrade to whatever
7525bis recommends? I suggest it will be the former, which is not what
we want.

I forgot about thi= s in my review, but you should also profile ciphers for TLS 1.3.
=
-Ekr

>> Section 6.3.4 states:
>>
>>=C2=A0 =C2=A0 o=C2=A0 If the error code is 500 through 599, the cli= ent MAY resend the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0request; clients that do so MUST limit t= he number of times they do
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0this.
>>
>> It is reasonable to provide guidance as to the number of re-sends?=
>
> Same issue here, that's a section that is unmodified from RFC 5389= .

I understand. Now is our chance to fix it. :-)

>=C2=A0 As long as the client does not enter an endless loop of retransm= ission, choosing different numbers of re-sends does not affect interoperabi= lity.

Choosing different numbers is OK, but choosing an infinite number is=
not. Can we provide guidance as to how many is too many? 10? 50? 100?

>> Section 9.1.1 and other sections invoke the OpaqueString profile o= f the
>> PRECIS FreeformClass; it might be helpful to mention that the prof= ile is
>> used to handle Unicode characters outside the ASCII range, and tha= t no
>> changes result if only ASCII characters are used.
>
> Hmm.=C2=A0 But in that case the application has first to test that the= string is in the ASCII range.=C2=A0 Isn't that better to always assume= that the input string will contain Unicode, and let the implementation of = OpaqueString short-circuit the processing in the case of an all-ASCII strin= g?

Yes, I meant that as an informational note to implementers so they w= ould
worry less. But it's not necessary and I think you can safely ignore it= .

Peter


--0000000000006d32cd056a02b694-- From nobody Tue Apr 17 03:00:26 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC30112D779; Tue, 17 Apr 2018 03:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 2AFpUJ5Xl1HV; Tue, 17 Apr 2018 03:00:16 -0700 (PDT) Received: from implementers.org (unknown [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECD0612762F; Tue, 17 Apr 2018 03:00:15 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:f993:3fc0:2548:9f56] (unknown [IPv6:2601:648:8301:730f:f993:3fc0:2548:9f56]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 9340CAE8D8; Tue, 17 Apr 2018 12:00:12 +0200 (CEST) To: Peter Saint-Andre , art@ietf.org Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> From: Marc Petit-Huguenin Message-ID: <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> Date: Tue, 17 Apr 2018 03:00:09 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kuGjWJaKegyCNzuRL9CzladtYkEpyPgNl" Archived-At: Subject: Re: [art] Artart telechat review of draft-ietf-tram-stunbis-16 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 10:00:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kuGjWJaKegyCNzuRL9CzladtYkEpyPgNl Content-Type: multipart/mixed; boundary="fnF6DRKn4WOd5H0ugYlTGpALhvdtfMAjs"; protected-headers="v1" From: Marc Petit-Huguenin To: Peter Saint-Andre , art@ietf.org Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org Message-ID: <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> Subject: Re: Artart telechat review of draft-ietf-tram-stunbis-16 References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> In-Reply-To: --fnF6DRKn4WOd5H0ugYlTGpALhvdtfMAjs Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/16/2018 05:22 PM, Peter Saint-Andre wrote: > Hi Marc, a few further comments inline. >=20 > On 4/16/18 5:43 PM, Marc Petit-Huguenin wrote: >> Hi Peter, >> >> Thanks for the review and sorry for the delay in responding, I was tra= veling for the last 4 weeks. >> >> See my responses inline. >> >> On 04/02/2018 03:59 PM, Peter Saint-Andre wrote: >>> Reviewer: Peter Saint-Andre >>> Review result: Ready with Nits >>> >=20 > >=20 >>> The first paragaraph of Section 6.2.3 restates recommendations from R= FC >>> 7525; why not simply reference that specification? >> >> The original text in RFC5389 said this: >> >> " When STUN is run by itself over TLS-over-TCP, the >> TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented at a >> minimum. [...]" >> >> The new text is an attempt at updating it in the same spirit of giving= minimal instructions and complementing them with a reference to RFC 7525= - which was the reason for the reference to RFC 7525 there. >> >> So I kept the text there, followed by the following paragraph, in addi= tion of moving the original last paragraph in the Security Consideration = section: >> >> " These recommendations are just a part of the the recommendations in >> [RFC7525] that implementations and deployments of a STUN usage using= >> TLS or DTLS SHOULD follow." >=20 > I would instead suggest that we do something like Section 2 of RFC 7590= > for XMPP: >=20 > The best current practices documented in the "Recommendations for > Secure Use of TLS and DTLS" [RFC7525] are included here by reference= =2E > Instead of repeating those recommendations here, this document mostl= y > provides supplementary information regarding secure implementation > and deployment of XMPP technologies. >=20 > Here's the rationale: RFC 7525 is likely to be updated/replaced more > quickly than STUNbis. If STUNbis recommends a particular cipher suite > that 7525bis stops recommending, in the absence of STUNter will STUN > implementations keep following STUNbis or will they upgrade to whatever= > 7525bis recommends? I suggest it will be the former, which is not what > we want. All right, makes sense. I'll add something like this on my next round of= reviews, most likely this Friday. >=20 >>> Section 6.3.4 states: >>> >>> o If the error code is 500 through 599, the client MAY resend the= >>> request; clients that do so MUST limit the number of times they= do >>> this. >>> >>> It is reasonable to provide guidance as to the number of re-sends? >> >> Same issue here, that's a section that is unmodified from RFC 5389.=20 >=20 > I understand. Now is our chance to fix it. :-) >=20 >> As long as the client does not enter an endless loop of retransmissio= n, choosing different numbers of re-sends does not affect interoperabilit= y. >=20 > Choosing different numbers is OK, but choosing an infinite number is > not. Can we provide guidance as to how many is too many? 10? 50? 100? Well, the text already states that an infinite number of of re-sends is n= ot compliant. Anyway, I am not sure how to determine a reasonable number= , but I'll try. >=20 >>> Section 9.1.1 and other sections invoke the OpaqueString profile of t= he >>> PRECIS FreeformClass; it might be helpful to mention that the profile= is >>> used to handle Unicode characters outside the ASCII range, and that n= o >>> changes result if only ASCII characters are used. >> >> Hmm. But in that case the application has first to test that the stri= ng is in the ASCII range. Isn't that better to always assume that the in= put string will contain Unicode, and let the implementation of OpaqueStri= ng short-circuit the processing in the case of an all-ASCII string? >=20 > Yes, I meant that as an informational note to implementers so they woul= d > worry less. But it's not necessary and I think you can safely ignore it= =2E >=20 > Peter >=20 --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --fnF6DRKn4WOd5H0ugYlTGpALhvdtfMAjs-- --kuGjWJaKegyCNzuRL9CzladtYkEpyPgNl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlrVxaoACgkQKcRFldZq fsRINw//SfqycpcdyLn9xQNNVz6DD6XHz7GmwfwRaevw90L42FzQfn0fIbilp+7o MhG+CW3vfUPdCQwGatDSp97xJ44TdQW/D54/31rLeD+4iYSlenect9P+QfZVIWV1 uypAgTwJJ38slb1Nz8DTMw2UQVQWyd7bdzMj0ICi1Q2Nae8zEI5ouF9DrUcMOTDG 5pFF4CBYxJ7Cu4gOy8yqBcR3dQUll0Y7SPZbF0+7De7s+1i4acA/v0/PxgSDBTQC Cm5LxQNdmvHrz613jgVo+YbGt69N6gFRpxaTfxhslq/BmuHuA+kBmgjlwd4vDLwH kHFomjucOCgof89m0ESKS66OGXhV2ZhiGcpQAQbS52iRbEUIUnKwzWWHyddARSiJ tAFFwK0+qAu2wE6uDGP3yneNuuAYDzSRRshyl4D2QPEJjkslhlJFMD4HSGYPQkaP E2SD/5zufn2U0XtmlaJoQKMYe14qUELwlCSW0IMZlOZYm92/mOIWShCWKJMeaFjJ rBYcNfgRTFOAdPacsN5cih+Dah1pLh9P0Mf/++Khcpn6UO9+tjDqTvaj0rHCxI/N IbgqVdYANKjmT78X/wzhLz42z8wo26mucPt0xl5UUII0HDKadRRqpfNbXXHwVw4I 6X8WBoyWlGus56cGyOOoul7zokVYTl3fGE3vDLF6AKUCB+3uRpE= =futH -----END PGP SIGNATURE----- --kuGjWJaKegyCNzuRL9CzladtYkEpyPgNl-- From nobody Tue Apr 17 03:02:50 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E48512D969; Tue, 17 Apr 2018 03:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 sYc7UUAa7YRA; Tue, 17 Apr 2018 03:02:41 -0700 (PDT) Received: from implementers.org (unknown [92.243.22.217]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5870012D779; Tue, 17 Apr 2018 03:02:41 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:f993:3fc0:2548:9f56] (unknown [IPv6:2601:648:8301:730f:f993:3fc0:2548:9f56]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id DE1EBAE8D8; Tue, 17 Apr 2018 12:02:38 +0200 (CEST) To: Eric Rescorla , Peter Saint-Andre Cc: art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, IETF discussion list , tram@ietf.org References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> From: Marc Petit-Huguenin Message-ID: Date: Tue, 17 Apr 2018 03:02:37 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="m94vs86lfj5OjTdRIFDz8QZiMGYdMacl9" Archived-At: Subject: Re: [art] Artart telechat review of draft-ietf-tram-stunbis-16 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 10:02:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --m94vs86lfj5OjTdRIFDz8QZiMGYdMacl9 Content-Type: multipart/mixed; boundary="IvgNIkT3boszypQnuEpfZFm1rJe1brc9I"; protected-headers="v1" From: Marc Petit-Huguenin To: Eric Rescorla , Peter Saint-Andre Cc: art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, IETF discussion list , tram@ietf.org Message-ID: Subject: Re: Artart telechat review of draft-ietf-tram-stunbis-16 References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> In-Reply-To: --IvgNIkT3boszypQnuEpfZFm1rJe1brc9I Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/16/2018 08:12 PM, Eric Rescorla wrote: > On Mon, Apr 16, 2018 at 5:22 PM, Peter Saint-Andre > wrote: >=20 >> Hi Marc, a few further comments inline. >> >> On 4/16/18 5:43 PM, Marc Petit-Huguenin wrote: >>> Hi Peter, >>> >>> Thanks for the review and sorry for the delay in responding, I was >> traveling for the last 4 weeks. >>> >>> See my responses inline. >>> >>> On 04/02/2018 03:59 PM, Peter Saint-Andre wrote: >>>> Reviewer: Peter Saint-Andre >>>> Review result: Ready with Nits >>>> >> >> >> >>>> The first paragaraph of Section 6.2.3 restates recommendations from = RFC >>>> 7525; why not simply reference that specification? >>> >>> The original text in RFC5389 said this: >>> >>> " When STUN is run by itself over TLS-over-TCP, the >>> TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented at a >>> minimum. [...]" >>> >>> The new text is an attempt at updating it in the same spirit of givin= g >> minimal instructions and complementing them with a reference to RFC 75= 25 - >> which was the reason for the reference to RFC 7525 there. >>> >>> So I kept the text there, followed by the following paragraph, in >> addition of moving the original last paragraph in the Security >> Consideration section: >>> >>> " These recommendations are just a part of the the recommendations in= >>> [RFC7525] that implementations and deployments of a STUN usage usin= g >>> TLS or DTLS SHOULD follow." >> >> I would instead suggest that we do something like Section 2 of RFC 759= 0 >> for XMPP: >> >> The best current practices documented in the "Recommendations for >> Secure Use of TLS and DTLS" [RFC7525] are included here by referenc= e. >> Instead of repeating those recommendations here, this document most= ly >> provides supplementary information regarding secure implementation >> and deployment of XMPP technologies. >> >> Here's the rationale: RFC 7525 is likely to be updated/replaced more >> quickly than STUNbis. If STUNbis recommends a particular cipher suite >> that 7525bis stops recommending, in the absence of STUNter will STUN >> implementations keep following STUNbis or will they upgrade to whateve= r >> 7525bis recommends? I suggest it will be the former, which is not what= >> we want. >> >=20 > I forgot about this in my review, but you should also profile ciphers f= or > TLS 1.3. >=20 > -Ekr >=20 Do you have any suggestion for these, or a pointer to a document that I c= an use to find these? Thanks. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --IvgNIkT3boszypQnuEpfZFm1rJe1brc9I-- --m94vs86lfj5OjTdRIFDz8QZiMGYdMacl9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlrVxj0ACgkQKcRFldZq fsTh9xAAzQyZk9dku3LN3poVPDQjWP31jKLaa8KEUESMU/i9te5w8YFcBOStsVMy SmypWXkWRTpNEIAnHU4Y0rWzjctrYuS8vq4MMGBKG/litcFUd0zI4x/0OSHQGi8X Fww0a8GEC85VD+G5Dm+kcgQyiJfIkptiGLP1zlFfpGklTrohqCpBorburKdOagyX ijYTGOGjCKYOqRTrcEO5aavrCFLI93xqvUv/YM2G9NY9rvR574KN3lkDlQQFQzOF nOPOVlO/dgVz/f/6xGr62r6gjJ+DcNXv6bzu8kqBJQkaIayEci+5wZTTd0a1ZvlN P2X5eexEJxr1Uf/p9qsOIu5lol8fGMSEPu/kwSpYa0FOEUA6wEvhFaogYkjGv5a/ j3pzMqBuMVTegu7wJEhFcD7dO+silAz/xZ8KUkF2z1t1x6B4pVmbBLYC0EXfVS2B tRjcJMSZDLevD9fOS6rWKj7fiwBl+xgqqV2Cjvlhm7USXrHoeoojz8kSuNJHQFkq dZuo514bqDkSX8N3+X/EbcIAHl4qFo5Yn2vZlizcVCBZjkLb+E/U9cJslIOztE/2 peglVe+N5PfbvdCrObKb0EJuy1AgTwSaSEZnfp/SnZQujsgZFVv5p1BvTMlSDL0C 3HNfDg1iRKHbo5qGQSpCg0DVxGLPchnNphITIzZjgaKHqrZUTGI= =WVuG -----END PGP SIGNATURE----- --m94vs86lfj5OjTdRIFDz8QZiMGYdMacl9-- From nobody Tue Apr 17 08:11:45 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E916124E15 for ; Tue, 17 Apr 2018 08:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 BxwqJBEYv2qP for ; Tue, 17 Apr 2018 08:11:37 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 7FDE0126E64 for ; Tue, 17 Apr 2018 08:11:31 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id q85-v6so16665130itc.0 for ; Tue, 17 Apr 2018 08:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=sJkXUTBXGjPk3Ho8T8cgHrXWxbFhVPamFiAhcv/PcTA=; b=QDeeUZT5j4AY+z0AcHtGQBvFkcLMAoLZ2bgCU6VaXg423nEn/vF3xuBbSiqqtvXFom S44oHgAqxKqcR6e3QiOrPIH5IndgPAXAcW/0TnJmjsvYrQDPo4zOXkKFXr4Q9J5GfitA aL7CKMpDscoDzrK7uSZil7ubV1+AfaMPOoDrQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=sJkXUTBXGjPk3Ho8T8cgHrXWxbFhVPamFiAhcv/PcTA=; b=UWNrss6D2GLfOrfbhY5uZw+f8c9wQ2exyuKTEngJrDnUoZdj2kaurXftL8kQ87daS/ iSsgEYFA2PzVmPFOmyt0mmR9Lt0le520yxaUWqn3MV1+LACYknb0kUDqlrc46iOrYcwS isWNOsBK96GJsZ95DQn2jnfOV65I/JMVfb9o+IvRlHoCO268OfEmUDzHig4aR5qateBy bgX7wnSBHFBWum3i+DYJ5LFesblOcUU6TftXKMpZtIURZ1tAn7RBopE47ZWsIQ3D3zL8 V5EZua/PGFRnA7oaQsa3pKFN9IcdMsP9ZMH0xpCj+3gMVBgoYDPj6ihoD/2w6jrMAvOf UhVg== X-Gm-Message-State: ALQs6tC3QXOSPdwt4fQoGzR8OV7vMS7jZ1t8I6Yk8LWvt7dllVN1Sxfe /WqnV8WskzmQ4QRrJuNXbHf8yg== X-Google-Smtp-Source: AIpwx49cYMRRzaUGTjQ9/+2HFCbBc1wCdD0uO3/epGbl/xfd0XUJqxBczqWUrnkdtHPdtv/3+/NVmw== X-Received: by 2002:a24:7b52:: with SMTP id q79-v6mr1470247itc.133.1523977890680; Tue, 17 Apr 2018 08:11:30 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id n67sm536303ioe.20.2018.04.17.08.11.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Apr 2018 08:11:29 -0700 (PDT) To: Marc Petit-Huguenin , Eric Rescorla Cc: art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, IETF discussion list , tram@ietf.org References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: Date: Tue, 17 Apr 2018 09:11:28 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NuKo0xXfEVPVs8NxhRQwahgAzEn0HW3RQ" Archived-At: Subject: Re: [art] Artart telechat review of draft-ietf-tram-stunbis-16 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 15:11:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NuKo0xXfEVPVs8NxhRQwahgAzEn0HW3RQ Content-Type: multipart/mixed; boundary="uwDOAXETWazvkzTXacLfdYdapW8huEFyf"; protected-headers="v1" From: Peter Saint-Andre To: Marc Petit-Huguenin , Eric Rescorla Cc: art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, IETF discussion list , tram@ietf.org Message-ID: Subject: Re: Artart telechat review of draft-ietf-tram-stunbis-16 References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> In-Reply-To: --uwDOAXETWazvkzTXacLfdYdapW8huEFyf Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 4/17/18 4:02 AM, Marc Petit-Huguenin wrote: >=20 > On 04/16/2018 08:12 PM, Eric Rescorla wrote: >> On Mon, Apr 16, 2018 at 5:22 PM, Peter Saint-Andre >> wrote: >> >>> Hi Marc, a few further comments inline. >>> >>> On 4/16/18 5:43 PM, Marc Petit-Huguenin wrote: >>>> Hi Peter, >>>> >>>> Thanks for the review and sorry for the delay in responding, I was >>> traveling for the last 4 weeks. >>>> >>>> See my responses inline. >>>> >>>> On 04/02/2018 03:59 PM, Peter Saint-Andre wrote: >>>>> Reviewer: Peter Saint-Andre >>>>> Review result: Ready with Nits >>>>> >>> >>> >>> >>>>> The first paragaraph of Section 6.2.3 restates recommendations from= RFC >>>>> 7525; why not simply reference that specification? >>>> >>>> The original text in RFC5389 said this: >>>> >>>> " When STUN is run by itself over TLS-over-TCP, the >>>> TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented at a >>>> minimum. [...]" >>>> >>>> The new text is an attempt at updating it in the same spirit of givi= ng >>> minimal instructions and complementing them with a reference to RFC 7= 525 - >>> which was the reason for the reference to RFC 7525 there. >>>> >>>> So I kept the text there, followed by the following paragraph, in >>> addition of moving the original last paragraph in the Security >>> Consideration section: >>>> >>>> " These recommendations are just a part of the the recommendations i= n >>>> [RFC7525] that implementations and deployments of a STUN usage usi= ng >>>> TLS or DTLS SHOULD follow." >>> >>> I would instead suggest that we do something like Section 2 of RFC 75= 90 >>> for XMPP: >>> >>> The best current practices documented in the "Recommendations for >>> Secure Use of TLS and DTLS" [RFC7525] are included here by referen= ce. >>> Instead of repeating those recommendations here, this document mos= tly >>> provides supplementary information regarding secure implementation= >>> and deployment of XMPP technologies. >>> >>> Here's the rationale: RFC 7525 is likely to be updated/replaced more >>> quickly than STUNbis. If STUNbis recommends a particular cipher suite= >>> that 7525bis stops recommending, in the absence of STUNter will STUN >>> implementations keep following STUNbis or will they upgrade to whatev= er >>> 7525bis recommends? I suggest it will be the former, which is not wha= t >>> we want. >>> >> >> I forgot about this in my review, but you should also profile ciphers = for >> TLS 1.3. >> >> -Ekr >> >=20 > Do you have any suggestion for these, or a pointer to a document that I= can use to find these? Off-topic: it sounds like we might need to start work on 7525bis... Peter --uwDOAXETWazvkzTXacLfdYdapW8huEFyf-- --NuKo0xXfEVPVs8NxhRQwahgAzEn0HW3RQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlrWDqAACgkQZWGMGH9o FKkfjhAA5MH1jh3xHiutIzQIyy9RPTCbBdLJSLNKcZ9EhPhyuL9cvSRzrthNWv6i QgVlKmpDF5DnNQ52HieifRuEFmzApB05pMlwflYvr2X7GtSnvINr0y6KaVbAd8GW 38tf9WOvOUvW3dL83EObi192ugZ8wONPd4l4+qIyT9eiBg7I0gtaYT+yErb44lf7 n1UsoPcNZoHwgLll0xlsDuNM2OCJYd51ofHKBrUwaHy6rLKTMmPX+MTj1YKJBpBz uGWSfGVXZHOMBMUbyqx2Ko0nrNtFlvjxZWWfR8G5uZsOuzMp3wOWfntIbd5HN9VI o53+y4vOL8TErZfpYzzKGKd62dfsYn3/4lR5k8frCRywhynWwhSJ4BKokA9nKJ6R XfVeiNDTRwNeqYIfo/Uvq7CK2xAWeYZYftyjSm/Ysv9G+6CJEVFvz33W0H7NqhTx GOymv4VKcxZ8ekj42K+uczKVIn+jusr6AikjUgftQHJWQjZwj1+on2YEp2dutEY+ Ac931DfqXM/Appxg0sfKScAoGWk++LFmHqUzTYOfrfwTaSBb3ytJNhwxfZ4yVh3+ bVkKCCng48IHxaK1/Syu1k9nYie1Zzfo8IsNfHnmTwBswI45uuw94uMXiVOa9rwW xE/myVUoKr8fhpTiACIxBSSZuBo8ini9395bh+NgBYKTCyvDV8o= =y/mV -----END PGP SIGNATURE----- --NuKo0xXfEVPVs8NxhRQwahgAzEn0HW3RQ-- From nobody Tue Apr 17 12:51:33 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F13E12D878 for ; Tue, 17 Apr 2018 12:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 p-X1GX_IyBCt for ; Tue, 17 Apr 2018 12:51:29 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp12.smtpout.orange.fr [80.12.242.134]) by ietfa.amsl.com (Postfix) with ESMTP id B3A24126D73 for ; Tue, 17 Apr 2018 12:51:28 -0700 (PDT) Received: from macbook-pro-de-julien-elie.home ([81.249.206.57]) by mwinf5d23 with ME id bXjv1x00T1Eq75t03XjwVE; Tue, 17 Apr 2018 21:43:57 +0200 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg== X-ME-Date: Tue, 17 Apr 2018 21:43:57 +0200 X-ME-IP: 81.249.206.57 To: Marc Petit-Huguenin Cc: art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: <3216f82e-ea12-6459-4ce2-42dc38b86e9f@trigofacile.com> Date: Tue, 17 Apr 2018 21:43:55 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [art] Artart telechat review of draft-ietf-tram-stunbis-16 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 19:51:31 -0000 Hi Marc, >>> So I kept the text there, followed by the following paragraph, >>> in addition of moving the original last paragraph in the Security >>> Consideration section: >>> >>> " These recommendations are just a part of the the recommendations in >>> [RFC7525] that implementations and deployments of a STUN usage using >>> TLS or DTLS SHOULD follow." >> >> I would instead suggest that we do something like Section 2 of RFC 7590 >> for XMPP: >> >> The best current practices documented in the "Recommendations for >> Secure Use of TLS and DTLS" [RFC7525] are included here by reference. >> Instead of repeating those recommendations here, this document mostly >> provides supplementary information regarding secure implementation >> and deployment of XMPP technologies. >> >> Here's the rationale: RFC 7525 is likely to be updated/replaced more >> quickly than STUNbis. If STUNbis recommends a particular cipher suite >> that 7525bis stops recommending, in the absence of STUNter will STUN >> implementations keep following STUNbis or will they upgrade to whatever >> 7525bis recommends? I suggest it will be the former, which is not what >> we want. > > All right, makes sense. I'll add something like this on my next > round of reviews, most likely this Friday. If you're going to add some wording about including TLS best current practices, maybe you could re-use what we came up with during final RFC edition of RFC 8143 : 3. Recommendations The best current practices documented in [BCP195] apply here. Therefore, NNTP implementations and deployments compliant with this document are REQUIRED to comply with [BCP195] as well. Instead of repeating those recommendations here, this document mostly provides supplementary information regarding secure implementation and deployment of NNTP technologies. Notably, the RFC Editor prefers referencing RFC 7525 as BCP 195 even though there currently is only one RFC in this BCP series. As other RFCs may be added in BCP 195, and we want to follow all best practices that apply, the reference should be the BCP series. -- Julien ÉLIE « – C'est joli cette avenue le long de la mer… Ça s'appelle comment ? – La promenade des Bretons. » (Astérix) From nobody Thu Apr 19 18:48:18 2018 Return-Path: X-Original-To: art@ietf.org Delivered-To: art@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 160FE12E8AD; Thu, 19 Apr 2018 18:48:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Matthew Miller To: Cc: draft-ietf-tokbind-protocol.all@ietf.org, unbearable@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152418888406.10829.5856838219601060605@ietfa.amsl.com> Date: Thu, 19 Apr 2018 18:48:04 -0700 Archived-At: Subject: [art] Artart telechat review of draft-ietf-tokbind-protocol-17 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 01:48:04 -0000 Reviewer: Matthew Miller Review result: Ready This document is well-written and clearly defines the format, creation, and validation of a TokenBindingMessage. Major Issues: NONE Minor Issues: NONE Nits: NONE From nobody Sat Apr 21 14:02:59 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC7B12DA12; Sat, 21 Apr 2018 14:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 odj9VI5Hz6Zg; Sat, 21 Apr 2018 14:02:54 -0700 (PDT) Received: from implementers.org (unknown [92.243.22.217]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 328811242F5; Sat, 21 Apr 2018 14:02:54 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:3134:3153:e7ee:f8f7] (unknown [IPv6:2601:648:8301:730f:3134:3153:e7ee:f8f7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id A6853AE844; Sat, 21 Apr 2018 23:02:50 +0200 (CEST) To: =?UTF-8?Q?Julien_=c3=89LIE?= Cc: art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> <3216f82e-ea12-6459-4ce2-42dc38b86e9f@trigofacile.com> From: Marc Petit-Huguenin Message-ID: Date: Sat, 21 Apr 2018 14:02:48 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <3216f82e-ea12-6459-4ce2-42dc38b86e9f@trigofacile.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uveg8IQlS7aDvv6qn8mVKtqgZcmr5zzAw" Archived-At: Subject: Re: [art] [tram] Artart telechat review of draft-ietf-tram-stunbis-16 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 21:02:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uveg8IQlS7aDvv6qn8mVKtqgZcmr5zzAw Content-Type: multipart/mixed; boundary="w0ECpTSTKe1lsKmqib92dfauL32s86Ucz"; protected-headers="v1" From: Marc Petit-Huguenin To: =?UTF-8?Q?Julien_=c3=89LIE?= Cc: art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org Message-ID: Subject: Re: [tram] [art] Artart telechat review of draft-ietf-tram-stunbis-16 References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> <3216f82e-ea12-6459-4ce2-42dc38b86e9f@trigofacile.com> In-Reply-To: <3216f82e-ea12-6459-4ce2-42dc38b86e9f@trigofacile.com> --w0ECpTSTKe1lsKmqib92dfauL32s86Ucz Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/17/2018 12:43 PM, Julien =C3=89LIE wrote: > Hi Marc, >>>> So I kept the text there, followed by the following paragraph, >>>> in addition of moving the original last paragraph in the Security >>>> Consideration section: >>>> >>>> " These recommendations are just a part of the the recommendations i= n >>>> =C2=A0=C2=A0 [RFC7525] that implementations and deployments of a STU= N usage using >>>> =C2=A0=C2=A0 TLS or DTLS SHOULD follow." >>> >>> I would instead suggest that we do something like Section 2 of RFC 75= 90 >>> for XMPP: >>> >>> =C2=A0=C2=A0=C2=A0 The best current practices documented in the "Reco= mmendations for >>> =C2=A0=C2=A0=C2=A0 Secure Use of TLS and DTLS" [RFC7525] are included= here by reference. >>> =C2=A0=C2=A0=C2=A0 Instead of repeating those recommendations here, t= his document mostly >>> =C2=A0=C2=A0=C2=A0 provides supplementary information regarding secur= e implementation >>> =C2=A0=C2=A0=C2=A0 and deployment of XMPP technologies. >>> >>> Here's the rationale: RFC 7525 is likely to be updated/replaced more >>> quickly than STUNbis. If STUNbis recommends a particular cipher suite= >>> that 7525bis stops recommending, in the absence of STUNter will STUN >>> implementations keep following STUNbis or will they upgrade to whatev= er >>> 7525bis recommends? I suggest it will be the former, which is not wha= t >>> we want. >> >> All right, makes sense.=C2=A0 I'll add something like this on my next >> round of reviews, most likely this Friday. >=20 > If you're going to add some wording about including TLS best current pr= actices, maybe you could re-use what we came up with during final RFC edi= tion of RFC 8143 : >=20 > 3.=C2=A0 Recommendations >=20 > =C2=A0=C2=A0 The best current practices documented in [BCP195] apply he= re. > =C2=A0=C2=A0 Therefore, NNTP implementations and deployments compliant = with this > =C2=A0=C2=A0 document are REQUIRED to comply with [BCP195] as well. >=20 > =C2=A0=C2=A0 Instead of repeating those recommendations here, this docu= ment mostly > =C2=A0=C2=A0 provides supplementary information regarding secure implem= entation > =C2=A0=C2=A0 and deployment of NNTP technologies. >=20 >=20 > Notably, the RFC Editor prefers referencing RFC 7525 as BCP 195 even th= ough there currently is only one RFC in this BCP series.=C2=A0 As other R= FCs may be added in BCP 195, and we want to follow all best practices tha= t apply, the reference should be the BCP series. >=20 Thanks, I used the BCP as reference, and changed the SHOULD to MUST. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --w0ECpTSTKe1lsKmqib92dfauL32s86Ucz-- --uveg8IQlS7aDvv6qn8mVKtqgZcmr5zzAw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlrbpvgACgkQKcRFldZq fsRZtg//b9+86VTI0FqR9k1Kr6YqCmOjJTEqF7Y5RKA/fz+yA4wbeYDMaNYQKrxT 0jGjnLuGQ+SP+34B08pP0gNEroVRMLL3QrZF9k6W2qJNJNrnVIh1UZU7Vlqibmah g0d/SagWu6JrNQ/+jBzZLryEbX8PqZYmzM+F9Nmfi//YCk8nqWzNh0YRtRxTjnTz sdaAkKhyh6GIH0aOt5tQhKRwhcJ4gDQCTy1RO7P6f/kxDkr6BNO74C96lwAmfAst Tsg0wRwuhNRkPYCctDo1CAGZKvprGtCPJHwumIr58dtRUNO304BfrixRMBibZS6B 4F+xJchnTmLIAeOJUyDAfEl9FN5aRDqDYdtvLGW85B/IoFC/lvfy0kfVdUO5Efnq Ar/uENsyWLAqxI6tELv8SNYWtOF9DT5ZZZr3SJXGSjuqcYSZaX15fxDoZBui43u7 w5XZYNMPiL9DhSL1r8dS8Q2mNNFCppkoxxu+nk2UbcKLCud1QPdqGNOqekavxrZ3 WGambG9pbPGsI291zjC3Cf6X1dWWLofNUOXYveV71tY/iWxVdp6ZCs8cVUIiwn6c vphyd+Dj3bvhReRBd0onJR9LmNvolXKIoXXpBb91y6N0++2bLmeUHO1ZVG5FQ2i+ bViA7GrBupXUK1mSbL21QC3NHp3cqsA4ic15SbcMPtbngSLnHac= =E0jr -----END PGP SIGNATURE----- --uveg8IQlS7aDvv6qn8mVKtqgZcmr5zzAw-- From nobody Sat Apr 21 14:07:20 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C2212DA1C; Sat, 21 Apr 2018 14:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 MMuNw2MU9W9V; Sat, 21 Apr 2018 14:07:17 -0700 (PDT) Received: from implementers.org (unknown [92.243.22.217]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2D9612D870; Sat, 21 Apr 2018 14:07:16 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:3134:3153:e7ee:f8f7] (unknown [IPv6:2601:648:8301:730f:3134:3153:e7ee:f8f7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 66A64AE844; Sat, 21 Apr 2018 23:07:14 +0200 (CEST) To: Eric Rescorla , Peter Saint-Andre Cc: art@ietf.org, Marc Petit-Huguenin , draft-ietf-tram-stunbis.all@ietf.org, IETF discussion list , tram@ietf.org References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> From: Marc Petit-Huguenin Message-ID: <5ec17f83-a2b0-8d5d-b17a-ac0977ede7b0@acm.org> Date: Sat, 21 Apr 2018 14:07:12 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="98hmvLnbeK34OLsFLLivKe9GO8PVcJ9qD" Archived-At: Subject: Re: [art] [tram] Artart telechat review of draft-ietf-tram-stunbis-16 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 21:07:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --98hmvLnbeK34OLsFLLivKe9GO8PVcJ9qD Content-Type: multipart/mixed; boundary="7pBOOTQ0uqj41z8a1dMR9nVGu0qASzo4X"; protected-headers="v1" From: Marc Petit-Huguenin To: Eric Rescorla , Peter Saint-Andre Cc: art@ietf.org, Marc Petit-Huguenin , draft-ietf-tram-stunbis.all@ietf.org, IETF discussion list , tram@ietf.org Message-ID: <5ec17f83-a2b0-8d5d-b17a-ac0977ede7b0@acm.org> Subject: Re: [tram] Artart telechat review of draft-ietf-tram-stunbis-16 References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> In-Reply-To: --7pBOOTQ0uqj41z8a1dMR9nVGu0qASzo4X Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/16/2018 08:12 PM, Eric Rescorla wrote: > On Mon, Apr 16, 2018 at 5:22 PM, Peter Saint-Andre > wrote: >=20 >> Hi Marc, a few further comments inline. >> >> On 4/16/18 5:43 PM, Marc Petit-Huguenin wrote: >>> Hi Peter, >>> >>> Thanks for the review and sorry for the delay in responding, I was >> traveling for the last 4 weeks. >>> >>> See my responses inline. >>> >>> On 04/02/2018 03:59 PM, Peter Saint-Andre wrote: >>>> Reviewer: Peter Saint-Andre >>>> Review result: Ready with Nits >>>> >> >> >> >>>> The first paragaraph of Section 6.2.3 restates recommendations from = RFC >>>> 7525; why not simply reference that specification? >>> >>> The original text in RFC5389 said this: >>> >>> " When STUN is run by itself over TLS-over-TCP, the >>> TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented at a >>> minimum. [...]" >>> >>> The new text is an attempt at updating it in the same spirit of givin= g >> minimal instructions and complementing them with a reference to RFC 75= 25 - >> which was the reason for the reference to RFC 7525 there. >>> >>> So I kept the text there, followed by the following paragraph, in >> addition of moving the original last paragraph in the Security >> Consideration section: >>> >>> " These recommendations are just a part of the the recommendations in= >>> [RFC7525] that implementations and deployments of a STUN usage usin= g >>> TLS or DTLS SHOULD follow." >> >> I would instead suggest that we do something like Section 2 of RFC 759= 0 >> for XMPP: >> >> The best current practices documented in the "Recommendations for >> Secure Use of TLS and DTLS" [RFC7525] are included here by referenc= e. >> Instead of repeating those recommendations here, this document most= ly >> provides supplementary information regarding secure implementation >> and deployment of XMPP technologies. >> >> Here's the rationale: RFC 7525 is likely to be updated/replaced more >> quickly than STUNbis. If STUNbis recommends a particular cipher suite >> that 7525bis stops recommending, in the absence of STUNter will STUN >> implementations keep following STUNbis or will they upgrade to whateve= r >> 7525bis recommends? I suggest it will be the former, which is not what= >> we want. >> >=20 > I forgot about this in my review, but you should also profile ciphers f= or > TLS 1.3. >=20 As suggested by Julien =C3=89lie, I now use BCP195 as reference. Would t= hat, and a future update of that BCP covering TLS 1.3 satisfy your commen= t? Thanks. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --7pBOOTQ0uqj41z8a1dMR9nVGu0qASzo4X-- --98hmvLnbeK34OLsFLLivKe9GO8PVcJ9qD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlrbqAAACgkQKcRFldZq fsQ7ag/+PyCWVhHKj3h52iU2O79oyq95JdM0x2wGzZwnPeQRq1qdC5cBjLkUuxFr 66eDmK/IB63stz/AIVDaCjhx7CcGNVr9EW8btbEWHK3NesImERc62pV5tVF6lqja iWp5X219uGtslvEA6WXjn0zMGQFHu5cEcRzPQ/YTO5wdQKgsrO/wTn1WPkvhrfRk yBkUMfQ1duyISpm3yRO8WsAR6jU9dNxSUD9GaaN3GrFpRmiViipOp4Qh8g/9YqNX IXghOogy9Ym29zgvlnQMCzR1S5Ioh2iqfY1CSfR5KSIadWB/wjiqiTDywFg5yDL2 XIQUYSkALCqjuj5RtzLDPH5Fh34ucoJCSAafJoDZ1r8jSubWcC7emk/XZcYDOoal 0CAUGrvEoTltYnCW8Z0gLxQ0jSO/oIhFJ38RWB03Rz8SiQtM+nmuyZT0GORjoY2C ehAKuhxI3bUdM3TiTS8eZmATWTxB0mfDEBDVQc+1menKzhbuubBD6G8hMNgn3vQG te92Ab+9Rw4mWfbNtm6go05VvT8HeQDmJ00LjxDt7uv/QNgFRmH1LcmoSka8UNOe 52AiVy56rXnpV7OmwdNVNluKzcoidZRaT9xBuj+hstUqJZAexqMb53Sk8SfzvX/Q J5vaxF+MamqcquPB+nDFRoXI13dmJ4PAekTWwOP6Uf5pfqpobGE= =w+2b -----END PGP SIGNATURE----- --98hmvLnbeK34OLsFLLivKe9GO8PVcJ9qD-- From nobody Sat Apr 21 14:39:37 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3365F12E8D7; Sat, 21 Apr 2018 14:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 m2_VXDnAAaUQ; Sat, 21 Apr 2018 14:39:33 -0700 (PDT) Received: from implementers.org (unknown [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DD8012E8D4; Sat, 21 Apr 2018 14:39:33 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:3134:3153:e7ee:f8f7] (unknown [IPv6:2601:648:8301:730f:3134:3153:e7ee:f8f7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id CE8D3AE844; Sat, 21 Apr 2018 23:39:29 +0200 (CEST) From: Marc Petit-Huguenin To: Peter Saint-Andre , art@ietf.org Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> Message-ID: <00ddbc05-2a96-d77e-f260-7d0b3c0f4074@petit-huguenin.org> Date: Sat, 21 Apr 2018 14:39:28 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="s98ikjH5z0Zsqqs2k3YOVMmKQGsTBjEp5" Archived-At: Subject: Re: [art] Artart telechat review of draft-ietf-tram-stunbis-16 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 21:39:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --s98ikjH5z0Zsqqs2k3YOVMmKQGsTBjEp5 Content-Type: multipart/mixed; boundary="7ye6ecdV7BXtpLLNFuPOQAvHLJEquLJsZ"; protected-headers="v1" From: Marc Petit-Huguenin To: Peter Saint-Andre , art@ietf.org Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org Message-ID: <00ddbc05-2a96-d77e-f260-7d0b3c0f4074@petit-huguenin.org> Subject: Re: Artart telechat review of draft-ietf-tram-stunbis-16 References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> In-Reply-To: <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> --7ye6ecdV7BXtpLLNFuPOQAvHLJEquLJsZ Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/17/2018 03:00 AM, Marc Petit-Huguenin wrote: > On 04/16/2018 05:22 PM, Peter Saint-Andre wrote: >> Hi Marc, a few further comments inline. >> >> On 4/16/18 5:43 PM, Marc Petit-Huguenin wrote: >>> Hi Peter, >>> >>> Thanks for the review and sorry for the delay in responding, I was tr= aveling for the last 4 weeks. >>> >>> See my responses inline. >>> >>> On 04/02/2018 03:59 PM, Peter Saint-Andre wrote: >>>> Reviewer: Peter Saint-Andre >>>> Review result: Ready with Nits >>>> >> >> >> >>>> The first paragaraph of Section 6.2.3 restates recommendations from = RFC >>>> 7525; why not simply reference that specification? >>> >>> The original text in RFC5389 said this: >>> >>> " When STUN is run by itself over TLS-over-TCP, the >>> TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented at a >>> minimum. [...]" >>> >>> The new text is an attempt at updating it in the same spirit of givin= g minimal instructions and complementing them with a reference to RFC 752= 5 - which was the reason for the reference to RFC 7525 there. >>> >>> So I kept the text there, followed by the following paragraph, in add= ition of moving the original last paragraph in the Security Consideration= section: >>> >>> " These recommendations are just a part of the the recommendations in= >>> [RFC7525] that implementations and deployments of a STUN usage usin= g >>> TLS or DTLS SHOULD follow." >> >> I would instead suggest that we do something like Section 2 of RFC 759= 0 >> for XMPP: >> >> The best current practices documented in the "Recommendations for >> Secure Use of TLS and DTLS" [RFC7525] are included here by referenc= e. >> Instead of repeating those recommendations here, this document most= ly >> provides supplementary information regarding secure implementation >> and deployment of XMPP technologies. >> >> Here's the rationale: RFC 7525 is likely to be updated/replaced more >> quickly than STUNbis. If STUNbis recommends a particular cipher suite >> that 7525bis stops recommending, in the absence of STUNter will STUN >> implementations keep following STUNbis or will they upgrade to whateve= r >> 7525bis recommends? I suggest it will be the former, which is not what= >> we want. >=20 > All right, makes sense. I'll add something like this on my next round = of reviews, most likely this Friday. Done, see my other emails to Julien =C3=89lie and Ekr. >=20 >> >>>> Section 6.3.4 states: >>>> >>>> o If the error code is 500 through 599, the client MAY resend th= e >>>> request; clients that do so MUST limit the number of times the= y do >>>> this. >>>> >>>> It is reasonable to provide guidance as to the number of re-sends? >>> >>> Same issue here, that's a section that is unmodified from RFC 5389.=20 >> >> I understand. Now is our chance to fix it. :-) >> >>> As long as the client does not enter an endless loop of retransmissi= on, choosing different numbers of re-sends does not affect interoperabili= ty. >> >> Choosing different numbers is OK, but choosing an infinite number is >> not. Can we provide guidance as to how many is too many? 10? 50? 100? >=20 > Well, the text already states that an infinite number of of re-sends is= not compliant. Anyway, I am not sure how to determine a reasonable numb= er, but I'll try. I chose 4 as the maximum number of retransmissions. I based that on erro= r code 508 in TURN that defines a delay of 60 seconds between retransmiss= ions, so we now get a delay of 5 minutes before the client gives up in ca= se of insufficient capacity. The new text reads like this: "o If the error code is 500 through 599, the client MAY resend the request; clients that do so MUST limit the number of times they do this. Unless a specific error code specifies a different value, the number of retransmissions MUST be limited to 4." --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --7ye6ecdV7BXtpLLNFuPOQAvHLJEquLJsZ-- --s98ikjH5z0Zsqqs2k3YOVMmKQGsTBjEp5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlrbr5AACgkQKcRFldZq fsRZGQ//d56hu0y7/tsLRJVANY6EEsyW3ZtI8+fpl6+ZAlg4GazKq6Lq1aLRc8FF 1JdJ/47IAEvByVVTQd2pb1NYf9hSE8QvInD9m9QeTpDbRKLpafdVuKpNOYtYnx8N fj+A0RGtwbzbm0RkUNAXBROT/aA/zcWEffT/zO010+chXXPoTqUJ3TEPczUk1BJ6 +p3m+S/kdg3u6xqtRPRsBwLK6i98ZwxfA4A/Yu2JZKjhfrEjlrw4xIJD0US7tvSb itpLEecbdQcyUz84mmTEsDOAwDEMECgaq3GEntsfxylCk211GsilC0GrKpBPIxi3 UpbIoPqKmb9Nf7lQVwsHnjUkOYB+/+SIj6mZJoXWu0AaIcGpvv9+EZweNiS6RJ3R BxBIg/BBoX4q61rUQUNuW0MrY/Jj0pV+n2iQBRgLO46LWUMTi8c0vQlSF/iFgV/8 HgLygsPP/u6Ce+wLMLvtvz/ZUPx3nFhtMwoGiqI05/GHG4UETx1H9GuurSXwCKRF GORQvb5UCx88OsOBq7+fb+YyE4qc5JkVu+rLxyPnIYYxnfZs6i59azvRAliHu7SZ tseRCH2bVBcuRdS0HoaUoGS+3mOgbqenO2pO31GojGMDvckjIC5zY5NE2bSH1TZc sr2eF6NCIzh3vX5qYh/fH4oD6xBnbS2tRs2/SuoGNs+/YooOBio= =cqIx -----END PGP SIGNATURE----- --s98ikjH5z0Zsqqs2k3YOVMmKQGsTBjEp5-- From nobody Sun Apr 22 20:30:58 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5D31275F4 for ; Sun, 22 Apr 2018 20:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 foXjFojJdb3e for ; Sun, 22 Apr 2018 20:30:41 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 9108D126DCA for ; Sun, 22 Apr 2018 20:30:37 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id 19-v6so8974111itw.3 for ; Sun, 22 Apr 2018 20:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=MKZzNFz0qNWfyNolYcI4P5s0xqV+tsMh23zcuitAH1M=; b=H687+YsXsYNnz8f3A0SU4011ewMfQ44BklgW9ATSILuHy5vChEJIKHpiizTBIrFiY4 dNwprLlh0gNBY6/wg44rnJ4DfvA8A1E6YbWKg+5HVbnMSOgEu2EQ1l5MDvF+9yHMFnsp WU/YGpJ3hE1Ax7Vg46jA4ozNJE61y09lwwbBM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MKZzNFz0qNWfyNolYcI4P5s0xqV+tsMh23zcuitAH1M=; b=dWk9qvd0DS2FAlaiQ73WVXcPmTIkxNydOWsrtMZXsWpAKWd93HgTpi2StnLNJFBi3X QfWmH/QX6GMgLeKiF1hwyoLP7MMdKJbD3I2EHx7qj4W1L7ygOLaBbelCuaZ+N45oKNJE d2QHUnrrc7v15Y6E8AJqgFk1zjgC2PAWxU2zrLxGixkhL8sN/TpeSth96vXQKp2K2Ip9 3CuoyB76xdvx86pkXoNf66jPw8x/mdCdhJItB4zE0LiO+nXK1IK+zh03qKGeyZd2qQEg Bd3UB5/Lppwdde0lmNpx5dBLY5tpXfUQEXYPKKcgSOJ6EI46t/E+qGQY6afsdMfR3Msl 3okQ== X-Gm-Message-State: ALQs6tChhw4J3ITcVI2KQuiL4k1tp0nRKLU8beDzvdwTGdmAO4ESL9E1 sik05YIDvc5d1H2ohz5dox89TA== X-Google-Smtp-Source: AIpwx48Ta84BuBAdUttmgt0oIkH1LpMrAGHMebsvz2cbscRNS+koHIZASA+mISZbWaqnNeTNAQg4zQ== X-Received: by 2002:a24:730e:: with SMTP id y14-v6mr13111024itb.45.1524454236939; Sun, 22 Apr 2018 20:30:36 -0700 (PDT) Received: from aither.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id k141-v6sm3556604ite.41.2018.04.22.20.30.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Apr 2018 20:30:36 -0700 (PDT) To: Marc Petit-Huguenin , art@ietf.org Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> <00ddbc05-2a96-d77e-f260-7d0b3c0f4074@petit-huguenin.org> From: Peter Saint-Andre Message-ID: <5f036c89-07b1-8d9d-cd18-8d9381ef8adf@mozilla.com> Date: Sun, 22 Apr 2018 21:30:34 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <00ddbc05-2a96-d77e-f260-7d0b3c0f4074@petit-huguenin.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [art] Artart telechat review of draft-ietf-tram-stunbis-16 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 03:30:45 -0000 On 4/21/18 3:39 PM, Marc Petit-Huguenin wrote: >>>>> Section 6.3.4 states: >>>>> >>>>> o If the error code is 500 through 599, the client MAY resend the >>>>> request; clients that do so MUST limit the number of times they do >>>>> this. >>>>> >>>>> It is reasonable to provide guidance as to the number of re-sends? >>>> >>>> Same issue here, that's a section that is unmodified from RFC 5389. >>> >>> I understand. Now is our chance to fix it. :-) >>> >>>> As long as the client does not enter an endless loop of retransmission, choosing different numbers of re-sends does not affect interoperability. >>> >>> Choosing different numbers is OK, but choosing an infinite number is >>> not. Can we provide guidance as to how many is too many? 10? 50? 100? >> >> Well, the text already states that an infinite number of of re-sends is not compliant. Anyway, I am not sure how to determine a reasonable number, but I'll try. > > I chose 4 as the maximum number of retransmissions. I based that on error code 508 in TURN that defines a delay of 60 seconds between retransmissions, so we now get a delay of 5 minutes before the client gives up in case of insufficient capacity. The new text reads like this: > > "o If the error code is 500 through 599, the client MAY resend the > request; clients that do so MUST limit the number of times they do > this. Unless a specific error code specifies a different value, > the number of retransmissions MUST be limited to 4." > "SHOULD be limited to 4" seems fine, but MUST is OK too. Thanks for looking into this and making the fix. Peter From nobody Mon Apr 23 10:46:10 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D888512D88A; Mon, 23 Apr 2018 10:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] autolearn=no 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 HPBso3AI8B1S; Mon, 23 Apr 2018 10:46:07 -0700 (PDT) Received: from implementers.org (unknown [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C885312D889; Mon, 23 Apr 2018 10:46:06 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:fdb6:1cc8:478a:5b55] (unknown [IPv6:2601:648:8301:730f:fdb6:1cc8:478a:5b55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 747AAAE844; Mon, 23 Apr 2018 19:46:04 +0200 (CEST) To: Peter Saint-Andre , art@ietf.org Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> <00ddbc05-2a96-d77e-f260-7d0b3c0f4074@petit-huguenin.org> <5f036c89-07b1-8d9d-cd18-8d9381ef8adf@mozilla.com> From: Marc Petit-Huguenin Message-ID: Date: Mon, 23 Apr 2018 10:46:02 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <5f036c89-07b1-8d9d-cd18-8d9381ef8adf@mozilla.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HbSK1bmpKHBO7Al1fHJB33Ot8fFkTISvn" Archived-At: Subject: Re: [art] [tram] Artart telechat review of draft-ietf-tram-stunbis-16 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 17:46:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HbSK1bmpKHBO7Al1fHJB33Ot8fFkTISvn Content-Type: multipart/mixed; boundary="y7NgICYfHnsZAft52uUF0RpGrT5GMGr2M"; protected-headers="v1" From: Marc Petit-Huguenin To: Peter Saint-Andre , art@ietf.org Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org Message-ID: Subject: Re: [tram] Artart telechat review of draft-ietf-tram-stunbis-16 References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> <00ddbc05-2a96-d77e-f260-7d0b3c0f4074@petit-huguenin.org> <5f036c89-07b1-8d9d-cd18-8d9381ef8adf@mozilla.com> In-Reply-To: <5f036c89-07b1-8d9d-cd18-8d9381ef8adf@mozilla.com> --y7NgICYfHnsZAft52uUF0RpGrT5GMGr2M Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/22/2018 08:30 PM, Peter Saint-Andre wrote: > On 4/21/18 3:39 PM, Marc Petit-Huguenin wrote: >=20 >>>>>> Section 6.3.4 states: >>>>>> >>>>>> o If the error code is 500 through 599, the client MAY resend = the >>>>>> request; clients that do so MUST limit the number of times t= hey do >>>>>> this. >>>>>> >>>>>> It is reasonable to provide guidance as to the number of re-sends?= >>>>> >>>>> Same issue here, that's a section that is unmodified from RFC 5389.= =20 >>>> >>>> I understand. Now is our chance to fix it. :-) >>>> >>>>> As long as the client does not enter an endless loop of retransmis= sion, choosing different numbers of re-sends does not affect interoperabi= lity. >>>> >>>> Choosing different numbers is OK, but choosing an infinite number is= >>>> not. Can we provide guidance as to how many is too many? 10? 50? 100= ? >>> >>> Well, the text already states that an infinite number of of re-sends = is not compliant. Anyway, I am not sure how to determine a reasonable nu= mber, but I'll try. >> >> I chose 4 as the maximum number of retransmissions. I based that on e= rror code 508 in TURN that defines a delay of 60 seconds between retransm= issions, so we now get a delay of 5 minutes before the client gives up in= case of insufficient capacity. The new text reads like this: >> >> "o If the error code is 500 through 599, the client MAY resend the >> request; clients that do so MUST limit the number of times they do= >> this. Unless a specific error code specifies a different value, >> the number of retransmissions MUST be limited to 4." >> >=20 > "SHOULD be limited to 4" seems fine, but MUST is OK too. >=20 Changed to SHOULD. Thanks. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --y7NgICYfHnsZAft52uUF0RpGrT5GMGr2M-- --HbSK1bmpKHBO7Al1fHJB33Ot8fFkTISvn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlreG9oACgkQKcRFldZq fsSzgw/9FPTE64+ikRn7y1J24OVVsWIX4BaF1jB4c5wsFxAFTklcN0XkSpDaLvRk uHBdFXpj4Ce+LnmIPKl95s8udekCBkewQkkJE0uuMgCBJHeIjKZq+V81dfgUUcBc pCS2U8GAuP7+NRmfejLxPVLiGexS+mU7azzhwcDaYVFShZmmJcc5fl+wMEk5PKCw NeuP2i2O7p32oCW/Yis95qwtIYikplZ9acbUMRNlnpjHDNCn8/EJAqehiY8mUQsK kf8ldpymzZ59rEpAhdmapHdB/l3NsYDIQzrWCvM6uZjsXiad0IHMimgI2c/ZgCUD LwmTtbK6Kn3PSHWvoSG06oVo1QP8gC+dRbCVC36pZwQjPzgZjeMJYjp3eHA+CEJK iiFNV2RwBNmAVAdELw4qJzC+i2f30SX/JUWkFqCSBAdTWilY72lDI6HLSeo3jyaD XXDFkpXZT1qVL+jnOuKNvCN7S8pqjAghDnE4RulL5zA3h6qofARIizWJkvNsu+Ul m+L53HbWHNXBma4c0enK0b6lKo/c5lYNcwq+ZLpj3NG2WryPB3mS6idsbT39YZ+J diPqO4mw2D6DNjPEA4n1Kv41ImGDZCXCfm7rS6DBXaSDyDf+Z1+dZ/4x4qfEHu9k BiwZE1qrPtWz5TTifqpMctOO1i79ndDqryoAGPef4iaqrHA2/sY= =jhrk -----END PGP SIGNATURE----- --HbSK1bmpKHBO7Al1fHJB33Ot8fFkTISvn--