From nobody Fri Sep 8 07:13:38 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95BFC13291C for ; Fri, 8 Sep 2017 07:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=samwhited.com header.b=pL76tS17; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JrZvVjOH 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 GGxQTfTSvO5r for ; Fri, 8 Sep 2017 07:13:36 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D2C8132925 for ; Fri, 8 Sep 2017 07:13:36 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 93E7520A9E; Fri, 8 Sep 2017 10:13:35 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute4.internal (MEProxy); Fri, 08 Sep 2017 10:13:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; h=cc:content-transfer-encoding:content-type:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=OogtsBAXZ4BViEvzr yQOE+JXVN1u63vU2qao0469AcY=; b=pL76tS17o6H6kzayH8kwvRdxMhUWL/SBT LWAvJqedG52SQem9g69r+d0cwLLjjM2TbznTxxwA0j/rXbl0AhgMS7rjc05iWbbY WrBOfY6YoXQYoHURi/i/711sDb0qsYMOZfP7XzKuOhFIz051RvzaDlcYSCW9fhxf m2VGoIO2pDUYiPKBeNW2y7vjGmdeKpJ/MIrN70U4CDMmLcU59T2D+r6Zmzl/re4q 63pwq9B+9Bz23y6WDmz9ZylU2ouO8zRQYxGM8233Q2U0qruz7x6ztDTrB7YjiY3y diVxOQofj28iQRIHZNqsBKRY9hjKPypRYZYqkAFCaN5Rk2/x3V80g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=OogtsB AXZ4BViEvzryQOE+JXVN1u63vU2qao0469AcY=; b=JrZvVjOHYVxHOQzBHbpN96 npBWr66h74ojuvoUf2DomtPh8L9siFI8I+GpWpre+6uN046arbswxWSiiY8ywV7z ZOY5Su9c8Nsf1I2pCchdHsSS3zDyajiCloSieI+CXrP3znHwvQnHukjYeEjmzGc+ 9zH3BHO+B+QbHGBlnpha6GRcLbwmtpBMXt/ZUYyN/u4SEd/BOg4KjA4sPxtpgZW+ b4pb6QEu4iYO5qU9pEZAogOXExSmV6V2XIhPMI6pvklbyyay61xYAkcmCvCLk/0l Faw15blFyhTiiDGikSxphAgN5GNKVelU8mnx3qTUcmUwZsAr6XLJocD6BtGpNsGw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 707C19E2DF; Fri, 8 Sep 2017 10:13:35 -0400 (EDT) Message-Id: <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> From: Sam Whited To: "Peter Saint-Andre" Cc: precis@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-973d3087 References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> In-Reply-To: Date: Fri, 08 Sep 2017 09:13:35 -0500 Archived-At: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 14:13:37 -0000 On Wed, Jul 19, 2017, at 23:44, Sam Whited wrote: > On Wed, Jul 19, 2017 at 8:40 PM, Peter Saint-Andre > wrote: > > What do implementers think is a "reasonable number of iterations"? My > > sense is that we're talking about at most 4 or 5, and usually 2 or 3. Apologies for the long delay, I know this thread is rather old now, but I was just reminded of this blog post [1] from Spotify that shows that the non-idempotency of the nickname profile is already a security issue in the wild and that documenting the fact that it may have security implications only goes so far. =E2=80=94Sam [1]: https://labs.spotify.com/2013/06/18/creative-usernames/ From nobody Wed Sep 13 20:39:06 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2141133085 for ; Wed, 13 Sep 2017 20:39:04 -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 (2048-bit key) header.d=stpeter.im header.b=hMPJFG1K; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XvlTZQ0f 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 9oaZJrbg5pLz for ; Wed, 13 Sep 2017 20:39:02 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A391330A5 for ; Wed, 13 Sep 2017 20:38:59 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 9A6E920B4E; Wed, 13 Sep 2017 23:38:58 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 13 Sep 2017 23:38:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=LSnFQlq3ngvQftRGx/mkCkuR85pLZ3a6srlchKxb4 9s=; b=hMPJFG1Kazx1v6052CpydyX4669zKrqI2dS3d/LrEX/Q7L/99rAcCK1YR pJL0jHCPU2EbabUzcwGkFXfg97hKenN85/fHtGpi5aDIMuVsy3LiUco7lsDLcxKb oUGSHtmSndTmjk/u17E9Y5lEpJsQtavAkXcNFYfVo88+AaSFCEC/JYxoJSb99LER gW0mGKLyj8hGjoDmO+28c4LZyJIYBgchTsLuvMWefR5TbhD4/0BhgWVq/FUNxjry kc/lSml4F9aXCUw1dr1D195pR38+aXezNwQUpCubUspB1ZCXeudJlne3mbqRnGV/ FVxrY8yCRUAYtzrdD9sjdAdZUJo8A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=LSnFQlq3ngvQftRGx/ mkCkuR85pLZ3a6srlchKxb49s=; b=XvlTZQ0f+/JV6a5oO4LYTZ70qJ72VwucBN hFjZnZOeOjNm9DViq50F2cvuCtA3/Di0w2LgkHwMDhkg+2z776coAGnddLKxDuyh i8JumWRYwfyYMzyeJnjIpzGO/Det+07ySzcsGjistCCAd58ui7l+8AIBoqzWGUnb if6XhWDE/vxRowFi+na7Pv9YlxWdirJjLPkqJOmCYGIBvW9dVXaHejXpqXXfC6yB ita0OgyiLtZicAMZRA6Acdv+UnxwmOGq7PO8SQN11gJpLRTvEIgBeMuHnG8DGcVg h0A+mGaPoIeAAOM+ckWxWMJjBle3WhrHL5ZkMas2dscDmap3MoNw== X-ME-Sender: X-Sasl-enc: DuPLvWGGE0lvJbTPskkG+/4dQwFmsr15JF9i6d/IG9F8 1505360338 Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id 2125A7E22F; Wed, 13 Sep 2017 23:38:58 -0400 (EDT) To: Sam Whited References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> Cc: "precis@ietf.org" From: Peter Saint-Andre Message-ID: Date: Wed, 13 Sep 2017 21:38:56 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="E5Aclq1ljX0U09k96uMQLUTgREL1PMq2p" Archived-At: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 03:39:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --E5Aclq1ljX0U09k96uMQLUTgREL1PMq2p Content-Type: multipart/mixed; boundary="EG5R4Wxm5iWaQaX7lRFkSpDwKMPmcUQJa"; protected-headers="v1" From: Peter Saint-Andre To: Sam Whited Cc: "precis@ietf.org" Message-ID: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> In-Reply-To: <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> --EG5R4Wxm5iWaQaX7lRFkSpDwKMPmcUQJa Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 9/8/17 8:13 AM, Sam Whited wrote: > On Wed, Jul 19, 2017, at 23:44, Sam Whited wrote: >> On Wed, Jul 19, 2017 at 8:40 PM, Peter Saint-Andre >> wrote: >>> What do implementers think is a "reasonable number of iterations"? My= >>> sense is that we're talking about at most 4 or 5, and usually 2 or 3.= >=20 > Apologies for the long delay, I know this thread is rather old now, but= > I was just reminded of this blog post [1] from Spotify that shows that > the non-idempotency of the nickname profile is already a security issue= > in the wild and that documenting the fact that it may have security > implications only goes so far. >=20 > =E2=80=94Sam >=20 > [1]: https://labs.spotify.com/2013/06/18/creative-usernames/ >=20 The Spotify folks faced numerous issues, including the fact that they implemented against an unfinished spec. I'd say that if they now used the PRECIS specs (especially the new ones about to be published) as their guideline, things would have gone much better. Peter --EG5R4Wxm5iWaQaX7lRFkSpDwKMPmcUQJa-- --E5Aclq1ljX0U09k96uMQLUTgREL1PMq2p Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJZufnRAAoJEOoGpJErxa2pczQP/0gQ8flFZJedOBx4IMob5/MJ uiy648EHRGEuIc3PemlnO02QiWbjpG8NVT3AUr9JKVYwEPkUGHFPaz/ljoQ4QwLn hSGHFmZAQmWwtc6tfOiaaTfuPMln4RwNG123OdqdZOzsUt3WMNfI5exowiyqqGdY gkC+6abS4EldRw7AoUgppr8d5FKzaJWrngLCCQJsMDZQtDraH2x4jzorwf8P0WyT 0Bp89RgAzhIAKt83XLeKzbq1GXEMQhvkI1R2y+3SvTmXBwWArbOnSrr2FuOnHxE8 XGHaPPRSBY+O/Jep6Pe/ifVlvplf5Ntr7shjPeiXaTVH43UAVB90qT8Fzppl+V9G ZK5QJvlUrybGJZ4l9F+tsLklpu5unFhAhAU//Pp0ZFwkdlAToR+PGUuqu8L8CFBL EJ4c6YCNIkGZJiu8ex18optnTM7QFAuc4xTsHzGKzfy5y1BtcEWChBZT4vdfjd8Q KoufVk+QGyLWKu7FSn1YgEE6rV9IlKknnCEkCy2YfWwJ5x34A15Yet19AiBzwsUN KwH/qPGfGCHVsNZaETF3ylqlTN1VLVwELW5WMbMpLFtJn/V1sv829vQToTvqRSVq y+VvpSCM0wb87rzoD0HCXA8gbk3kQu3HlfJD5ygY7PmBLaX1+tJ3ysRApkyDuaiB 9V7jajS0foaZGAgEi8Ef =t8le -----END PGP SIGNATURE----- --E5Aclq1ljX0U09k96uMQLUTgREL1PMq2p-- From nobody Thu Sep 14 07:06:25 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B36F132713 for ; Thu, 14 Sep 2017 07:06:24 -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 (2048-bit key) header.d=samwhited.com header.b=GBR80+Pp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=slMDykfy 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 wUnKAg__Je22 for ; Thu, 14 Sep 2017 07:06:22 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 250D6132335 for ; Thu, 14 Sep 2017 07:06:22 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 7092320E8E; Thu, 14 Sep 2017 10:06:20 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute4.internal (MEProxy); Thu, 14 Sep 2017 10:06:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; h=cc:content-transfer-encoding:content-type:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=2xG+SNroioo8wYayB kdVpioBQZ5OoTaOrQwUZQfXLXQ=; b=GBR80+Pp/BXJRkKWFwEpNMcLf3f/5jGV7 RO0kHIuZ8Whi67xi7PDvPVL/6lnBLbLzuPg0xM2mrxydFkT0eXQbCBVuj30s1R9c h+YRdAuRcIpXq4TV4R1bMpTdsqBAIit2Ko6veXbYxAm5HUefrf0bf0lo3p4kimpw UX2zQZ8dNoegmlqXzijMICZB7xLmJNLh5eaPlVFS9hjvvn9l1zh2ClaTkCYbvD/O oJzjgQY28WFh6FSl2L8wfzbjwbN0/S1Pqm4Q7AM9cV0umaq75ytbXsZcNfGeCa9X QC7NxjIe/mVjErPzacy+mxlcm8h5X04K9uNazCNEjR1V42y6+zN4w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=2xG+SN roioo8wYayBkdVpioBQZ5OoTaOrQwUZQfXLXQ=; b=slMDykfyVxamO5wdatiWkY o+DHrxlEIRAriIYbnhUsGur57vuX2eaUPWHK9H73jSd1iViGKEY2uuR+uyu1yDde w2k2zM7bcjHiGfUIJ4nv9VdZ6vyrAXwBw4ch9b2sEqvltfIQ0fy6+esGVbwKhAt+ 6HtmQbmVA/K0Fg0Z9kLFSkhcg5i3lUHIU2hn1H6lPmGf4tYgJG8mVjrm7jVMC4rc FrOFmHQ8NOp3gf5c1TYf2EYHHZKlkvlGBJm6GmBTBhmlR7J9cn+T/rqHVFUcWRTb AJMLG/8JLqfM7M5Em5Mr6FPUFmv0lMzKy3PUUZ1J/+dx2rpQ3GyhdiTq9DAm3YRA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 09BDF9E2C0; Thu, 14 Sep 2017 10:06:20 -0400 (EDT) Message-Id: <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> From: Sam Whited To: "Peter Saint-Andre" Cc: precis@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-64b08692 Date: Thu, 14 Sep 2017 09:06:19 -0500 References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> In-Reply-To: Archived-At: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 14:06:24 -0000 On Wed, Sep 13, 2017, at 22:38, Peter Saint-Andre wrote: > The Spotify folks faced numerous issues, including the fact that they > implemented against an unfinished spec. I'd say that if they now used > the PRECIS specs (especially the new ones about to be published) as > their guideline, things would have gone much better. I agree as far as the username profiles go (which is actually what they were doing), the major issues with those have been fixed as far as I can tell from my implementation / limited usage. Let's do the same for the nickname profile before publishing another since there is a history of this being a problem. =E2=80=94Sam From nobody Thu Sep 14 19:04:51 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F07813293A for ; Thu, 14 Sep 2017 19:04:50 -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 (2048-bit key) header.d=stpeter.im header.b=m9q+zogw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jBwigsJM 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 0cE6LrkQxYUA for ; Thu, 14 Sep 2017 19:04:48 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54A36127517 for ; Thu, 14 Sep 2017 19:04:48 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 3292320A22; Thu, 14 Sep 2017 22:04:47 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 14 Sep 2017 22:04:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=rF8a4o4NJsNhf6dxbiERU6oCHo9kWYu1f2e+yFo9s ZY=; b=m9q+zogwuwW6Gw2yZTYOf1k5KmNeUBanNTCNwtIXetD32u2m7zOM6mpyp EQtsqxgBck53JkaLdvGm+FpqGflMhGZ+MMlRLlEWSDqVgFx+/WyXqx71db6GpbvU Sq7bPW8fSCiCzqgClzzNeGDW/imXdgXLj0qhbwq4bqLZi7MP3QhtjrTmGfbBBBc9 tZCuo9JeR0tZc9NIGY53XGU5c58K2cmoTamsYhqxqYDMNd59cZiW/YeB1d4VSSBl TgsyyA4+igRdHCCFLG6Jp0bPC7z9khb9lCO4Vwolc5MpsFqFUB6j4fws59nuYnWF QEv1FKewYxv7pV/p59TALMXIBM7gw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=rF8a4o4NJsNhf6dxbi ERU6oCHo9kWYu1f2e+yFo9sZY=; b=jBwigsJM2Vt1RGvlAnjr+8jg7nGAM/YV99 uNh10kGTityx5DWX6QPi3YkeWzG5tZL1FqOedIyXSo5p+7NW8ZmzKhNrDQh4lOB8 eBbrRO2r2H2SoXpt33kWep5oEWG2v4vCwXjxBk1MIowtwXbw3yS/SQGVVcwhSWUd Aq9zCFG0ZyD0D5vb2YVgVVv6n/CnaiVXEefNgTTVgWnltO3aOpfwv/Qn/LC5JaJO t6WV9euDFKHpZ/IpIOnHlkGA4lryaMkk3ccQkkGxIfu2vw3LhjO7kqlYVvp1BF3p eiIYnaOKdlYi0dxEbUAuYd2Bv3clZDVVDswoSNOoHlk3mGH6jBaw== X-ME-Sender: X-Sasl-enc: WTTSxwiR4R45VtQ9d5NJwOw4oIQXqIV/O9Rh1vnOczp9 1505441086 Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id 947437E4F0; Thu, 14 Sep 2017 22:04:46 -0400 (EDT) To: Sam Whited Cc: precis@ietf.org References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> From: Peter Saint-Andre Message-ID: <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> Date: Thu, 14 Sep 2017 20:04:44 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7lUx8ihoL6tO3qpaxd4SA99deUes0IFgt" Archived-At: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 02:04:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7lUx8ihoL6tO3qpaxd4SA99deUes0IFgt Content-Type: multipart/mixed; boundary="RlxfEqo5aHwiM1kEM4uXaBftwcgDTMcfC"; protected-headers="v1" From: Peter Saint-Andre To: Sam Whited Cc: precis@ietf.org Message-ID: <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> In-Reply-To: <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> --RlxfEqo5aHwiM1kEM4uXaBftwcgDTMcfC Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 9/14/17 8:06 AM, Sam Whited wrote: > On Wed, Sep 13, 2017, at 22:38, Peter Saint-Andre wrote: >> The Spotify folks faced numerous issues, including the fact that they >> implemented against an unfinished spec. I'd say that if they now used >> the PRECIS specs (especially the new ones about to be published) as >> their guideline, things would have gone much better. >=20 > I agree as far as the username profiles go (which is actually what they= > were doing), the major issues with those have been fixed as far as I ca= n > tell from my implementation / limited usage. Let's do the same for the > nickname profile before publishing another since there is a history of > this being a problem. What needs fixing? We added explanatory text about idempotence, and there will also be an example of such in the RFC version. Please note that these documents are now in AUTH48 (very final edits before publication). So speak now or forever hold your peace! Peter --RlxfEqo5aHwiM1kEM4uXaBftwcgDTMcfC-- --7lUx8ihoL6tO3qpaxd4SA99deUes0IFgt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJZuzU9AAoJEOoGpJErxa2p6IQP/0hozFN2MSJwvU2heWumrUWu DOy1zbN9yGAKEEHVusTzubsxPsf7pslUTeSXeUpThB8alVF/Euy0fSuQR6Eifcst lYmSa5L0xA2X+HOLvzUOvOl5UEQSgEOvv3nSOhgvJf/fI8aRsiD6m1tshjCNOpsH gS05jaS5+xIerSOXEIR2SmIXHxUKIKm2w5uF8isBFi4lTxlK1Ja+WiIdC9Q2HAGW l6gJyQt5d0DO3t2QGw5MGsPXwhjHoLGK+lLludx5eQnSXEOq9XLF7hrPFnFmYaPs 3zdgc2nDCEm72gubGj09zm9raySDR740uHTkYgyXuoIUZR2pgkbHqrAvFaaQ2tod GOhFNEgPnjiRGL6m9NdWsHoPQP+Q8DTUfve6uWflpGpEhOBN5pQ6O3mVzYI+uONU ZPoY7R6BMFoGd3hb+amPLYdSEF66Onb0RQyCru3ecE8sErH731Rj83Zp9OQGIfld iVN3UJSxYZfCzjrRmdgjri1DXsNV+ZnE1uTNIiGsvrhi5heVHUwO6fn2bWZg6t/K IeU/AZ23GlQ4A65J21RBcxG/aX4ALPas0ndV5rf6vuJCH19Cqgy5GywIV0qttEoj t7MFMbnpo2tsynEps6ShVNCW6PonhFK6XhDiAtonCpl6wLMnC0HMPLaBE8iMWPfl qHFG6QH28XKpn4DN3YbC =/cPc -----END PGP SIGNATURE----- --7lUx8ihoL6tO3qpaxd4SA99deUes0IFgt-- From nobody Sun Sep 17 12:13:39 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060E0132F65 for ; Sun, 17 Sep 2017 12:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=samwhited.com header.b=Tszuz5hP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=o99i78Su 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 WA9wi9Qr5itF for ; Sun, 17 Sep 2017 12:13:37 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5306013301F for ; Sun, 17 Sep 2017 12:13:37 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 9E74E20A90; Sun, 17 Sep 2017 15:13:36 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Sun, 17 Sep 2017 15:13:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; h=cc:content-transfer-encoding:content-type:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=OHwwScX6GH0wt8TyM 6BK5qIYZ123K45UsUCA8mwkyuc=; b=Tszuz5hPSgpbZ30veV2j88ib4oc0F+BnB 9IUNpimKFhfdGu1OrJwmbvZxYycz5ldXeonEhe9o8oaLWzbnqBilCe4GMOSJygjc 8oZeaggoW4PlBeL0o9inX7Yel0dVcyoqHLYRLeJTN72HqTLMaizJYcZN6BCqCGDO otJmN6TLuXzyCWIpjYW0oEt2hjGD3jj3Ycmtbtj7/EtP4OWjcc9pPTSCM6Bdy4Vr okAS+0ozP69fX42ckhpdrPVeHojPWbT1nxKIduIAQW1DJlifVbHq6Ax8q8WB4wYW Ujq0NtSt3ACOzo0vTd0lRZ65B8w09kUoF0IKQhaiGS6rNITWysCxg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=OHwwSc X6GH0wt8TyM6BK5qIYZ123K45UsUCA8mwkyuc=; b=o99i78Su4e44ceezMey3rs He3AemwBys+X3M//t0QWeSWZ/UUeaNjRjWRF2zMpNOIBwM5d/p9iZVzZk1CG+Cw/ d27oI5njILMGB+I7LcvCUjEqpWvsfVzO0N7LKfAN1GTvyLu6O4DIdkKslCXsSamD Q2dXtShbXPLg9pl6TdAA24A2Y53tw+mDuAL00yotC8aZ/whnXqnK49Z7uAVEzAgt L9l5FKOvShfIJYwSJrvfES4ygJurKo2PgjVdywnM/y7kLGG9pfZ3H7e+BniaR/gf RZWsSwxcXA7RiVhJc6BVqI+cVRPSO3FR6GCqFsgT1qtp4J829AfwULXoZ3Xt3nkQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 6D49D9EB1B; Sun, 17 Sep 2017 15:13:36 -0400 (EDT) Message-Id: <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> From: Sam Whited To: "Peter Saint-Andre" Cc: precis@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-64b08692 In-Reply-To: <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> Date: Sun, 17 Sep 2017 14:13:36 -0500 Archived-At: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 19:13:39 -0000 On Thu, Sep 14, 2017, at 21:04, Peter Saint-Andre wrote: > What needs fixing? We added explanatory text about idempotence, and > there will also be an example of such in the RFC version. That is not enough. Someone writing a PRECIS implementation *might* see that. Someone actually using the PRECIS implementation (eg. the author of an XMPP Client, Spotify, etc.) will most likely not see that. If they're lucky, the text will have been copied over into the implementations documentation. That's a lot of "if's". > Please note that these documents are now in AUTH48 (very final edits > before publication). So speak now or forever hold your peace! I brought this up earlier as well. I wanted to bring it up again because the Nickname profile is getting so close to being published again with something that I think is possibly a security concern and that needs to be fixed since we won't have this opportunity again. =E2=80=94Sam From nobody Sun Sep 17 13:41:42 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F20213334E for ; Sun, 17 Sep 2017 13:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=mn0fmDBX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qvJRyez1 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 6WcWr_EYEWzM for ; Sun, 17 Sep 2017 13:41:38 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69E3B13301C for ; Sun, 17 Sep 2017 13:41:38 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id BBB1020B0C; Sun, 17 Sep 2017 16:41:37 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sun, 17 Sep 2017 16:41:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=DL/i7E/7idy0TNSEfMoFdVE+4oWiUTgOp82Qdsp00 MA=; b=mn0fmDBX2QPqCiGeYkbLo6OzUYtcyi6+vJx5B7nq7lXRYiVrQNALMQBIr 3va7xjWSgga7007kU5t7glD/BWNggdoiV40t1gDl7qeDlfE1RC9O0FeOmi5E3Uv9 yxQG96yD1LYCaKcyvSV9COt289pSJO7P7bJ5qx+T/3W4/vJjKgZRcDdPMpAI9Z5E 5TIVEPwaYeAf5tnVE3wjcxxTjB7xj7TSo+gcGCXpgK+EkWLlnlFeL/sFuMm84l7l XzeO66z3U4IAYmWQCyT4aK1VTWIFBJerUTVD3NUlay0B0hnxXdwsOtj+Z71xM0uo wFaRHjg+jN/GGyZUlPzU55LCb3suw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=DL/i7E/7idy0TNSEfM oFdVE+4oWiUTgOp82Qdsp00MA=; b=qvJRyez1vgk/id4RgtcryKnP772PFCRMks EGDxuyAtZm3oibylhjS6E19Dd2Cqg6yc+KYIFPLYRaKHflM/6h29fTv1uEKWfD39 Sd0tmRHBTwpkRcZ2vhqzPhcemcpsqzO7bvmyoqvBLDnndvXtG28OdVkWW8kmZfMv uf+v7Q8xMX3OxOJKARijhsoFW04APD3D6RLShlzaHfmqOva8woHEJYxKuEWYKskJ rra2U42SKKGUfbVgE1qRWJtZh9juVp1uozYWlcOzJhynvVaC6gFgMfORmqlqKWEP yK/m5xf6e1b+JE9hD9l6XOJzbEI/7X+QMd8YIOyCLF+3Qm4ODnnA== X-ME-Sender: X-Sasl-enc: w7wAFGT0GDHMpSrQEFiby0HYmGTtujmLJWg8++VWeits 1505680897 Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id 2C0077E125; Sun, 17 Sep 2017 16:41:37 -0400 (EDT) To: Sam Whited Cc: precis@ietf.org References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> From: Peter Saint-Andre Message-ID: Date: Sun, 17 Sep 2017 14:41:35 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="E38OCo06oekMu7qTxNs77veNC5ABqSuV1" Archived-At: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 20:41:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --E38OCo06oekMu7qTxNs77veNC5ABqSuV1 Content-Type: multipart/mixed; boundary="NEahEn14sfsd3jHPUB4X1uX4jW8GJQa6U"; protected-headers="v1" From: Peter Saint-Andre To: Sam Whited Cc: precis@ietf.org Message-ID: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> In-Reply-To: <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> --NEahEn14sfsd3jHPUB4X1uX4jW8GJQa6U Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 9/17/17 1:13 PM, Sam Whited wrote: > On Thu, Sep 14, 2017, at 21:04, Peter Saint-Andre wrote: >> What needs fixing? We added explanatory text about idempotence, and >> there will also be an example of such in the RFC version. >=20 > That is not enough. Someone writing a PRECIS implementation *might* see= > that. Someone actually using the PRECIS implementation (eg. the author > of an XMPP Client, Spotify, etc.) will most likely not see that. If > they're lucky, the text will have been copied over into the > implementations documentation. That's a lot of "if's". Why would an application need to care about this? This is an internal implementation detail of a PRECIS library/API, and IMHO it would be irresponsible of the library/API author to offer an option for application developers to select how many times to apply the rules. >> Please note that these documents are now in AUTH48 (very final edits >> before publication). So speak now or forever hold your peace! >=20 > I brought this up earlier as well. I wanted to bring it up again becaus= e > the Nickname profile is getting so close to being published again with > something that I think is possibly a security concern and that needs to= > be fixed since we won't have this opportunity again. Sam, I am going to reiterate that we are EXTREMELY close to publication of this document - it could have happened on, say, Thursday morning right before you posted to the list about this. Please please please either propose very specific text or point to an earlier email message where you did so, because personally I have forgotten if you already did that and my recollection from the previous discussion was that you did not raise objections to the compromise text that Bill Fisher and I agreed on. If your proposal is that we make significant changes to the document at this time, then the Working Group chair or Area Director will likely have to suggest a path forward, because your feedback is coming so very late in the process. Peter --NEahEn14sfsd3jHPUB4X1uX4jW8GJQa6U-- --E38OCo06oekMu7qTxNs77veNC5ABqSuV1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJZvt4AAAoJEOoGpJErxa2pS4YP/RlZb3IWfSFuPvALb3FxGQAk V9b/6J3xUk90xmOl2w0qQOT6b3MQEMKmK54kk1VFZCINk7L3OtaPbTpx4TY4QjV3 ltmBw6GdpQ/ARNjuXrYj3pf54mCT4tbAdw+UC7iSufjdzFRKnLrsnQVJx/oNHrzM iZBdbTywywMiw9BkiyeZtLgtDvi2JrBmuwohfUKeNdh/vxOytoXhAvOcSDX1ZKXJ +jf5fX9WNamxRFJ+32+21QMiC3SMzypjpJODNWwhFicuAJLGje3crUXgZG9YVAc+ sHLzXbEhtOxVx0p2uhKSuNzuArlYeQilywbWiddXTULNUK1vSfbyuK+DHh1lmEiS m7lK3Tx5tUiuhGe7bWnyUci03flOTkVrCB+ZfVK0pAu4trd8X9jpMbShtWzGB01N ioTDstntcbG0mF/tDLg3penX2kSNVUuRGPsUIt08SJpQUf/N/Ef6WrApq/kn0zj9 QJiHROkprjlNlEJxCQv5/z5CklU5iaMI06jbvXPODaVm4AdC/mU/HTGm9b8WDOxD kqBPPLp+nVuROKzbV28lDO2vXLZhm7Do4C+E3v9dGorbIn7+namt4uLaoWQb2SiK bDCQAAmZKh9EaP+zW4zYMo6Be9TZLfhrjMKoP5ljgyN1epRrbhPvgQ71K2DrYRSn gLC99ydt+Frrrz3HUXwp =h4l1 -----END PGP SIGNATURE----- --E38OCo06oekMu7qTxNs77veNC5ABqSuV1-- From nobody Sun Sep 17 13:51:49 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFEBC13339D for ; Sun, 17 Sep 2017 13:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=samwhited.com header.b=ONWlvnsd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XoVaIAtu 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 9LrZ68rc_0Pl for ; Sun, 17 Sep 2017 13:51:47 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCEFB13337F for ; Sun, 17 Sep 2017 13:51:46 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 51920209F3; Sun, 17 Sep 2017 16:51:46 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Sun, 17 Sep 2017 16:51:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; h=cc:content-transfer-encoding:content-type:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=q6OHEqFsNwAiXOvXr SlbnYfoX+HFGfZH/PgQSGfh1Yk=; b=ONWlvnsd/JF98BpLNQnJFwnja4pIjz9Ph Mm7iUiyjeV7m7Lf+YmjKw53Lxj3t4p8axopg7nSJnR1n10PnRkIUapgEX25+lZSJ NMOfRVt1z83weEGT7H1xDgtFwi+Zf2NjQcQg+IhVHwVgsgQIJMpv59Wh+mRgz1A4 DavpKOSI2/RTZkFK8DZ1FGEsnQ9zEzfLGaonKYgTXH8Gw2FKPyPWJYyPVNWPuN0O tZSW6+GA5jibQasSC1dEhil7L1bOR5dGoub3Clvsh1Rqlr7U6mnNOkFkfK7KYQVy ll/0MqVtWkRNpctD6WS0ODvw1vMDLmr0E3xqDTMaqeAJxzL5NEylw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=q6OHEq FsNwAiXOvXrSlbnYfoX+HFGfZH/PgQSGfh1Yk=; b=XoVaIAtu7in2UEFvOyw2Vp +AihydhIWODDM20YzpnpJoK2YfzT70gKBPgQ3QRfaiINCdj23ox5h0p8mqOMgAw5 h+9dTOqSbGWcUmKq1hJI6F6WpULPKJFXem5ACcnPy7zh4GTY83CCpnazgF1ffBPH oAi8XAmLsELQpotO5jkhjR5MmW7Vke84cSStlIluAvGuCpCS1yeEVc+e3glScezg tzFAr+yWM2g7YOzXHV/UjACjyp2NGPZxG80lBTecUlwebZoO1zVRU7MVCowjBg30 CRh5coS6dZ4fC5j3e7614A9ns7To1YCLXPY/9a4DNoT6TEhkwnts9OPA1wQSjBXA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 19DA89EB1B; Sun, 17 Sep 2017 16:51:46 -0400 (EDT) Message-Id: <1505681506.1709856.1109072624.0D72B3D4@webmail.messagingengine.com> From: Sam Whited To: "Peter Saint-Andre" Cc: precis@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-64b08692 In-Reply-To: References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> Date: Sun, 17 Sep 2017 15:51:46 -0500 Archived-At: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 20:51:48 -0000 On Sun, Sep 17, 2017, at 15:41, Peter Saint-Andre wrote: > Why would an application need to care about this? This is an internal > implementation detail of a PRECIS library/API, and IMHO it would be > irresponsible of the library/API author to offer an option for > application developers to select how many times to apply the rules. That's fair, but in that case this specific profile is a special case that takes a massive performance penalty even when it doesn't need too (if the library author did this at all). My point is that we can't count on this, and there are still opinions and if's in that statement. We should be trying to make this as secure as possible at the spec level; regardless of what we feel might be more important, if it's easier to not do this, or it incurs a big performance penalty to do it some library authors probably won't. > Sam, I am going to reiterate that we are EXTREMELY close to publication > of this document - it could have happened on, say, Thursday morning > right before you posted to the list about this. Please please please > either propose very specific text or point to an earlier email message > where you did so, because personally I have forgotten if you already did > that and my recollection from the previous discussion was that you did > not raise objections to the compromise text that Bill Fisher and I > agreed on. If your proposal is that we make significant changes to the > document at this time, then the Working Group chair or Area Director > will likely have to suggest a path forward, because your feedback is > coming so very late in the process. I don't have a specific solution; I understand that this would require reworking the Nickname profile to not use NFKD which is a huge change, and that's unfortunate, but I still do not beleive it's appropriate to publish this document in its current form. I voiced this opinion early on, and the compormise change did nothing to address it, so I did not voice it again at that time, maybe I should hvae. I am voicing the feedback again now because I think the spotify article is better evidence that this is a real problem than I had before. =E2=80=94Sam From nobody Sun Sep 17 13:54:37 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00431331F6 for ; Sun, 17 Sep 2017 13:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_fouPfLYHk2 for ; Sun, 17 Sep 2017 13:54:31 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BE001331E5 for ; Sun, 17 Sep 2017 13:54:31 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id k20so4862199wre.4 for ; Sun, 17 Sep 2017 13:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1ikCFrx/cP7bGq6toKufHD5QjEdma/yNcarL06fm0/8=; b=G5bdd+9Dge+YdKKqcV1uh0bGEyIV0+yzwK5GNC3krmc//xrvUHj5v32YmxHXbMjT/c DhRjzsLki/RfNPxkgd+4XsDahFIJEXToq28IiVYRgVJRNwF3lInd07BOTYJnCGzwmCrc JRcbB15T+tNPaA3dMwf8b85IfTyrPHZGNTAcW8rHGigDcW4IHc7spG0yWzOFfeR6luT7 yI7OnS8gw3p8arq/qhjoW6qSHiCP+GPTYH8GZ8VvVKFYavC34whPnxekg9UvKRBGKSRB jZEDHZ50uAw6Q2fmKkG8jgmcmgA+ne9lemealR3dqPWsF2lf76l74Al4esYfSM/Wd+KF x7Cg== 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=1ikCFrx/cP7bGq6toKufHD5QjEdma/yNcarL06fm0/8=; b=R2/+sryVLRws03CAF6Y2EWvE52loaWRk35OVXC41GNa36AQ4u0dEhx4wyBhcQwph14 1OXeLGJEoZpJaiP6HXMZts6oK6DE+tvp+1is3IaKM2rNgP25oAddytXr2qnpQQ/nAu17 rwrxgIQ05vIV/8gO0J8seGP/le5FCpKCzfbyjx4oQs5nB9v7Y1UAdK85Rs2WcIqMQVkt brnNZx9NJOHzNFv+xeioJmVGKONASGV4un+iwafQal9iY35Dk7bTFD7HNOix5BSRYUZ2 W3SU+V/FYxTc172XK9ocfV+OQc4mTLDPDnNeeIDatjEbx5G0GmmtnTm4U+3zaHGgexNn k8Wg== X-Gm-Message-State: AHPjjUilI5W0MsIglDRlGknRqccPd9ivOPA+FBdJ21X+66EjIPJOzV+A +yfpRpyUF/VkXji/iRFoYGX2a3i/MDW/WAxucas= X-Google-Smtp-Source: ADKCNb5LAudn6UrwJdKNiRbrbTNCrpnAwNd3bhhSpWBKNeZD5oN5BzwL7oNbtwIx3aEiBSS+C7ESR0MExIyeJLy6NzQ= X-Received: by 10.223.134.23 with SMTP id 23mr26481552wrv.93.1505681669738; Sun, 17 Sep 2017 13:54:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.130.1 with HTTP; Sun, 17 Sep 2017 13:54:28 -0700 (PDT) In-Reply-To: <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> From: William Fisher Date: Sun, 17 Sep 2017 13:54:28 -0700 Message-ID: To: Sam Whited Cc: Peter Saint-Andre , precis@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 20:54:36 -0000 On Sun, Sep 17, 2017 at 12:13 PM, Sam Whited wrote > That is not enough. Someone writing a PRECIS implementation *might* see > that. Someone actually using the PRECIS implementation (eg. the author > of an XMPP Client, Spotify, etc.) will most likely not see that. If > they're lucky, the text will have been copied over into the > implementations documentation. That's a lot of "if's". In the python implementation, the Nickname profile reapplies itself a second time to handle the non-idempotent cases. In addition, all profiles defensively verify that they are returning an idempotent result. If a result is determined to not be stable/idempotent, the code returns a "DISALLOWED/not_idempotent" error for the input. If someone writes their own Profile, the Profile subclass is responsible for iterating to avoid the "not_idempotent" error. > I brought this up earlier as well. I wanted to bring it up again because > the Nickname profile is getting so close to being published again with > something that I think is possibly a security concern and that needs to > be fixed since we won't have this opportunity again. IMHO, requiring a non-idempotent PRECIS profile to iterate to resolve idempotency issues mitigates the security issue. I do think this is the PRECIS implementation's responsibility. I have a vague suspicion (untested) that the double Nickname composition: result = nfkc(tolower(additional(nfkc(tolower(additional(input)))))) may be equivalent to the composition that you might get if you fixed the Nickname profile by re-ordering the steps. result = tolower(additional(nfkc(input))) -Bill From nobody Sun Sep 17 13:55:30 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEE11331E5 for ; Sun, 17 Sep 2017 13:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=VRzlyRHk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UKax/FtL 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 KZge0ZfQpVeB for ; Sun, 17 Sep 2017 13:55:27 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDD64133352 for ; Sun, 17 Sep 2017 13:55:24 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id CBABA20C0B; Sun, 17 Sep 2017 16:55:23 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sun, 17 Sep 2017 16:55:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=LDqaGJxrAeuUqyvIZUxzkSbhlTg+Lx5Pt4BgIKumG qA=; b=VRzlyRHk5lxAx1wURY1c8rLM/T1v6uG3UnNgPYma7S/RIBaYIuSZzbY3D 7LH7BfS9Cw8zCVvT6fTX70fnk+ft+IxYo14Za4qi8r3oIlBpk6Opakpfzk5kyNnK F73Kel8BbBFaAJDrmDuT3vtq8teQv8Tl1yPSrG8BcvcTtsY1kvdQOFbRfGzgHQWJ j2jKFogNpFcrVlD9jCMjCfJ+AZpvsMadTckTbQUiaBDgCZ1qHFjzCbV6k2y/46Ly ZNUCu+XeL9A/NVQvVlY5lilD9iHlAJeI3F3gEaLHTeju/2OO8tAZ32+Di3PbYy8+ +bDtTG0PKsf26oUNGglLI40E69cbA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=LDqaGJxrAeuUqyvIZU xzkSbhlTg+Lx5Pt4BgIKumGqA=; b=UKax/FtLH7FFhGaE82Vrc6LKwB0jROe7nn S776QxPSx9CBGlMIrryQTvEFfFnUZnhBh60KZ7yHoTk7iYrsAAU3gCaE28fm1xf5 jTtm1AnPcNJFw5XzNf0zw5ZOywRr88inxxqa+Kf06FTxiKUKcaljFClT6DXNL8xB n3Yj3CsGjha8DFicAvJswTeu8QpUYxhOIXm4BDyFIuk1FR8ICE4SojOG0lpZfBC3 NJ0ayKdqBWbxWC3EyvQP+07NIJWlOpUbBBxL3xvIG8N0TCDoNV8pe2SoeC7zh8GE Cmo2vjWR9LMsYqlMekzVr1pYGAMb7MTjin50fuPf0ignYxozL+Jg== X-ME-Sender: X-Sasl-enc: WktLBefgbdwTR1wcikWf1LCBDlqEtnqNXl1+Qgqz+I77 1505681723 Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id 371EF7E446; Sun, 17 Sep 2017 16:55:23 -0400 (EDT) To: Sam Whited Cc: precis@ietf.org References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> <1505681506.1709856.1109072624.0D72B3D4@webmail.messagingengine.com> From: Peter Saint-Andre Message-ID: <406663e1-8829-8e45-2716-904a657fd3af@stpeter.im> Date: Sun, 17 Sep 2017 14:55:22 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1505681506.1709856.1109072624.0D72B3D4@webmail.messagingengine.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5HWHtha59X7qQgTNgpAPifdmGqvkLWPDS" Archived-At: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 20:55:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5HWHtha59X7qQgTNgpAPifdmGqvkLWPDS Content-Type: multipart/mixed; boundary="OFnsEGTChMURN8i9lv2Thsrvu7QOwFgPk"; protected-headers="v1" From: Peter Saint-Andre To: Sam Whited Cc: precis@ietf.org Message-ID: <406663e1-8829-8e45-2716-904a657fd3af@stpeter.im> Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> <1505681506.1709856.1109072624.0D72B3D4@webmail.messagingengine.com> In-Reply-To: <1505681506.1709856.1109072624.0D72B3D4@webmail.messagingengine.com> --OFnsEGTChMURN8i9lv2Thsrvu7QOwFgPk Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 9/17/17 2:51 PM, Sam Whited wrote: > On Sun, Sep 17, 2017, at 15:41, Peter Saint-Andre wrote: >> Why would an application need to care about this? This is an internal >> implementation detail of a PRECIS library/API, and IMHO it would be >> irresponsible of the library/API author to offer an option for >> application developers to select how many times to apply the rules. >=20 > That's fair, but in that case this specific profile is a special case > that takes a massive performance penalty even when it doesn't need too > (if the library author did this at all). >=20 > My point is that we can't count on this, and there are still opinions > and if's in that statement. We should be trying to make this as secure > as possible at the spec level; regardless of what we feel might be more= > important, if it's easier to not do this, or it incurs a big performanc= e > penalty to do it some library authors probably won't. >=20 >> Sam, I am going to reiterate that we are EXTREMELY close to publicatio= n >> of this document - it could have happened on, say, Thursday morning >> right before you posted to the list about this. Please please please >> either propose very specific text or point to an earlier email message= >> where you did so, because personally I have forgotten if you already d= id >> that and my recollection from the previous discussion was that you did= >> not raise objections to the compromise text that Bill Fisher and I >> agreed on. If your proposal is that we make significant changes to the= >> document at this time, then the Working Group chair or Area Director >> will likely have to suggest a path forward, because your feedback is >> coming so very late in the process. >=20 > I don't have a specific solution; I understand that this would require > reworking the Nickname profile to not use NFKD which is a huge change, > and that's unfortunate, but I still do not beleive it's appropriate to > publish this document in its current form. I voiced this opinion early > on, and the compormise change did nothing to address it, so I did not > voice it again at that time, maybe I should hvae. I am voicing the > feedback again now because I think the spotify article is better > evidence that this is a real problem than I had before. In that case, we'll need to invoke the WG chair and/or AD. Peter --OFnsEGTChMURN8i9lv2Thsrvu7QOwFgPk-- --5HWHtha59X7qQgTNgpAPifdmGqvkLWPDS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJZvuE7AAoJEOoGpJErxa2pD7gQAKifeXuvPF6Cvsu4Lp1vgkPI HYu8pYlWOcqYNaVcz4ai0DzH2OJZaRuZ0XEnxdvlEL4AxvlnMy/8HtWv4oEP+Tai dArIGtkMVqdhxjC3UI2l0xhIGsb/sluEHSuTQjcIu3qrivMgmQ4T7uhx6DPkUVVT Qjg0pKxmWYEBLNLa3URLgxC3Qk3U7jXqOYwj1qO5+O5yUe2sQjtdPKPhc6YC4pzo yUlT4okdjnhUpOlOoFNuOKBkRu355mVUAeNjaNpFfIilMlcHZ5WANAMQ70kYJAcW SD79x5Du5FyxAs0RIR2XhLxXUcxa31HS/UCQ5Mxya/FqopTZgpb2hSXC6OFeMojq lGLBc4d1cY2/Ao4x4uAWnjYuxxATTDvEypKTY62I32rXRdXF7O5gxVmIbB45ggLa vXLwgFY7MIYYwGOC6Nr3belnYikrPa83nz8/iRtLqUNX4e/W8FDK+YkcCyoRitJi TaGyXh25HeGe071hF+O4aattIvB3gjQ0NbX2CGdyCBY6b56f6yhquGJQIpFmiWLa 5Z1+mU0CDl/KKEmObF7fBlg2g79sz4a5uwXvUbAzwdEJFUWo/fa+5UsGvj0suBku KV0B+4UckdyCvZz5v1f5oCuGW7fV2k8+GeGaCzFJ1RZqmCRMMujyh9yj8TquMyNv jQB9zThHa0QfzMvKqaZt =iXhy -----END PGP SIGNATURE----- --5HWHtha59X7qQgTNgpAPifdmGqvkLWPDS-- From nobody Sun Sep 17 13:57:42 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4694013336A for ; Sun, 17 Sep 2017 13:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=samwhited.com header.b=gJ4FUaJ8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=P/fSaVtu 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 okARGa6vHhhw for ; Sun, 17 Sep 2017 13:57:40 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E8921331E5 for ; Sun, 17 Sep 2017 13:57:40 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id BAC2320C7E; Sun, 17 Sep 2017 16:57:39 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Sun, 17 Sep 2017 16:57:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; h=cc:content-transfer-encoding:content-type:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=bwpB9hD7DFjcC2tJs No8CUKwQ59GyPqGGjxqXC4FGe0=; b=gJ4FUaJ81XtIK5oP5SroPLcLIYfnutuKV 9OIkW3HGfTHd1ST/7B5UsxrMgg4jRc2dr+LfcyQxDPxiqwtVHAsI7sY+T/uDUvMP ZsKQacSl6g8Zgp3MhnK9B0DqRGzpENj0iXKjEb8ujx/8B/iZOWe05815A0cn97f/ fJaRqRd4oqcWPE7Ay+PO63Nkc439E1WCLeIHChxVhTPrAZtXeQ3CIYipadnaqh9k KKANvdyaszBQrzket/e165DVp0ImBgdLBneIZZ/HZ5chLMB3bPzm4uOYf2oqfi8D K4I5s8z7ZD3QwH/qypvgif688VLpB+LzffhbtoIgfZBuEtu6DxH7A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=bwpB9h D7DFjcC2tJsNo8CUKwQ59GyPqGGjxqXC4FGe0=; b=P/fSaVtuaF9lX4pNXE/jxJ 1UZ3Wm0szFnYloRalfKTRlzJ/tjCpr/tUHwD/mawkClKVrxkmGcHbpbUzc7tR44d rAS7Y+DmYCxuQYvoRnvKPjk3ZBlqecr7YOSbVzllfRtXqGwx59gOvEieb7ItSn6e bIOSiq7x5a/X16mdtAuXZbr6E6JQV6OGFH5DXycNxyVEEplnrp1goiBUgHBU/vyw PzLQD6nXt3as3n8Rse6Ug5OYg8E/eSiDv2hdbB8GQNjO1JHZal4sngvMV74DBU4K ddtfsgZb4wsbBIfllHYbexNxfa0+T7PkBgw9TDVwD+TAsZ9s7FzmrKE6GCAsCiTA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 9E74E9EB1B; Sun, 17 Sep 2017 16:57:39 -0400 (EDT) Message-Id: <1505681859.1711250.1109076296.3DFD0692@webmail.messagingengine.com> From: Sam Whited To: "Peter Saint-Andre" Cc: precis@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-64b08692 Date: Sun, 17 Sep 2017 15:57:39 -0500 References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> <1505681506.1709856.1109072624.0D72B3D4@webmail.messagingengine.com> <406663e1-8829-8e45-2716-904a657fd3af@stpeter.im> In-Reply-To: <406663e1-8829-8e45-2716-904a657fd3af@stpeter.im> Archived-At: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 20:57:41 -0000 On Sun, Sep 17, 2017, at 15:55, Peter Saint-Andre wrote: > In that case, we'll need to invoke the WG chair and/or AD. Thank you, I would appreciate it, but am also aware that my opinion really means nothing here since I am not related to the WG. Do as you see fit; I just wanted to make sure this issue was brought up again before these documents were approved, since this may be our only chance to fix this for a while. =E2=80=94Sam From nobody Sun Sep 17 13:59:21 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A480213337F for ; Sun, 17 Sep 2017 13:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=ej5tK4kJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XT7TvXZC 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 xUIqe1LUMYyd for ; Sun, 17 Sep 2017 13:59:18 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A3EE1331E5 for ; Sun, 17 Sep 2017 13:59:18 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id A050520B6A; Sun, 17 Sep 2017 16:59:17 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sun, 17 Sep 2017 16:59:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=niQaTAa9qvOfMBhTfciXY8y5y7JQWWEKKzJcLiLZm EI=; b=ej5tK4kJ8VPDo95cgRffPZ5YulgdF/tAOsNG9nHAFUFOXZeU0Chc6YEwr r6pMi+16OFPTQh2gMHznLxv//xGPXyY3nMiDY+pEzSXkB96R547kD4GMyXyjsK5C dZkeJ44cATcBf46/kD+o8FBIOlziSX1Bd2sV6I9Ie5jb0t88m688xINdjz8UB3JT JEt453/LruWDmr3HuYKhDCWXhDKICzbclOcVlBts8cOtnbyivC0kJsJkKbYChhtq VYDPpquG2WU3pXzevHXfqDDnVFQxMCnFHGyZLRKPA3SWEcpzCEDRtZ+PUZ+hxZ4J q0m3J3ULGBY4+ingni4Fd9r6KMh7Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=niQaTAa9qvOfMBhTfc iXY8y5y7JQWWEKKzJcLiLZmEI=; b=XT7TvXZCDNDXA5pst6hwzKbSLCJGEhDtJH mQzSZMZ990dXe4KJxhpynWmndISek+ZzsDXqiXJ3paF5Yl86UnIvLiBMJTG2aX2f RNJuInvPXLhL3DLqPVFTVIbygEurGsQnPAIVqyGf0OEel7DGOskuU/8IGFyhTN5e wmkbXMrZG7Qi9nA5gpTUJwLh0tB9U3Dn4MfnOWY+CWpcXrEPO+r/xM90jC860kHd 6XxGXTi4kLkHD4LgVDn2EN4hOBGZCY1fjdsV2+tm5Xyn1nRmHZ0tb71UVVicyMy4 hzVHCmhFO+IBJdDeWLlPHw4tEwzMDjhN2GsZ0Sbktk5Of1MLg78w== X-ME-Sender: X-Sasl-enc: 3H0Rv6wDPiVG/f0XWj0Mk+h0PmYgpTkg6Myc7fTZb7b0 1505681957 Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id 1223D7E8ED; Sun, 17 Sep 2017 16:59:17 -0400 (EDT) From: Peter Saint-Andre To: Sam Whited Cc: precis@ietf.org References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> <1505681506.1709856.1109072624.0D72B3D4@webmail.messagingengine.com> <406663e1-8829-8e45-2716-904a657fd3af@stpeter.im> Message-ID: Date: Sun, 17 Sep 2017 14:59:16 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <406663e1-8829-8e45-2716-904a657fd3af@stpeter.im> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AihO69WiJoeAJWIluTXEQLnCucB1tvUBH" Archived-At: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 20:59:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AihO69WiJoeAJWIluTXEQLnCucB1tvUBH Content-Type: multipart/mixed; boundary="VirwlWWVXgjGIVO15BTtARgIsoQrHxjib"; protected-headers="v1" From: Peter Saint-Andre To: Sam Whited Cc: precis@ietf.org Message-ID: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> <1505681506.1709856.1109072624.0D72B3D4@webmail.messagingengine.com> <406663e1-8829-8e45-2716-904a657fd3af@stpeter.im> In-Reply-To: <406663e1-8829-8e45-2716-904a657fd3af@stpeter.im> --VirwlWWVXgjGIVO15BTtARgIsoQrHxjib Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 9/17/17 2:55 PM, Peter Saint-Andre wrote: > On 9/17/17 2:51 PM, Sam Whited wrote: >> On Sun, Sep 17, 2017, at 15:41, Peter Saint-Andre wrote: >>> Why would an application need to care about this? This is an internal= >>> implementation detail of a PRECIS library/API, and IMHO it would be >>> irresponsible of the library/API author to offer an option for >>> application developers to select how many times to apply the rules. >> >> That's fair, but in that case this specific profile is a special case >> that takes a massive performance penalty even when it doesn't need too= >> (if the library author did this at all). >> >> My point is that we can't count on this, and there are still opinions >> and if's in that statement. We should be trying to make this as secure= >> as possible at the spec level; regardless of what we feel might be mor= e >> important, if it's easier to not do this, or it incurs a big performan= ce >> penalty to do it some library authors probably won't. >> >>> Sam, I am going to reiterate that we are EXTREMELY close to publicati= on >>> of this document - it could have happened on, say, Thursday morning >>> right before you posted to the list about this. Please please please >>> either propose very specific text or point to an earlier email messag= e >>> where you did so, because personally I have forgotten if you already = did >>> that and my recollection from the previous discussion was that you di= d >>> not raise objections to the compromise text that Bill Fisher and I >>> agreed on. If your proposal is that we make significant changes to th= e >>> document at this time, then the Working Group chair or Area Director >>> will likely have to suggest a path forward, because your feedback is >>> coming so very late in the process. >> >> I don't have a specific solution; I understand that this would require= >> reworking the Nickname profile to not use NFKD which is a huge change,= >> and that's unfortunate, but I still do not beleive it's appropriate to= >> publish this document in its current form. I voiced this opinion early= >> on, and the compormise change did nothing to address it, so I did not >> voice it again at that time, maybe I should hvae. I am voicing the >> feedback again now because I think the spotify article is better >> evidence that this is a real problem than I had before. >=20 > In that case, we'll need to invoke the WG chair and/or AD. I have forwarded this note to the chair and AD with a suitably scary subject line. If we don't hear back from them before 8 AM Pacific time tomorrow, I will send a similar note to the RFC Editor team to stop the presses. Peter --VirwlWWVXgjGIVO15BTtARgIsoQrHxjib-- --AihO69WiJoeAJWIluTXEQLnCucB1tvUBH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJZvuIkAAoJEOoGpJErxa2pKY0P/jIcMWaD1n+RIAxPS2V5c2iv JN7+FgbVx6RWJ8d6Q6vFeOG5mxWrNXaauhTHQXIegB/wuY5CH+Ya/oKr2sk+yG9J TEy+Y3RI7/kQnXsbw82mfhE1QNU5DRr52GBGV6S/e1/sPhgVEI9sVyelQwTgmHfq 8AeQJWfWtt1TPju2Y3t7SqtQwgoz4VusYA4WZg4+ielTNKRrE1zC1+oMhq/KNQmo blEkD1XnpH5YakyQMbjeNTeeJ8GaSvRjcXXf0XC9yYxmERl9c1eI2TXv7lPeRcFD KQ27SazNYB+fZCYtvm3jucDdeM6QTqXZrOhBtL1JELfhpvrHBGnT3ef7g3oM3KcL cFjhK6BkAG+ToYtpwyJoxXCHfTroX0IW1GODAsQ0Kgq1C7mf/n/tU80DXRM1+vKX q76NcoHJR3IVJ4mIAadvgkScdzC3isa/gpFf90RCAiQDANhYnaYTWLZHMwWG8j5E dhoH+NgAFh+Ufi72l4Pkd8MLXePNbdVxhFLZUEcQpzMLT1zTYkT0NWl8rOXVXup/ 7Tt+7j//Gx+d3iIdhBf6UdricRQqNCZUbX4CNeidw7AaNvW/uHJ7oU2ECwxLAc5t Xt5byexmQC6lIcPhtsgHLG5TcaMy+hGfmOy/WzyAtU4fnFUrTP7bAMFNXcWDlnwg lTuulTz3o5iZf+T+R5sz =ymxh -----END PGP SIGNATURE----- --AihO69WiJoeAJWIluTXEQLnCucB1tvUBH-- From nobody Sun Sep 17 14:00:43 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0556133052 for ; Sun, 17 Sep 2017 14:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=QcQbXC50; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oFW5OEZV 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 tDye-_vlC5sH for ; Sun, 17 Sep 2017 14:00:40 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A261132F69 for ; Sun, 17 Sep 2017 14:00:40 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id E22CB20AF1; Sun, 17 Sep 2017 17:00:39 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sun, 17 Sep 2017 17:00:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=IqUZQKGcpR+vyo9L36Zj4iJbpoCzbCnnuWs2PCFXe yM=; b=QcQbXC50F57Ixlz7BffGk7rE4RROtpbrIpno0kY6HFycA6js8qRakiVS8 fTMu6XPEe/ncbB4352Ux0Xi9C0nhojhUYgBWyyKuf0XqiiJ7dsMbY4aD97IY9vTk shfJp1d6QoKbTZBB8ihUqXR+pxnkqPyeBmiYYgdHJF5WISI4IkUx4Vrhn4rIde15 mZmJ1yScEXwWcJhLCmynIB0+zbrTpjvYpxuyd2sG50W5dmxmu/+5qx6M2G36Jb8C /cLdtsVpGAN8K3NqMubau1OhqPVREXfaT39LjUPmTfLZLZ/3KOX5KQO6tphSnZwu MpKJXXfx7yvc6WDLRmwfBMTpSTDXg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=IqUZQKGcpR+vyo9L36 Zj4iJbpoCzbCnnuWs2PCFXeyM=; b=oFW5OEZV7p8NWzEmVw8Xk0KqYj7M8UzJAX MY991qeX4iKIcTtqiJ5NlVGAAWe/bYhA7+TN2N25dhDOY3MHBg54HS/h7F256UTS WtiWeGWjzMJcAjAqJC8Ey2sviCZ5W+LKQdG268lHTEEQCJH4CL0vgS1BWMwCdLJa iAYMwwXDpPT91uKv6dl6oZ97aVG00D4h6LVkeFQpIpMVbA6IupU5xgj8BCP7ne/K UUm4PvwJ7SlCNBTr/nDDBDwSEBQPFlkjHcuVQiR8BgLXweWo9Z+aFF9qnJmxI3dl TYg7UOVZa+qVgD6b8thcNttZssrarArCoKsj5KmC6FLAjh/4aS+A== X-ME-Sender: X-Sasl-enc: JHIDv67WVHXlOnoVh6c7x+y1k7hnTFR5zK4akoUEcKoS 1505682039 Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id 5E1A87F97C; Sun, 17 Sep 2017 17:00:39 -0400 (EDT) To: Sam Whited Cc: precis@ietf.org References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> <1505681506.1709856.1109072624.0D72B3D4@webmail.messagingengine.com> <406663e1-8829-8e45-2716-904a657fd3af@stpeter.im> <1505681859.1711250.1109076296.3DFD0692@webmail.messagingengine.com> From: Peter Saint-Andre Message-ID: <91b2758f-6143-295b-6a59-78e6d4e9b497@stpeter.im> Date: Sun, 17 Sep 2017 15:00:39 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1505681859.1711250.1109076296.3DFD0692@webmail.messagingengine.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qASIGEkNXslsH9aG0eUmJiAl4vRSUuGDg" Archived-At: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 21:00:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qASIGEkNXslsH9aG0eUmJiAl4vRSUuGDg Content-Type: multipart/mixed; boundary="4abnj0r4BSsdgQ1pGpo9Bqg6S5QwKeWLL"; protected-headers="v1" From: Peter Saint-Andre To: Sam Whited Cc: precis@ietf.org Message-ID: <91b2758f-6143-295b-6a59-78e6d4e9b497@stpeter.im> Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> <1505681506.1709856.1109072624.0D72B3D4@webmail.messagingengine.com> <406663e1-8829-8e45-2716-904a657fd3af@stpeter.im> <1505681859.1711250.1109076296.3DFD0692@webmail.messagingengine.com> In-Reply-To: <1505681859.1711250.1109076296.3DFD0692@webmail.messagingengine.com> --4abnj0r4BSsdgQ1pGpo9Bqg6S5QwKeWLL Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 9/17/17 2:57 PM, Sam Whited wrote: > On Sun, Sep 17, 2017, at 15:55, Peter Saint-Andre wrote: >> In that case, we'll need to invoke the WG chair and/or AD. >=20 > Thank you, I would appreciate it, but am also aware that my opinion > really means nothing here since I am not related to the WG. Sam, you are very much part of the WG. The IETF doesn't require membership, just participation, and you're participating. > Do as you > see fit; I just wanted to make sure this issue was brought up again > before these documents were approved, since this may be our only chance= > to fix this for a while. That is very true. Peter --4abnj0r4BSsdgQ1pGpo9Bqg6S5QwKeWLL-- --qASIGEkNXslsH9aG0eUmJiAl4vRSUuGDg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJZvuJ3AAoJEOoGpJErxa2pS9YP/2HrfkUO8Nq/nmMEpKgccBBw G37Fph4KFJ5/XsJaVETp4YxkP9H77ykVIRKI6K6Qw5Y37TpIYCBZhVFivVu07KaQ QmDQuNCRgxZ70eZ18MorJFrVVO0sWJy1JzbrM5skPUk6cPLe2QB4taKigCA7Dseq 9h5B9f0RF628j/TBT3vRTB0EwVEuDk8FKeiiR2dRiboVpZnVODUjqkOPq9S54GoD wMQkPqVKOJV3kUxdoIFdFplxRcb4wpGV6fnmwvjBEUkAPO+k9RMG+xrFM8XHfBdR xvv/4biObNFTSMKE5INLO4xxHyX6gZUpivC8P7JNOASm8qvZaFg2lycTRWlYZLGa ZihqVVu1SiymP5BtpLXylJtuV4L+lNdfL3RaAsM7GxorUGs1nYkqT3LFNo1eGxB0 ubWzAcWNiIrbC9xznHsS+S+PWGrhxL3k6Xb1Db25Ay6YZ3RoYfb12ubTFPufu717 fdnpcscLOdFo81dmMfUA9JS46PNtfHjy9pcWPWIeyVoABVqiGjHbuCbWR0+g2Obb fS723AUrsiAzZE+ExfvkzOZ2ZfgdOEVNa6tukHSW4eng1OBcKTMYOrehjb7Kc+Dn sgRLzU38/IIRC84qFP/LeLkC70k1tnhI/e+HxfhhYfGv1vz/MDMULxqRw/ggv/Ei QsiEjGeun5R6KNJJG/66 =WKqo -----END PGP SIGNATURE----- --qASIGEkNXslsH9aG0eUmJiAl4vRSUuGDg-- From nobody Sun Sep 17 17:02:40 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D131320DC for ; Sun, 17 Sep 2017 17:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=Tez29TP2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LcB0dBZD 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 5vIbhT0WqUfX for ; Sun, 17 Sep 2017 17:02:36 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2102126E64 for ; Sun, 17 Sep 2017 17:02:36 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 1EBBC2090D; Sun, 17 Sep 2017 20:02:36 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 17 Sep 2017 20:02:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=ioNegREv2Uvr2fDtTOFXIYx2/fLjX34rK5WgRFw30 mc=; b=Tez29TP2eXhDvQVA8Mch3Xgi9zpAuga4DWoHVbF5iXmbAElMMh56rfmXh nezB9ldojbdO8Bhc08YLwBAsXrVoSDUSu4Xl7Pd0vT1Mcd0gykU9wQibbYS5tgnC ERkXwEN6RT/d1I4HOHSS4sA/sOBM4gBOYVO0ojgeDviX0eM8vMBrBAxssbOkaztw pI/CMLTKW9z2Gt9cZTnVSyQxgj2FVi4vwON40MOuMS8zG+eh/XL94KsPxr8/3YkS infjcYJzW8ERFdAQ1cki/rWhFoMmHQ2BADdnFnhgdU1OX70V7Han9ejpGPBIJPw6 8W9bMmugrMtQ5O0NcmEQZn68Zq7+w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=ioNegREv2Uvr2fDtTO FXIYx2/fLjX34rK5WgRFw30mc=; b=LcB0dBZDOErhpsECJcKxwogZlMbbLuWc9m XOkGnffn97fh8egTf6K8NP9Bq1vP3wfGkGjwLgGwWaqmeyCU/hc5wmkiME0ASjJ+ hf/m5uFJpBEpCpqaIiJoGEnaMWTkS8y4tPRDAehe9zGTdUKvNE2BcVi4HoR1K+Yu DGOxrVfQFUlmiLOOWleeC8isrXKfqSzWqn0DmK6JepnSTVhZ4/ziiBzfgfXtMMHe K930p3gPZQKdQZFY4lX7TRJ/FGUlL1mpu1LqZZzvx5iIQIPbR8hlnkxsZhjBT0lU +kVS7Yiqaygjb23CmogO1r/Hm0wSDOxPOrOmn6kwa3f8L+h8AWrQ== X-ME-Sender: X-Sasl-enc: lTtLq6vIudw/lvJChbThaC4aStaYjcnRHmNqeANJn7db 1505692955 Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id 7BC492489E; Sun, 17 Sep 2017 20:02:35 -0400 (EDT) To: Sam Whited Cc: precis@ietf.org References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> <1505681506.1709856.1109072624.0D72B3D4@webmail.messagingengine.com> From: Peter Saint-Andre Message-ID: <70293ba4-d48d-fe38-4ea2-cfcb8254978c@stpeter.im> Date: Sun, 17 Sep 2017 18:02:34 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1505681506.1709856.1109072624.0D72B3D4@webmail.messagingengine.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Ei9bIaraGbfPTpLQOoaK5Cb2qfqUb61iA" Archived-At: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 00:02:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ei9bIaraGbfPTpLQOoaK5Cb2qfqUb61iA Content-Type: multipart/mixed; boundary="JFKueHmNabS1RM878bohUoHaxhEqJ8vd5"; protected-headers="v1" From: Peter Saint-Andre To: Sam Whited Cc: precis@ietf.org Message-ID: <70293ba4-d48d-fe38-4ea2-cfcb8254978c@stpeter.im> Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> <1505681506.1709856.1109072624.0D72B3D4@webmail.messagingengine.com> In-Reply-To: <1505681506.1709856.1109072624.0D72B3D4@webmail.messagingengine.com> --JFKueHmNabS1RM878bohUoHaxhEqJ8vd5 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 9/17/17 2:51 PM, Sam Whited wrote: > On Sun, Sep 17, 2017, at 15:41, Peter Saint-Andre wrote: >> Why would an application need to care about this? This is an internal >> implementation detail of a PRECIS library/API, and IMHO it would be >> irresponsible of the library/API author to offer an option for >> application developers to select how many times to apply the rules. >=20 > That's fair, but in that case this specific profile is a special case > that takes a massive performance penalty even when it doesn't need too > (if the library author did this at all). >=20 > My point is that we can't count on this, and there are still opinions > and if's in that statement. We should be trying to make this as secure > as possible at the spec level; regardless of what we feel might be more= > important, if it's easier to not do this, or it incurs a big performanc= e > penalty to do it some library authors probably won't. >=20 >> Sam, I am going to reiterate that we are EXTREMELY close to publicatio= n >> of this document - it could have happened on, say, Thursday morning >> right before you posted to the list about this. Please please please >> either propose very specific text or point to an earlier email message= >> where you did so, because personally I have forgotten if you already d= id >> that and my recollection from the previous discussion was that you did= >> not raise objections to the compromise text that Bill Fisher and I >> agreed on. If your proposal is that we make significant changes to the= >> document at this time, then the Working Group chair or Area Director >> will likely have to suggest a path forward, because your feedback is >> coming so very late in the process. >=20 > I don't have a specific solution; I understand that this would require > reworking the Nickname profile to not use NFKD which is a huge change, > and that's unfortunate, but I still do not beleive it's appropriate to > publish this document in its current form. I voiced this opinion early > on, and the compormise change did nothing to address it, so I did not > voice it again at that time, maybe I should hvae. I am voicing the > feedback again now because I think the spotify article is better > evidence that this is a real problem than I had before. Sam, I've had a chance to think about this a bit more and I would like to point out a few additional aspects of the issue you've raised. First, the Nickname profile is based on the Freeform Class. As we know, this in itself is a dangerous move. If you want safety and security, you really really really need to use a profile based on the IdentifierClass. We have emphasized this many times and it is clearly expressed in the various PRECIS specs. If we need to add more warning text to 7700bis, I'd be happy to do that. Second, we have make this dangerous move for the sake of greater expressiveness in situations where, in essence, it doesn't matter very much. For instance, in XMPP all authorization and authentication decisions are based on a user's Jabber ID (of which the localpart is an instance of the UsernameCaseMapped profile of the IdentifierClass), i.e., on a much safer construct than a user's nickname. Other uses for the Nickname profile might be as petnames for things like user-visible bookmarks - i.e., for things that are not shared across multiple users, used for inter-user communication, or relied upon for authetication or authorization. So I think the scope and implications of the issue you have raised are much more limited than those we can directly derive from the Spotify story. Third, in Section 2.1 of 7700bis we've explained the reasoning behind using NFKC instead of NFC: 4. Normalization Rule: Apply Unicode Normalization Form KC. Because NFKC is more "aggressive" in finding matches than other normalization forms (in the terminology of Unicode, it performs both canonical and compatibility decomposition before recomposing code points), this rule helps to reduce the possibility of confusion by increasing the number of code points that would match (e.g., U+2163 ROMAN NUMERAL FOUR would match the combination of U+0049 LATIN CAPITAL LETTER I and U+0056 LATIN CAPITAL LETTER V). Your proposal to scrap NFKC in favor of NFC would actually make things worse here, because matching would be more lax. As a result, users would be more confused and attackers could more easily impersonate legitimate users. Is that what we want? We're trying to strike a delicate balance here between safety and expressiveness. The Nickname profile gives developers a very pretty gun that allows them to shoot themselves in the foot. In some restricted settings, where it doesn't really matter, the Working Group has made the judgment that this is OK. If you are indeed deeply concerned about the security implications of any use of the Nickname profile in Internet applications, then it would be better to argue that it should not be published in any form - or, at the least, that it needs to contain more warning text. But I'd argue that modifying the normalization rule of the Nickname profile doesn't really solve the problem, and actually makes it worse. Peter --JFKueHmNabS1RM878bohUoHaxhEqJ8vd5-- --Ei9bIaraGbfPTpLQOoaK5Cb2qfqUb61iA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJZvw0aAAoJEOoGpJErxa2pcIQQALERDR3T0mWNMD908Or6elkQ meVLvT6Ck8v/OQYCVeTsIgMEvIlqQaiFCvuw2LgzvhVuMbXNuSFwviptCjeqz/3T eGebBJIwDVV7nS/VRLWwuANGK8+GpH/vwv3sI0wCtO+WRCmZHN9OMgnVf/h2hTsM Wt9S1L9g6tPkhdkrOfK7pv/0KTirEv2SPP4R8t5arjVwYIpnD7+w/f7CAAU6Z7D7 dC1zqDdU/yy/g9aczEHAYI9/LJj2VyF2QECCymf3hmj0WpxM0YC3xBGjKKDcbHjo v3IXJ+xcDS4RnVYrI69l08gnKbTDsaZGnsuYhpHWUfE6lRuhbnhXtIW1lLL7O2sF WnEiM19+jbmIsmGeQ6u3htEapbVSwnDmfe51vqz1ymVvKEtzoWpCAt1ckfatGG+R W9BPQVmndf+H4fd89/r6g16S9HEzNbMe5jVBFlHjzMuz7FweHhn/YmhxQcuD0sFR od6RDtLtNMYNJy4NhO9XGWqZpRkwk78VbQQyq6XepZa3YG9WXzCPSSQ5nAvnOcd6 adu8yI0BvqpdEGiekE7/KxNaGYjzTeMub3Wp/gxYkkBU2SAWKSrJfM276+imoERg 5Qs4GSxO5reP6ltt5odpEnm/qHEIO2EvoyUoCmPyAoIA20nEDrhyosS5EF7S29o5 NuAU96/vVfd9gUGzFlNX =mDBV -----END PGP SIGNATURE----- --Ei9bIaraGbfPTpLQOoaK5Cb2qfqUb61iA-- From nobody Sun Sep 17 17:37:27 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1CB132C2A for ; Sun, 17 Sep 2017 17:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=samwhited.com header.b=hoGLgL7H; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=a63UsAMM 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 mSRy4LIoSlY3 for ; Sun, 17 Sep 2017 17:37:25 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A6513243A for ; Sun, 17 Sep 2017 17:37:25 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 356E620C3E; Sun, 17 Sep 2017 20:37:24 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Sun, 17 Sep 2017 20:37:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; h=cc:content-transfer-encoding:content-type:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=pjWarFroiNVDFW+en nFBVf3QjBA6/4HeRm918N3DfJI=; b=hoGLgL7HZA5SXDhF78C8oBJO4YMrPohGl dOxCTxZPDt1gvb4WH6qoj4OZCtUeCiUOzPHZrlOGN+OcDcxXSTVUjdn0f7/tbzPg 8qZHAZgEzTp0dxUCx0XWRLPWMbAGM5scDSIKIGMF6RjPvPh4KOlm4vfE7q3oIuCK orQYAP3Z6Rr6G9hggoaEZllqLv9dehnRjTqhr+l/PekSk7+Gv+KQMPxFq2cwURPM xv0CuXrvxSKM6XDFMu5LRLUWj1H/KrLVroF3NZXl59WnvFZoMyrg5QMLnDsPsVrw V1kMeRmfrjJp2uKwLeMAGPtB06ZcAY534QI8B5qKE9657jDW2oWeQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=pjWarF roiNVDFW+ennFBVf3QjBA6/4HeRm918N3DfJI=; b=a63UsAMMKPDMCaZOMbBc7v 6pa93ngB6S9ZhoYEDiKYdG9ZaSjrO3LTreU2xRD9SB0a/gI8XKv40+AsZBbu6BFw 3SDGDEJ+PKnPNfwnx3Jc/SK6ii9URGLYMZ7xfSuPp/JDrCJwMkuTP+yUmJKf3spp sGzoBRRa8R7Nn+2UktHkeTZPuZqkbEM30nquURoWtiGp8scrzGbbtWInk4BvIBay 4AHO6jjUXfrZgz3Qcab5digGmh4QsAgX5bDFqqdot3PsR4oahMecG2ME9ufHxplJ NaF2trh/f1PJsFE0OAMZbFl+7s0GWVFaHN3AfH+SkD49cz02uReMF7LRirUf4FEw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 06A7C9EB1B; Sun, 17 Sep 2017 20:37:23 -0400 (EDT) Message-Id: <1505695043.1765196.1109187000.6BDEAF89@webmail.messagingengine.com> From: Sam Whited To: "Peter Saint-Andre" Cc: precis@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-64b08692 Date: Sun, 17 Sep 2017 19:37:23 -0500 References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> <1505681506.1709856.1109072624.0D72B3D4@webmail.messagingengine.com> <70293ba4-d48d-fe38-4ea2-cfcb8254978c@stpeter.im> In-Reply-To: <70293ba4-d48d-fe38-4ea2-cfcb8254978c@stpeter.im> Archived-At: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 00:37:26 -0000 On Sun, Sep 17, 2017, at 19:02, Peter Saint-Andre wrote: > First, the Nickname profile is based on the Freeform Class. As we know, > this in itself is a dangerous move. If you want safety and security, you > really really really need to use a profile based on the IdentifierClass. > We have emphasized this many times and it is clearly expressed in the > various PRECIS specs. If we need to add more warning text to 7700bis, > I'd be happy to do that. I think this is clear enough in the current text. The fact that comparisons may fail when I don't expect them to (and that the solution is to require multiple expensive iterations) seems like a more fundamental class of problem to me though, and not one that can be solved by better documenting it. > So I think the scope and implications of the issue you > have raised are much more limited than those we can directly derive from > the Spotify story. I agree that it's less important with the Nickname profile, an issue with a profile that was used as an authentication identifier would be much worse. The Spotify example was intended more to say "we have seen this in the real world, it's not a hypothetical problem" than it was to say "this exact thing might happen again". > Your proposal to scrap NFKC in favor of NFC would actually make things > worse here, because matching would be more lax. As a result, users would > be more confused and attackers could more easily impersonate legitimate > users. Is that what we want? I was under the impression that NFKC was the problem, but that argument makes a lot of sense. > But I'd argue that modifying the normalization rule of the > Nickname profile doesn't really solve the problem, and actually makes it > worse. I think you're right. My apologies if I misunderstood the problem and thought that the solution was to scrap NFKC. There may be other solutions, or a depeer underlying problem (the order of operations of PRECIS itself was brought up, I think?). I don't understand the problem well enough to propose a specific solution, I just can't shake the feeling that having a single profile be non-idempotent will lead to a serious issue that we're not considering. Identifiers created with the nickname profile may not be used for authentication or authorization, but they will be seen by the users and need to be compared in the context of eg. chat rosters, multi-user chat participant lists, etc. and developers, in general, won't read documentation carefully and are prone to taking the path of least resistance; we need to make sure the path of least resistance is secure and doesn't greatly impact performance (another pressure that will push people away from doing the right thing). =E2=80=94Sam From nobody Sun Sep 17 19:56:13 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5BF512EC30 for ; Sun, 17 Sep 2017 19:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=ThYjY2JN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=C5CDLHFq 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 B8vHOgBUBaBP for ; Sun, 17 Sep 2017 19:56:09 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4578126B6E for ; Sun, 17 Sep 2017 19:56:09 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id C799E20852; Sun, 17 Sep 2017 22:56:08 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 17 Sep 2017 22:56:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=UxCbGQ/mdQ2juWl7yB9ju1RUhQTDu5rcZG9pYX8L6 uk=; b=ThYjY2JNmza2t5wAO2cfoKB5qDyAT8LdJZnKsMqZTwFtf95g7KFJVQLtY hN8wGMShoAn5SrD6x1IIWNWGdu2Lc4OoJj5dUKKvM1m7q4FSds9Q3aAmnQHbcJ2d X7c0Lm8hFrecL6Oaxb9FDEqx+YJ/KEsYKWdWNOYL2D1frRI2vZQQ8OWCY3GWw56Q FrtFb039tGiJxiaLnT1lnRXH0k1Gelwcgyg+56wvYxKYbgVd9I8/UT6Cmsr+Re5P 4c8PhARDoQU01F8trcTTk/HfrOxEejiOqqnCLTvxAP7eBQVLYn/4ESx3EJX/l5fa fFQXnxpwsvkVkSn98eX87wRCZCdBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=UxCbGQ/mdQ2juWl7yB 9ju1RUhQTDu5rcZG9pYX8L6uk=; b=C5CDLHFqQkbU0e2Tu5HOlF+Vh14CI0Gokp k6AwDGKdBE0FiVWqF3M65L3qAwq/tD38ChW8iXh33h+KnvrffAsRIZHbntWP7YEg xKwZwXpPGts+BL3MCm6YDeXqbdsWlSh90YisXxmDNYKR26+/fTcsytGFoEsPxJDI emgaEBlrfqF9WHCDOpIFqaRkase0lVBpxS92C0wllvDyEgmFFZxJtFWSAtSvgnbO Fb6ryJ1J7zgTAcNTbDspZIgebnYANN1Xx317Wsmr4GouSRtX0KcvrFeJo9u1ra1J 8MpjI/VIEO4OIuPS1/4cm24l9yhWr67uxIf5O8SQK+vNDjFTWfxw== X-ME-Sender: X-Sasl-enc: GO8j5xs1f/p4MNUIM0yYvfGxKg0aEyFNb3S4dAwbsXaj 1505703368 Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id 1A3CB2460A; Sun, 17 Sep 2017 22:56:08 -0400 (EDT) To: Sam Whited Cc: precis@ietf.org References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> <1505681506.1709856.1109072624.0D72B3D4@webmail.messagingengine.com> <70293ba4-d48d-fe38-4ea2-cfcb8254978c@stpeter.im> <1505695043.1765196.1109187000.6BDEAF89@webmail.messagingengine.com> From: Peter Saint-Andre Message-ID: Date: Sun, 17 Sep 2017 20:56:06 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1505695043.1765196.1109187000.6BDEAF89@webmail.messagingengine.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2PsneeBfr2w0fVHv7QvJ2IFi7ktsfDx4r" Archived-At: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 02:56:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2PsneeBfr2w0fVHv7QvJ2IFi7ktsfDx4r Content-Type: multipart/mixed; boundary="RNKW0dGu7KuqgFXjTHW7fEf0VFDPPiI2j"; protected-headers="v1" From: Peter Saint-Andre To: Sam Whited Cc: precis@ietf.org Message-ID: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> <1505681506.1709856.1109072624.0D72B3D4@webmail.messagingengine.com> <70293ba4-d48d-fe38-4ea2-cfcb8254978c@stpeter.im> <1505695043.1765196.1109187000.6BDEAF89@webmail.messagingengine.com> In-Reply-To: <1505695043.1765196.1109187000.6BDEAF89@webmail.messagingengine.com> --RNKW0dGu7KuqgFXjTHW7fEf0VFDPPiI2j Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 9/17/17 6:37 PM, Sam Whited wrote: > On Sun, Sep 17, 2017, at 19:02, Peter Saint-Andre wrote: >> First, the Nickname profile is based on the Freeform Class. As we know= , >> this in itself is a dangerous move. If you want safety and security, y= ou >> really really really need to use a profile based on the IdentifierClas= s. >> We have emphasized this many times and it is clearly expressed in the >> various PRECIS specs. If we need to add more warning text to 7700bis, >> I'd be happy to do that. >=20 > I think this is clear enough in the current text. The fact that > comparisons may fail when I don't expect them to (and that the solution= > is to require multiple expensive iterations) seems like a more > fundamental class of problem to me though, and not one that can be > solved by better documenting it. Well, we can't get something for nothing. Internationalization as currently designed is expensive in many ways (all those code points to store client-side, computing-intensive normalization required, potential for user confusion, potential for attackers taking advantage of a lack of understanding among developers as in the Spotify story, etc.). The safest approach is to restrict all protocol slots to ASCII. Fortunately or unfortunately, in many applications that is deemed unacceptable these days. However, we don't have to go that far because it's easy to avoid most of the relevant expenses by using a profile based on the IdentifierClass. >> So I think the scope and implications of the issue you >> have raised are much more limited than those we can directly derive fr= om >> the Spotify story. >=20 > I agree that it's less important with the Nickname profile, an issue > with a profile that was used as an authentication identifier would be > much worse. The Spotify example was intended more to say "we have seen > this in the real world, it's not a hypothetical problem" than it was to= > say "this exact thing might happen again". Sure, I understand. As outlined above, there are difficult tradeoffs here. We've tried to thread the needle, but perfection is not an option. >> Your proposal to scrap NFKC in favor of NFC would actually make things= >> worse here, because matching would be more lax. As a result, users wou= ld >> be more confused and attackers could more easily impersonate legitimat= e >> users. Is that what we want? >=20 > I was under the impression that NFKC was the problem, but that argument= > makes a lot of sense. >=20 >> But I'd argue that modifying the normalization rule of the >> Nickname profile doesn't really solve the problem, and actually makes = it >> worse. >=20 > I think you're right. My apologies if I misunderstood the problem and > thought that the solution was to scrap NFKC.=20 No need to apologize. This internationalization stuff is complex in a very messy way. Those darn humans and their langauges... :-) > There may be other > solutions, or a depeer underlying problem (the order of operations of > PRECIS itself was brought up, I think?). It was indeed. That, however, introduces other issues - we might need to introduce versioning for PRECIS because a change that deep would really be PRECIS v2, the existing order of operations was chosen quite carefully years ago and revisiting that decision would mean rethinking a lot of how PRECIS works (e.g., interactions between normalization and width mapping / case mapping) and in the process likely exposing a range of further isses with particular code points or character categories, etc. Not to mention that this working group doesn't have the energy or the authorization (via its charter) to work on PRECIS v2 at this point. The underlying challenge is again the messy complexity of internationalization along multiple dimensions - we've tried to do our best to contain that complexity, but it you push too hard on it from one direction, it comes bulging out in another direction. There are no clean, easy, straightforward answers here. > I don't understand the problem well enough to propose a specific > solution, I just can't shake the feeling that having a single profile b= e > non-idempotent will lead to a serious issue that we're not considering.= I worry about that kind of thing all the time, and not just with internationalization (personally I still wish we had disallowed wildcard certs in RFC 6125, but the consensus wasn't with the authors on that one). But we don't know what the future will bring, and it's difficult to make decisions based on unshakeable feelings of impending doom. > Identifiers created with the nickname profile may not be used for > authentication or authorization, but they will be seen by the users and= > need to be compared in the context of eg. chat rosters, multi-user chat= > participant lists, etc.=20 It's true that a nickname / handle / display name is not a solid basis on which to make authentication or authorization decisions. So don't do that. :-) Should we add a sentence about this to 7700bis? > and developers, in general, won't read > documentation carefully and are prone to taking the path of least > resistance;=20 Sadly, specifications can't solve the problem of developers taking the easy route or not understanding the underlying issues. > we need to make sure the path of least resistance is secure > and doesn't greatly impact performance (another pressure that will push= > people away from doing the right thing). The path of least resistance is using ASCII only. The path of second-least resistance is using the UsernameCaseMapped or UsernameCasePreserved profile of the IdentifierClass, as we do for localparts in XMPP. The path of third-least resistance is using the UsernameCaseMapped or UsernameCasePreserved profile for authentication or authorization, and using the Nickname profile only for user-friendly display purposes in parts of the application or protocol that exist somewhere above that more solid foundation. (Which is exactly what the WG has produced and recommended so far.) Again, if you would like to argue against publishing 7700bis, speak now or forever hold your peace. You'd be going against the consensus of the working group (which, after all, did publish RFC 7700 in 2015), so an Internet-Draft (perhaps entitled "Nickname Profile Considered Harmful") would be the most effective way to make your case. Peter --RNKW0dGu7KuqgFXjTHW7fEf0VFDPPiI2j-- --2PsneeBfr2w0fVHv7QvJ2IFi7ktsfDx4r Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJZvzXGAAoJEOoGpJErxa2pws4QAI0WidLbcxXTX3pwlYi+WuL8 rEH0T9XCoBbFI3X5LPLsCqxnO2gK1qM9O+YJqDa6kDmRFHh8v9XCa0hO4HXuAzTS LbD2+WbDQFYqD49JP/qCos2O+v8ABw+jEAYS+3S6dLIAwRNSZ/+P7s9YizPy+8Pj urbohaPDoM0V90s11oO3+OTifmBS0S9AE5+g7PtmvVMbPPYmhxSG73upiC4OkDEg 2QmO0/N66QMyuc1lnpfmC1adNGEKxTEREBx7+B0PT3fWanVmB/q9HFvNMPjA4SeU Ww7/7gT7L8CeTScOWh60mMamrOnSE7I2AdMqyCu3aIuE3yORj+U/hGbjw5svAajU cM5PCEv8Wq3XOcfnGYwL7nlel0r9MW3AQTSEsq8/WjBMnjJgFZGQU8NbcJvyHTFA xEaBlBDACA7NJiEI8nTqUXcjpziUYiAHh1IYCwA+2hA4NYi77jMoBYORvFcf8wJN i5KWtUkA6ZuaXtaqRg8OpYEeciREzBSorfQbsrgojHwbR8ozDK2IH958o2EJ+Vsh xhu6XpbrsOQFLX5WpZP/mOS7h5mpOUbPUvDeoOuQZhwmADOQtI4vUKUqCmLn9xSo frN5Jzb7mQSawV0hAKePk0seHVPuV93+7KQnomnBtx7DN6NbGxUsBWQBjja/dzV4 qBBkC8JER5PcpIrqiFa/ =gAmB -----END PGP SIGNATURE----- --2PsneeBfr2w0fVHv7QvJ2IFi7ktsfDx4r-- From nobody Sun Sep 17 20:32:29 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DEB1270AB for ; Sun, 17 Sep 2017 20:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=samwhited.com header.b=dMcFNAnI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Z3IWLg67 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 8jt_2VOCZ1jV for ; Sun, 17 Sep 2017 20:32:28 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1735126B6E for ; Sun, 17 Sep 2017 20:32:27 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id F1A0820C1B; Sun, 17 Sep 2017 23:32:26 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Sun, 17 Sep 2017 23:32:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; h=cc:content-transfer-encoding:content-type:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=vmfgysqXNtyc99NmK nb1cFhvUffWM252lJfqE9FCBk0=; b=dMcFNAnILjlXPQWJqMPAfEDJw9RunUd7H xmsSw+F1OUwJFBmkIP4HN2glwfbRfXv9k6Us1+va0rS8YJzr3OxZZZLU/Hw0w8j7 xrDfaypCkyD5ETQMAD454ntpXdW6KLH65VS1uaMoHEJxvSIeMiYa3WW4MlI2rX0V fago/rvWffqT+yrTcJaq8jrjbUZgNKOzjrK3hp1C2mGXsyYup/XfG7mRXiZn8Q2C aN+m7lEQyixXqCSpY9xO2JEdBJm8e++/D2tqhldGLWpRuxet9e3tT84g8GavwMXB LxeBB6WIItBtGLTAD1TpOQa77nMuzNjpL0nL48R+kEfNyLplooUww== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=vmfgys qXNtyc99NmKnb1cFhvUffWM252lJfqE9FCBk0=; b=Z3IWLg67Sh0z4eCIH9Jjz5 7N8dkWCP3Twq0zfQ1Y7m7qbU+2TWTziWJJPOi5xb/I2jPXl6eP0cgSPkW+KXmH/6 0Ohy2CulieecPYjWSZLpXYbbE9dO+Q9PlyzeiV0hYhCMrdTbpgMOsLxgf6xXhPLr Jo5Jflp0n9G/I+ZCrdstI+oB0FDzpLUSKq1CndCiLRGD+FZXYYtnej7sQ82CBTVT UNtl51i5N8w31FO5sy9yfT+AA89P1uECr9d/Gk9atLCjpaZywdXcah9oiPxogzJm hei2QKFzBsnumkX1RdR15ElWEkCzxmB9iEjiFNGxLiQRVUJ1kyrpTh+7rpr9TIPA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C49259EB1B; Sun, 17 Sep 2017 23:32:26 -0400 (EDT) Message-Id: <1505705546.1810302.1109287696.57457A90@webmail.messagingengine.com> From: Sam Whited To: "Peter Saint-Andre" Cc: precis@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-64b08692 References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> <1505681506.1709856.1109072624.0D72B3D4@webmail.messagingengine.com> <70293ba4-d48d-fe38-4ea2-cfcb8254978c@stpeter.im> <1505695043.1765196.1109187000.6BDEAF89@webmail.messagingengine.com> Date: Sun, 17 Sep 2017 22:32:26 -0500 In-Reply-To: Archived-At: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 03:32:29 -0000 On Sun, Sep 17, 2017, at 21:56, Peter Saint-Andre wrote: > It's true that a nickname / handle / display name is not a solid basis > on which to make authentication or authorization decisions. So don't do > that. :-) >=20 > Should we add a sentence about this to 7700bis? I suppose it couldn't hurt, but I'm not sure that it's necessary either. I was not attempting to suggest that the issue was that they would use the nickname profile for authentication, but that misusing it could be an issue in its own right. > Again, if you would like to argue against publishing 7700bis, speak now > or forever hold your peace. That's what I'm doing right now :) > You'd be going against the consensus of the > working group (which, after all, did publish RFC 7700 in 2015), so an > Internet-Draft (perhaps entitled "Nickname Profile Considered Harmful") > would be the most effective way to make your case. I do seem to be the lone dissenter in this matter and since I no longer have a job that allows me the time to work on open source or standards in any serious way outside of the weekends I'm afraid I won't be able to make a better argument than what I've tried (poorly) to present in this email chain. =E2=80=94Sam From nobody Mon Sep 18 06:22:04 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383DA132332 for ; Mon, 18 Sep 2017 06:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=flFO0KuU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ALas1JhK 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 XvOYtAVDttge for ; Mon, 18 Sep 2017 06:22:01 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76232126C7A for ; Mon, 18 Sep 2017 06:22:01 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 6701620D0E; Mon, 18 Sep 2017 09:22:00 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 18 Sep 2017 09:22:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=z7U0Hq1BNPV4Q+DCbaPq7Lcou1RdOuLjEphF27RW3 7s=; b=flFO0KuU4KmAJcybiSJC8jDxLez3kSxwD3TzatPAFYAHb1X71zcpExioo GZV6zAFzmcRDu8bEAtimpkLNOURfps/bydxe4w+fIVYP/P030BSKSfp3/9EoKJ0B 32OKpD4ooRoRFHwCfB73zJoCXnVPq1SLQqOCDGUEBG1ltvLCxlGMLHrmQNs99sZ4 O64BTz3aSw8AxGOs/LS03nmqa4DyKJD4WaMCLJ87/C8bHmNJftiIi3XSSSShVnVg ndLsbxCX3FsH1GGlocW+dZxeK2NcwQJ2I5dbSg/6lfmuIDFcva2mkJOWJSx895AX R6sj3ifg4wcNRf5pgn5aVU/SN/ufQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=z7U0Hq1BNPV4Q+DCba Pq7Lcou1RdOuLjEphF27RW37s=; b=ALas1JhK2V3gYkSOfEDpUP9FlMZ7CRlJwB XL3vR3sH5B3kLNdDnVHFezu1sRxKydnx2zeBji7PGfMW+ZaUwYr0tvtrVScXLn2N kbEqbuSDp0d7UCf+35e6qxntuoxE+jIAoZWcC8bQ9XrpBIYdUurNCG//HpR8ns9F Nwm7utXEHM8fNH9v/dCo94FxuPbpwZznWwIpcqts/42BQo5/Cs/y73bYoat1wBRw Fwlei82oDN+96oxyceaEDSkgOmtp96Nylybh4uDvmR0/eBPhLx44Dp3ihKmPJVPc qzCItH/r8iGbCwNVigg8KWll0DdXV/EujLQmToVa75IVlrOgJ+FA== X-ME-Sender: X-Sasl-enc: olR/BAy6CNf1wNqizUXhuT8zo3AiIB8fEGgUz///o38s 1505740920 Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id C3A9E24640; Mon, 18 Sep 2017 09:21:59 -0400 (EDT) To: Sam Whited Cc: precis@ietf.org References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> <1505681506.1709856.1109072624.0D72B3D4@webmail.messagingengine.com> <70293ba4-d48d-fe38-4ea2-cfcb8254978c@stpeter.im> <1505695043.1765196.1109187000.6BDEAF89@webmail.messagingengine.com> <1505705546.1810302.1109287696.57457A90@webmail.messagingengine.com> From: Peter Saint-Andre Message-ID: <9ff90d8e-d130-0443-d3bd-4964b101f957@stpeter.im> Date: Mon, 18 Sep 2017 07:21:57 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1505705546.1810302.1109287696.57457A90@webmail.messagingengine.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HkSfQeq46DCM8tBCpH5gEpaBJkGSkkuWt" Archived-At: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 13:22:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HkSfQeq46DCM8tBCpH5gEpaBJkGSkkuWt Content-Type: multipart/mixed; boundary="6r46I2NgRrnlw32andGkwvDaioGH3rnuX"; protected-headers="v1" From: Peter Saint-Andre To: Sam Whited Cc: precis@ietf.org Message-ID: <9ff90d8e-d130-0443-d3bd-4964b101f957@stpeter.im> Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> <1505681506.1709856.1109072624.0D72B3D4@webmail.messagingengine.com> <70293ba4-d48d-fe38-4ea2-cfcb8254978c@stpeter.im> <1505695043.1765196.1109187000.6BDEAF89@webmail.messagingengine.com> <1505705546.1810302.1109287696.57457A90@webmail.messagingengine.com> In-Reply-To: <1505705546.1810302.1109287696.57457A90@webmail.messagingengine.com> --6r46I2NgRrnlw32andGkwvDaioGH3rnuX Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 9/17/17 9:32 PM, Sam Whited wrote: > On Sun, Sep 17, 2017, at 21:56, Peter Saint-Andre wrote: >> It's true that a nickname / handle / display name is not a solid basis= >> on which to make authentication or authorization decisions. So don't d= o >> that. :-) >> >> Should we add a sentence about this to 7700bis? >=20 > I suppose it couldn't hurt, but I'm not sure that it's necessary either= =2E I thought about it more overnight and I will look more closely at the security considerations and introduction later today. I do think a sentence or two would help. > I was not attempting to suggest that the issue was that they would use > the nickname profile for authentication, but that misusing it could be > an issue in its own right. The spec as written attempts, via use of NFKC, to prevent the most egregious misuse (as quoted previously in this thread). >> Again, if you would like to argue against publishing 7700bis, speak no= w >> or forever hold your peace. >=20 > That's what I'm doing right now :) Actually you're arguing against the prior publication of RFC 7700, too, which is why IMHO the burden of proof is a bit stronger - that was, after all, a document that had IETF consensus. >> You'd be going against the consensus of the >> working group (which, after all, did publish RFC 7700 in 2015), so an >> Internet-Draft (perhaps entitled "Nickname Profile Considered Harmful"= ) >> would be the most effective way to make your case. >=20 > I do seem to be the lone dissenter in this matter=20 Numbers are unimportant. RFC 7282 discusses this kind of scenario. What matters is the issue, not the person who raises the issue or the number of people who voice agreement. > and since I no longer > have a job that allows me the time to work on open source or standards > in any serious way outside of the weekends I'm afraid I won't be able t= o > make a better argument than what I've tried (poorly) to present in this= > email chain. Communication is a two-way street. I get the sense that I haven't fully understood your concern - it's open to interpretation whether you've poorly presented the argument or I haven't grasped its implications. As I've tried to express, there are legitimate concerns with the Nickname profile or with any profile of the FreeformClass, but as far as I can see we've done everything possible (via use of NFKC etc.) at this stage in the development of internationalization technologies at the IETF to address those concerns (or at least the concerns we've all had for a long time - perhaps you are raising a new concern, which we need to figure out). Until we can get to the bottom of this, I'm going to ask the RFC Editor to "pause the presses" for a few days. I'll try to find time later today to propose a sentence or two that we can add to the introduction or security considerations or both. Peter --6r46I2NgRrnlw32andGkwvDaioGH3rnuX-- --HkSfQeq46DCM8tBCpH5gEpaBJkGSkkuWt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJZv8h2AAoJEOoGpJErxa2plgkP/2kgbCSYv3/hQpD7qsZWQSmw 6fAiTte5JuLeyQ5PuHSShqjHMUTmPI9EXY3/sHY6m7LPNiIawuJvABX9PMvFEUib +swO1eeaPmTT6CqYwg9Upp1vokev34h2ebFmmCRGYPQbLyxYkZpGFjZ2I9ZJu/vA 9c/dyov+uwgSGZy/OhQTXh8XVC3bzyOMytw3WTgIGk0mqJogt7W6y/HiB5arhxq9 RSFGwfzCer7V4isWQvbjjNLfn+ecdvnXBA/uGOaxFlkdQ2paniMLatcXVGgdimvk DARlx5StU2OdVaz1osfbWlm4xYagv+TTfrRn8WLWyHVacvttAwHgei+5H8ln4zf0 y+CT2vacbo8wTYjEyHXrCAlpMbazxeNztE/5tu6bwzg3qlhAQE4nAJbZv3iMWXXh SgjDyrLLYzIWN9XymAgFBWJUN8TOsP2PRkfJ16fAUbZYypgMhBiy45MGvzu7JNH7 KZdPwynOpPMZhZZYVgTT6zmtdiBpcf1HfjGPYWlP+ms/N5KcEBLM2yUYSO7rdsU8 IzntnB2BswapgecsiUZQgCJQr+rwliZKDoTBMhgmugfkEfrWK+PpUG0QqJd5iJjr C1vQa0Sazy3QEjqXV49iDefFnC20yGDfoZGwzviAQ893rgUew9fr/OxtdTBMUOOS U0ABYAbTX2ooUeKH8GmW =jd7y -----END PGP SIGNATURE----- --HkSfQeq46DCM8tBCpH5gEpaBJkGSkkuWt-- From nobody Mon Sep 18 08:10:50 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0436413428D for ; Mon, 18 Sep 2017 08:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=samwhited.com header.b=cbHpbp20; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LDcCi6WW 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 yabPYC_HPuPh for ; Mon, 18 Sep 2017 08:10:46 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CFB51321A2 for ; Mon, 18 Sep 2017 08:10:46 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 98AC3212DD; Mon, 18 Sep 2017 11:10:45 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute4.internal (MEProxy); Mon, 18 Sep 2017 11:10:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; h=cc:content-transfer-encoding:content-type:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=VwUXWCfv9DLSuAa7M 5yiHquDU6a45imJm55/NMRFffs=; b=cbHpbp20m9yvLYrHkEa9w3rHrtWKN1pfw oFHqxhjUg18vJVNs2bBGPYWvvBTYlwIg62lNP1iXgHe8nsr8ZYLGXlsvTHOJm3f+ NQRUYcEqE1+tpuxTqFQHFV9jpzQ7/ICRhunzCq9N2dHjTN4rpdOPDxX9FtT+olWM rlt74mD3+a5SRyooquYYzmjBt+sQfBcybfndwpnKzGDDKEo6V30omeo4g0dsrct2 W4qjL48wdkQlEuQaS8jZ6jXAfVNQoqXGFwjxcYEycHiTNCNCf+rUsWthwRi8FFCM KewhrZBFA+PCD6beU5lwzwh4c/nhNfqwEyR4cW+0IA4gqxXnjOS4w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=VwUXWC fv9DLSuAa7M5yiHquDU6a45imJm55/NMRFffs=; b=LDcCi6WWmzk+/oIy+YWFxM RgTrPJhBDvK2YCim+WEv2UIoGaeibJxZeu/7o01o1jERvT1pEN1tMHKhRAgNhb28 7GsuUrC8ospkRx41A3FtLHY+KpQ5aZhb7chzGFgGJIx2R/BWZj7SyUBFE3lodTYr QVTGspPDBRfC+42mXNNKl5XgYy/Xyp+SEJ8MnLksm1WcNxlq7mDQqRKIrMy4mfUe yfizpzREnXBA5S/UGsuoVaTlH119KjQwYVGfqUusQzz+6j11bcU55LTXNWqX/9zM GKlYV4GOpDch5uh64VRmpz4nwL4/mpiaPNHlvg7dgIYl7od6AnvqyTxiAVnRkCRg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 3900F9E2E6; Mon, 18 Sep 2017 11:10:45 -0400 (EDT) Message-Id: <1505747445.2679629.1109850960.22FF1F11@webmail.messagingengine.com> From: Sam Whited To: "Peter Saint-Andre" Cc: precis@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-64b08692 In-Reply-To: <9ff90d8e-d130-0443-d3bd-4964b101f957@stpeter.im> References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> <1505681506.1709856.1109072624.0D72B3D4@webmail.messagingengine.com> <70293ba4-d48d-fe38-4ea2-cfcb8254978c@stpeter.im> <1505695043.1765196.1109187000.6BDEAF89@webmail.messagingengine.com> <1505705546.1810302.1109287696.57457A90@webmail.messagingengine.com> <9ff90d8e-d130-0443-d3bd-4964b101f957@stpeter.im> Date: Mon, 18 Sep 2017 10:10:45 -0500 Archived-At: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 15:10:49 -0000 On Mon, Sep 18, 2017, at 08:21, Peter Saint-Andre wrote: > Until we can get to the bottom of this, I'm going to ask the RFC Editor > to "pause the presses" for a few days. I'll try to find time later today > to propose a sentence or two that we can add to the introduction or > security considerations or both. Thanks. Let me try again to clarify why the current state of the RFCs makes me so nervous, and why I think the solution isn't as simple as adding more copy: We cannot address every security concern in every RFC. This brute force method (adding a new paragraph to the security considerations section) doesn't scale, and we'll never find all the specific issues. Instead, we have to write standards in such a way that it actively difficult to make a mistake that will lead to a security flaw (not that we shouldn't document any potential gotchas that we can't get rid of, but we should also make them hard to do in the first place). One way we do this is with consistency. Right now, the nickname profile is the *only* profile that is non-idempotent, this is inconsistent. The reason this matters is that most developers won't read the RFC carefully (or possibly, at all). There is nothing we can do about this, and when developers don't read the RFC we should not blame them for the flaws that result. Reading an RFC is a huge amount of work, so naturally most people won't. Instead we need to write specs in such a way that they won't break it if they just look at the examples, or just skim the sections that sound like they're related to what the dev is trying to do.=20 When I implemented PRECIS I did read the core RFC, built tables, added rules, built an API for composing those rules into profiles, and then went to create the profiles. I did *not* read the profile RFCs (until later when reviewing them for this process, but that's not something most devs will do). Instead, I skipped down to the section that listed the rules for enforcement, saw case mapping, width mapping, etc. and threw those the existing transformers I'd written together in the order specified and called it a day. If I had not been on this mailing list I would never have known that the nickname profile was non-idempotent. This is how most developers will probably do things. Adding more text to address security concerns won't help, since they never saw what was there already. If they didn't get the message from X pages of text, they're even less likely to get it from X+n pages. Even if I did notice that the nickname profile is non-idempotent, there are pressures against a correct implementation: multiple passes over the data makes an already expensive operation even more expensive (2=E2=80=933 = times more in the naive case) and it's just more work to do the right thing (whereas it's easy to pass that work onto the application developers using your implementation and assume they'll take care of it and iterate properly). All this means that, by default, the RFCs make it easy to leave the nickname profile non-idempotent (either by mistake, or intentionally due to the pressures against fixing it). The question then becomes: "is that a problem?" In the case of the non-idempotency of the nickname profile, I think the answer is "yes". For a somewhat concrete example, imagine a multi-user chat room. If a user connects and sets their nickname, a single iteration of the nickname profile is run on it, and it *should* match another user in the room but doesn't because of this issue, that user can use the nickname and is allowed into the room. This may be fine, we expect this to happen anyways on occasion because we're using the freeform class. Now, however, the user sends a query to the server that is handled by a third party system; maybe it's a file upload that is delegated to another server which stores the file at /files//myfile. This second application applies the nickname profile again, however, this now makes it identical to the original users nickname (because the fileserver got a nickname that the chat server already enforced) and their files get stored in the same place, meaning the new user whos nickname is slightly different can overwrite the first users files and use that to send malicious files to the original chat participants friends even though as far as the chat system is concerned they are separate users. This is a silly contrived example, and maybe the administrators shouldn't have been using the nickname profile for their filenames in the first place in this case, but any time there are two systems that might both enforce the nickname profile you end up with a possible inconsistency like this, and I'm sure there will be one where it feels perfectly reasonable to use the nickname profile, but where the actual vulnerability comes from the fact that you don't expect the nickname to end up being different between the two systems. Note that in this example that it only matters that the chat server used a broken implementation that did not iterate multiple times, the file server could be using a perfectly correct implementation and the issue would still exist. =E2=80=94Sam From nobody Mon Sep 18 16:18:21 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDA9132F69 for ; Mon, 18 Sep 2017 16:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=EUtlydoP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Xi1bJ/H2 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 OiNJJ5QaYB-7 for ; Mon, 18 Sep 2017 16:18:18 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CFDA132076 for ; Mon, 18 Sep 2017 16:18:17 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 3D1D920BE4; Mon, 18 Sep 2017 19:18:17 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 18 Sep 2017 19:18:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=Z+IGzflgxcEqhpVAcjoX+lbuiO/CmQStIzyn5v7in YE=; b=EUtlydoPRJ9oFFJW9dEm8ydZcQOgCUIOUUai9zra4tywizMFSPGEBvhzi FK4PkVM2MNvhcsZW4+bbzlXVHei9hWExDLU6q33Gv6R99rF2BrOmPXs0WhKMM/3i iuOWLEJdY3M9KZHJir+S1FMrXpCvejcMRDXMruDFrmP26r/IEDn/Xg/PS3zugxUA OOQ1qoryhaqD/MsMq+vswURih8gZHjb7AMvLuc4Gon/dXW1pxiiEf3uMY+7PnEOg UGNeeCo2Vj8zVtG2PYU0veq/TD3Xqam2k6061xu59agJrUbnAZkLnbDyH1cRiNZ6 9eVXQyENjRym3QHYFhbnKObVrZANg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=Z+IGzflgxcEqhpVAcj oX+lbuiO/CmQStIzyn5v7inYE=; b=Xi1bJ/H2IP70XwUeXtxy6cxaohnPRXw9YL uVq8EotFNb3wYG+VkAJgDFx4pEOmxo4CondcCsW2g5Au65KTkqg7e6+Opm585TFa LMip5awD5B0EXFRqeIPNque/CCUoev4iadrmp4iTIWg0o6CPLlqOC1yQcbELXoZc B7IP5i/wB/K9vzNGseNoZvdFGF4XqRBkne4/jXYw5NTFEpYmHOavpEUepc2tlwbu YRE5E9PmM6J4/YpZdsbxKurEYJtlpWpjkf2j1IAflltyCO+xuES2Wwv1+jorc+vw se2IRhgLK4VUH7v9hBliBj5KTf3Fx+5bGXXiHXZRh0DrfaXbnA0Q== X-ME-Sender: X-Sasl-enc: 4G9tEgTxIpydHLUkcty0/yxKl9bYWFInw144ZjeS01be 1505776696 Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id 9D61A7FA73; Mon, 18 Sep 2017 19:18:16 -0400 (EDT) To: Sam Whited Cc: precis@ietf.org References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> <1505681506.1709856.1109072624.0D72B3D4@webmail.messagingengine.com> <70293ba4-d48d-fe38-4ea2-cfcb8254978c@stpeter.im> <1505695043.1765196.1109187000.6BDEAF89@webmail.messagingengine.com> <1505705546.1810302.1109287696.57457A90@webmail.messagingengine.com> <9ff90d8e-d130-0443-d3bd-4964b101f957@stpeter.im> <1505747445.2679629.1109850960.22FF1F11@webmail.messagingengine.com> From: Peter Saint-Andre Message-ID: Date: Mon, 18 Sep 2017 17:18:15 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1505747445.2679629.1109850960.22FF1F11@webmail.messagingengine.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AiXSEBLXCusRgGiQv2mLDNWbIX6fXWEdH" Archived-At: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 23:18:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AiXSEBLXCusRgGiQv2mLDNWbIX6fXWEdH Content-Type: multipart/mixed; boundary="797TbIlqVGPMSFlqQNofHF6xLKFesliPU"; protected-headers="v1" From: Peter Saint-Andre To: Sam Whited Cc: precis@ietf.org Message-ID: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> <1505681506.1709856.1109072624.0D72B3D4@webmail.messagingengine.com> <70293ba4-d48d-fe38-4ea2-cfcb8254978c@stpeter.im> <1505695043.1765196.1109187000.6BDEAF89@webmail.messagingengine.com> <1505705546.1810302.1109287696.57457A90@webmail.messagingengine.com> <9ff90d8e-d130-0443-d3bd-4964b101f957@stpeter.im> <1505747445.2679629.1109850960.22FF1F11@webmail.messagingengine.com> In-Reply-To: <1505747445.2679629.1109850960.22FF1F11@webmail.messagingengine.com> --797TbIlqVGPMSFlqQNofHF6xLKFesliPU Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 9/18/17 9:10 AM, Sam Whited wrote: > On Mon, Sep 18, 2017, at 08:21, Peter Saint-Andre wrote: >> Until we can get to the bottom of this, I'm going to ask the RFC Edito= r >> to "pause the presses" for a few days. I'll try to find time later tod= ay >> to propose a sentence or two that we can add to the introduction or >> security considerations or both. >=20 > Thanks. Let me try again to clarify why the current state of the RFCs > makes me so nervous, and why I think the solution isn't as simple as > adding more copy: >=20 > We cannot address every security concern in every RFC. This brute force= > method (adding a new paragraph to the security considerations section) > doesn't scale, and we'll never find all the specific issues. Instead, w= e > have to write standards in such a way that it actively difficult to mak= e > a mistake that will lead to a security flaw (not that we shouldn't > document any potential gotchas that we can't get rid of, but we should > also make them hard to do in the first place). One way we do this is > with consistency. Right now, the nickname profile is the *only* profile= > that is non-idempotent, this is inconsistent. As previously noted, the only ways I can see to create this consistency would be to (1) change the Nickname profile to use NFC instead of NFKC, thereby introducing even more serious problems or (2) perform major surgery on the order of operations across all PRECIS string classes. Neither of those alternatives is very appealing, and I would argue that they are less appealing than proceeding with what we have right now and in fact did have in 2015 (right now we're just making some minor fixes and corrections to the three RFCs we published then). > The reason this matters is that most developers won't read the RFC > carefully (or possibly, at all). There is nothing we can do about this,= > and when developers don't read the RFC we should not blame them for the= > flaws that result. Reading an RFC is a huge amount of work,=20 Not as much as writing it. ;-) > so naturally > most people won't. Instead we need to write specs in such a way that > they won't break it if they just look at the examples, or just skim the= > sections that sound like they're related to what the dev is trying to > do.=20 The usual response to such an objection is: be a more responsible developer. I know for a fact you're a responsible developer, but this subject matter is, by its nature, difficult, and someone should not expect to skim the examples and write a proper implementation. > When I implemented PRECIS I did read the core RFC, built tables, added > rules, built an API for composing those rules into profiles, and then > went to create the profiles. I did *not* read the profile RFCs (until > later when reviewing them for this process, but that's not something > most devs will do). Instead, I skipped down to the section that listed > the rules for enforcement, saw case mapping, width mapping, etc. and > threw those the existing transformers I'd written together in the order= > specified and called it a day. If I had not been on this mailing list I= > would never have known that the nickname profile was non-idempotent. > This is how most developers will probably do things. Adding more text t= o > address security concerns won't help, since they never saw what was > there already. If they didn't get the message from X pages of text, > they're even less likely to get it from X+n pages. >=20 > Even if I did notice that the nickname profile is non-idempotent, there= > are pressures against a correct implementation: multiple passes over th= e > data makes an already expensive operation even more expensive (2=E2=80=93= 3 times > more in the naive case) and it's just more work to do the right thing > (whereas it's easy to pass that work onto the application developers > using your implementation and assume they'll take care of it and iterat= e > properly). It's always more work to do the right thing. When we published the updated XMPP RFCs in 2010, Alexey Melnikov noticed that we had not updated the internationalization considerations and extracted a promise from me that I would do the right thing. Here we are 7 years later and we're still trying to get PRECIS right. This is more painful for me than it is for you. > All this means that, by default, the RFCs make it easy to leave the > nickname profile non-idempotent (either by mistake, or intentionally du= e > to the pressures against fixing it).=20 Unfortunately we can't solve for developers not reading the specs. > The question then becomes: "is that > a problem?" In the case of the non-idempotency of the nickname profile,= > I think the answer is "yes". But the solutions are even less appealing and the second alternative (starting work PRECIS 2.0) is simply not going to fly right now because it would require rechartering the working group and I sense zero organizational support for that initiative. > For a somewhat concrete example, imagine a multi-user chat room. If a > user connects and sets their nickname, a single iteration of the > nickname profile is run on it, and it *should* match another user in th= e > room but doesn't because of this issue, that user can use the nickname > and is allowed into the room. This may be fine, we expect this to happe= n > anyways on occasion because we're using the freeform class. Now, > however, the user sends a query to the server that is handled by a thir= d > party system; maybe it's a file upload that is delegated to another > server which stores the file at /files//myfile. This second > application applies the nickname profile again, however, this now makes= > it identical to the original users nickname (because the fileserver got= > a nickname that the chat server already enforced) and their files get > stored in the same place, meaning the new user whos nickname is slightl= y > different can overwrite the first users files and use that to send > malicious files to the original chat participants friends even though a= s > far as the chat system is concerned they are separate users. This is a > silly contrived example, and maybe the administrators shouldn't have > been using the nickname profile for their filenames in the first place > in this case, but any time there are two systems that might both enforc= e > the nickname profile you end up with a possible inconsistency like this= , > and I'm sure there will be one where it feels perfectly reasonable to > use the nickname profile, but where the actual vulnerability comes from= > the fact that you don't expect the nickname to end up being different > between the two systems. Note that in this example that it only matters= > that the chat server used a broken implementation that did not iterate > multiple times, the file server could be using a perfectly correct > implementation and the issue would still exist. The file server is making authorization decisions based on a slippery construct that the service operators likely don't understand even as well as the developers (e.g., do they understand right-to-left scripts or the complexities of various symbol code points, or have the tools to administer such things?). I'd call that irresponsible development. Better and safer to use the IdentifierClass or ASCII. If your argument is that RFC 7700 should not have been published, then I really think we're at an impasse because you're arguing against a standards action that had IETF consensus in 2015. Even if you were to launch an appeal against publication of 7700bis at this time, you'd have to argue against the diff from 7700, not the basic concept or approach. Your only avenue is to publish an Internet-Draft requesting that RFC 7700 is harmful to the Internet and should be made Obsolete. Look, Sam, I agree that perhaps someday we can do better, but the level of effort to get there is significant and this working group does't have the energy to do that. Peter --797TbIlqVGPMSFlqQNofHF6xLKFesliPU-- --AiXSEBLXCusRgGiQv2mLDNWbIX6fXWEdH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJZwFQ4AAoJEOoGpJErxa2pgDIQAJu9fUOwNuB5BgE66s+H6n/O k0ddDjrvxOiizDmRz6WbJPXXcMOHaagSZSSa0LawScvXXexVsXiOyrPzTyRgel7/ RhZgTSXFGLOcq/eXz7Hwo2p9z4ozCaNw8Y2AjukC8xTa0HXxidAAaohnlLcs2Bie 8wu3P4sknVBcBc9J379Q5VBaySJej+5xHoPfUFV9vZZZFr9/wh7c9Bc+M5ulezTS tf/K3To6MYKSb9cQZw/rk4R6z8y7EU5M2gAdvAS7P58VCoL39TG9E3kHc0ZJeCXD BsVTvwldto4k1NXyfidJznzAnhflFw7go6n8tIlYZg5YpEbt8gJLK4Jibo1dhAgZ 5GWc32Tt1QEUUff1MvSH06wLrcBnTKLggNp17SH+I46N+XbSGPEhtPE0Ziq4sHxR LksTOHJdL1Fh+Bc1qxqTT2vQzZnxeTPgTAfkg8ktbC/Z8UKwoQISc8OuDpb+ugep cF0V33s2hGaM8nf0CbchVTB8LObdfzB0NMcLAg1YfvS0oh9Fcea4xcNHqprC9pVP DDmVLHJyY6vHmhtcbPh5xB6vN0Jt0bEkVH+ftncKWn9lm6Z+7cCT2/DRmXJmup8T 450vqf63F1z7PbaJgrFIEVcT4KPKRLAxfv935aXTaSqj69pkYS9yYjzIUpDyV/B8 vePLN5bRTvzWu6uoCC1g =AJ7T -----END PGP SIGNATURE----- --AiXSEBLXCusRgGiQv2mLDNWbIX6fXWEdH-- From nobody Mon Sep 18 17:24:10 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1584D133338 for ; Mon, 18 Sep 2017 17:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=samwhited.com header.b=dhedCyq4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=E04IFtfp 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 kwiighRfrVAJ for ; Mon, 18 Sep 2017 17:24:07 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEBD71332CA for ; Mon, 18 Sep 2017 17:24:06 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 3309620D92; Mon, 18 Sep 2017 20:24:06 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Mon, 18 Sep 2017 20:24:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; h=cc:content-transfer-encoding:content-type:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=rqwu6w98PMheiXJFh BNRspLxU9A8t+dJ0YIhVHaaeDs=; b=dhedCyq4HKRWW2QCE2COrlwpu5M67Rsmw HICIv2j9xgiqSFam9Yqivklf4n+rNyPRvgOGwM46V7dPJmF1XpFagrZJFoBP6+Fs EtS+A5OPufJdqJJ5zLJCxl+r/YDLlIXVfQq+tkXP1aEt84pec4+fwqItbo628l6O V81AdxAsPgzMwWxQtynUI5qmS76UsnjqkQoOHSvaQ2DLg84ydk/YUrUYYYDDIs9T pAi5YyePgiQ/Vu4y5Q/R2l0OJwYOj1krCW94AOvdtRv/dQFd+1WIq42mnq+8W+fj GOGKZtDOwhVwj4nt/d6NgpAmvmaeJOO0YPQtPnU3UpuNN9GSTEGOg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=rqwu6w 98PMheiXJFhBNRspLxU9A8t+dJ0YIhVHaaeDs=; b=E04IFtfpU0yxwnV6DZ/0oL SbETCsb1iBEWs2FiuzwyeFcWkVcNI6Lp+YIZnsPMjyK2Ifg1gEm69SiYE7TbNOgF pOqPK8JUy3V76kK6OmAk6bg6JGcZnU7JnOHaw2zbz1jD/E+JaCHXyLx6gfh3QkRq YGnAf4lFQwZAvFyP+0nCVX4iPVbbJKGSaK9ucxVVafRs4EO+b+j19e2n63ceRgsM fSkYRJXk+pagJKgmo4rZTaBIIReq/BY0IatISyijw6BD7dCtCkXurmi5bgeWEzQ7 3zqzxEq1BRgY5+XrzgVu4JpgcuIH25IQ5VJfZwi8PNjtD/TDdcDYEeYnf6ajXaQA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 0C00D9EA18; Mon, 18 Sep 2017 20:24:06 -0400 (EDT) Message-Id: <1505780645.635715.1110496432.321E4052@webmail.messagingengine.com> From: Sam Whited To: "Peter Saint-Andre" Cc: precis@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-64b08692 In-Reply-To: Date: Mon, 18 Sep 2017 19:24:05 -0500 References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> <1505681506.1709856.1109072624.0D72B3D4@webmail.messagingengine.com> <70293ba4-d48d-fe38-4ea2-cfcb8254978c@stpeter.im> <1505695043.1765196.1109187000.6BDEAF89@webmail.messagingengine.com> <1505705546.1810302.1109287696.57457A90@webmail.messagingengine.com> <9ff90d8e-d130-0443-d3bd-4964b101f957@stpeter.im> <1505747445.2679629.1109850960.22FF1F11@webmail.messagingengine.com> Archived-At: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 00:24:08 -0000 On Mon, Sep 18, 2017, at 18:18, Peter Saint-Andre wrote: > Look, Sam, I agree that perhaps someday we can do better, but the level > of effort to get there is significant and this working group does't have > the energy to do that. If there's no energy to make the change then I don't see any reason to continue this discussion. It sounds like I'm disagreeing with something that's fundamental to the construction of PRECIS, so if the change isn't going to be made either way there's no point in holding publication of the current drafts. Thanks for discussing it and helping me understand the problem more fully. =E2=80=94Sam From nobody Tue Sep 19 04:40:15 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25367134215 for ; Tue, 19 Sep 2017 04:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPBrglAj970c for ; Tue, 19 Sep 2017 04:40:10 -0700 (PDT) Received: from cheri.viagenie.ca (cheri.viagenie.ca [IPv6:2620:0:230:8000::48]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78E43134210 for ; Tue, 19 Sep 2017 04:40:10 -0700 (PDT) Received: from [206.123.31.198] (h198.viagenie.ca [206.123.31.198]) by cheri.viagenie.ca (Postfix) with ESMTPSA id 89E1510ABE1; Tue, 19 Sep 2017 07:40:09 -0400 (EDT) From: "Marc Blanchet" To: "Sam Whited" Cc: "Peter Saint-Andre" , precis@ietf.org Date: Tue, 19 Sep 2017 07:40:09 -0400 Message-ID: <887649CA-B708-4A05-948D-9993F38CB652@viagenie.ca> In-Reply-To: <1505780645.635715.1110496432.321E4052@webmail.messagingengine.com> References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> <1505681506.1709856.1109072624.0D72B3D4@webmail.messagingengine.com> <70293ba4-d48d-fe38-4ea2-cfcb8254978c@stpeter.im> <1505695043.1765196.1109187000.6BDEAF89@webmail.messagingengine.com> <1505705546.1810302.1109287696.57457A90@webmail.messagingengine.com> <9ff90d8e-d130-0443-d3bd-4964b101f957@stpeter.im> <1505747445.2679629.1109850960.22FF1F11@webmail.messagingengine.com> <1505780645.635715.1110496432.321E4052@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.7r5412) Archived-At: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 11:40:14 -0000 On 18 Sep 2017, at 20:24, Sam Whited wrote: > On Mon, Sep 18, 2017, at 18:18, Peter Saint-Andre wrote: >> Look, Sam, I agree that perhaps someday we can do better, but the >> level >> of effort to get there is significant and this working group does't >> have >> the energy to do that. > > If there's no energy to make the change then I don't see any reason to > continue this discussion. It sounds like I'm disagreeing with > something > that's fundamental to the construction of PRECIS, so if the change > isn't > going to be made either way there's no point in holding publication of > the current drafts. That is also my conclusion. You have raised good points, some were discussed before, but if the end resolution is to redesign precis (such as changing the normalization form which is a major redesign), then I think we shall proceed with the publication and then some people like you can start another round of revisions of the documents. As you may know, the first iteration of this work was called Stringprep (RFC3454), then we moved to the new IDNA framework based on Unicode rules which led into Precis. At the time of Stringprep, we already knew some of its weaknesses. Neither Stringprep or Precis is perfect. So I encourage you to write a proposal and submit it as internet-draft (and advertise it to this mailing list). Marc. > > Thanks for discussing it and helping me understand the problem more > fully. > > —Sam > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis From nobody Tue Sep 19 08:40:02 2017 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5309B134292 for ; Tue, 19 Sep 2017 08:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=j+wDNFZe; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VZzx98D6 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 TlLzE1S-P09P for ; Tue, 19 Sep 2017 08:39:59 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24FB3133020 for ; Tue, 19 Sep 2017 08:39:58 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 5AA75213F5; Tue, 19 Sep 2017 11:39:58 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 19 Sep 2017 11:39:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=4Pw4+tHRS96gfIdWmlcKY3e6GcZxUdYz0lbsdmLag dE=; b=j+wDNFZe/La0G785DGtjzGrAKEtnOnCdtOa5+hXXLFd2kABN4wocc4HD0 hSgFZm2b4P4IyPtdiAuWcoV3c/uBqDEX4h8jwyIREFS2SslzCSTMGAG8nLFyr4o+ +hey/ydJTpYsLipHnmvXExOmt/zeZ2WnQPrFSOFOkQDQFJ9CYorEP/ICp/8l26HQ NKP/CD+qmu0i2DOh6HbMHCVpzFv8JgCQoSfJewe+TCDxY55To1W7qD0TSpj5VU1L qDfYUrYSOPsU3B7TKniOLKoiWV25A4Ru2b0Ii7DVLsjWadzXIyxGzPG3G2f4kFlj UayzSexM/Jwe9ZrwM8wtSGS0djrqQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=4Pw4+tHRS96gfIdWml cKY3e6GcZxUdYz0lbsdmLagdE=; b=VZzx98D68GDnTfePOEvGXbJlZtwIgkdQEz oL0WPPdPvY7heTDnnvoIA4/AeC76C8DEWG+2OxnwF+pragsBXm1Dk8oQlILhRh8z D7zFNsS7kau/c7J32LJEOwuF8hVqllJgpO5mq1cSglhloRlLQR8ZLTQI/uoFbNP+ ASw37ErEy4Ql9BwpEhyreT1kyAb1yfLXWfhbD7WoKxf/D9RiHMEOaOLbAhxYp0Pu MA5H1Q9XcrtVPrfw6UMTqXRsVhVrbSdBK8+w34RrONkZ2Nbi6S+PM4ZkBoYoRD8V iMNOVuspvxppvg4k4dQafhhEoOlj17nK6qrvQTsMIEsAJhET9Slw== X-ME-Sender: X-Sasl-enc: HYjhq6Xklkck9ji412t/nvAmizJ480Cmn4mfA8BzdsjE 1505835597 Received: from aither.local (107-1-214-226-ip-static.hfc.comcastbusiness.net [107.1.214.226]) by mail.messagingengine.com (Postfix) with ESMTPA id B97F87FA6B; Tue, 19 Sep 2017 11:39:57 -0400 (EDT) From: Peter Saint-Andre To: Sam Whited Cc: precis@ietf.org References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> <1505681506.1709856.1109072624.0D72B3D4@webmail.messagingengine.com> <70293ba4-d48d-fe38-4ea2-cfcb8254978c@stpeter.im> <1505695043.1765196.1109187000.6BDEAF89@webmail.messagingengine.com> <1505705546.1810302.1109287696.57457A90@webmail.messagingengine.com> <9ff90d8e-d130-0443-d3bd-4964b101f957@stpeter.im> Message-ID: Date: Tue, 19 Sep 2017 09:39:55 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <9ff90d8e-d130-0443-d3bd-4964b101f957@stpeter.im> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="igDNTQOimaBSCi7orMUOtfH1MeG3B9wIF" Archived-At: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 15:40:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --igDNTQOimaBSCi7orMUOtfH1MeG3B9wIF Content-Type: multipart/mixed; boundary="550J6Ua85iRSqtivCGEaVk8f7mGgaL8Ti"; protected-headers="v1" From: Peter Saint-Andre To: Sam Whited Cc: precis@ietf.org Message-ID: Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt References: <150024725625.303.17137036571104960991@ietfa.amsl.com> <33f7468c-6742-7cbe-fa6f-70002c35cc62@stpeter.im> <1504880015.1561911.1099626960.6CB0430C@webmail.messagingengine.com> <1505397979.578298.1106052760.03A5025F@webmail.messagingengine.com> <0fc31e75-7893-c982-30b4-a6fe4ecae5fb@stpeter.im> <1505675616.1686212.1109016016.7A9E7FFE@webmail.messagingengine.com> <1505681506.1709856.1109072624.0D72B3D4@webmail.messagingengine.com> <70293ba4-d48d-fe38-4ea2-cfcb8254978c@stpeter.im> <1505695043.1765196.1109187000.6BDEAF89@webmail.messagingengine.com> <1505705546.1810302.1109287696.57457A90@webmail.messagingengine.com> <9ff90d8e-d130-0443-d3bd-4964b101f957@stpeter.im> In-Reply-To: <9ff90d8e-d130-0443-d3bd-4964b101f957@stpeter.im> --550J6Ua85iRSqtivCGEaVk8f7mGgaL8Ti Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 9/18/17 7:21 AM, Peter Saint-Andre wrote: > On 9/17/17 9:32 PM, Sam Whited wrote: >> On Sun, Sep 17, 2017, at 21:56, Peter Saint-Andre wrote: >>> It's true that a nickname / handle / display name is not a solid basi= s >>> on which to make authentication or authorization decisions. So don't = do >>> that. :-) >>> >>> Should we add a sentence about this to 7700bis? >> >> I suppose it couldn't hurt, but I'm not sure that it's necessary eithe= r. >=20 > I thought about it more overnight and I will look more closely at the > security considerations and introduction later today. I do think a > sentence or two would help. Here is some proposed text to address part of Sam's concern. First, in the Introduction... OLD The rules specified in this document can be applied in all of the foregoing contexts. To increase the likelihood that memorable, human-friendly names will work in ways that make sense for typical users throughout the world, this document defines rules for handling nicknames in terms of the preparation, enforcement, and comparison of internationalized strings (PRECIS) framework specification [RFC8264]. NEW The rules specified in this document can be applied in all of the foregoing contexts. It is important to understand that a nickname is a personally memorable name or handle for something that has a more stable, underlying identity, such as a URI or a file path. To ensure secure operation of applications that use nicknames, authentication and authorization decisions MUST be made on the basis of the thing's identity, not its nickname. To increase the likelihood that memorable, human-friendly names will work in ways that make sense for typical users throughout the world, this document defines rules for handling nicknames in terms of the preparation, enforcement, and comparison of internationalized strings (PRECIS) framework specification [RFC8264]. Second, we might repeat that paragraph in a new subsection of the Security Considerations, too. Third, I suggest that we move the following paragraph from the end of Section 4 to the end of Section 2.1: Implementation experience has shown that applying the rules for the Nickname profile is not an idempotent procedure for all code points. Therefore, an implementation SHOULD apply the rules repeatedly until the output string is stable; if the output string does not stabilize after reapplying the rules three (3) additional times after the first application, the implementation SHOULD terminate application of the rules and reject the input string as invalid. Peter --550J6Ua85iRSqtivCGEaVk8f7mGgaL8Ti-- --igDNTQOimaBSCi7orMUOtfH1MeG3B9wIF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJZwTpLAAoJEOoGpJErxa2pXv8QAK7S9c7amTMKOBl/Ev5fOsrJ zvcQ302RHZpCOGea9WkRaZ+HZUtAlfMNpDEX9xPASKoVJZVZ0m/0kcVX7O5qjn2R pfkKkoAKSoEi7Wh3RTIGN3T/hwvzo/laX3+JDOa3LWNOw/XTFUQNQiii9FPYHff0 8TTIkaIaBW8niK19K43FXyELJ8E/6GVqcFjulyVkB5iaNB3dPjSzpeZrRXjI8mRv RYQre6BjFsrXzDMNtPemujcLXJJ/wavj999qZKfZ76Os4e5x3XitGOTrwHDWU1nd iqL+wqBMeopjnZSdngsZjBdUHUYKgPpnsheaijgbsM3xJ4MDB/QJPlLOVTROooky /HT1LdjEplqr/a98XXJQHVay9MmDXM+Iban9/aoWXSFZEkQhywOASb6FXtnLXltP inUBCpIv5VSVaSm08h2XeLuATER5FYQLkWcik4uE4RtzR8eK2hUJZG48IVvjleqg nWbGQbJGH1uwdjNtT7x63nNNY7EYry+zzcjAloqYCccQ36RZnbDH3D3wVkdrlEh+ pvqh7X52E8m+HOzqda/7UQom1ZIWharkvwsm1/3yO9IxpVZurn94nRlLz0e+10+C lsGBo/PzfAOzpETDMNxXJMzRVlPIYc+98X5xvxH84sbVgQtIsPj8fpn1xbAN92Qb ejfloPNP/zU/gF4lvuYf =kkVZ -----END PGP SIGNATURE----- --igDNTQOimaBSCi7orMUOtfH1MeG3B9wIF-- From nobody Fri Sep 29 06:04:59 2017 Return-Path: X-Original-To: precis@ietf.org Delivered-To: precis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 642D413451A; Fri, 29 Sep 2017 06:04:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: alexey.melnikov@isode.com, precis-chairs@ietf.org, precis@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150669029640.13976.14135634371371460228.idtracker@ietfa.amsl.com> Date: Fri, 29 Sep 2017 06:04:56 -0700 Archived-At: Subject: [precis] precis - Not having a session at IETF 100 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 13:04:56 -0000 Alexey Melnikov, a chair of the precis working group, indicated that the precis working group does not plan to hold a session at IETF 100. This message was generated and sent by the IETF Meeting Session Request Tool.