Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt

Sam Whited <> Thu, 20 July 2017 04:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AAB5E12EC51 for <>; Wed, 19 Jul 2017 21:45:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id txHkV0LKB-UZ for <>; Wed, 19 Jul 2017 21:45:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4F1E6126D85 for <>; Wed, 19 Jul 2017 21:45:38 -0700 (PDT)
Received: by with SMTP id x6so1451558ywd.1 for <>; Wed, 19 Jul 2017 21:45:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=swgoo; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=aTeM8uLkJMGr5eOWp/GVTcxUT23JsvZzErO8Mchn9WQ=; b=gBDHdcoIrw0RIvptFCBEcxh8gv4jTLDhDnmvu3Tgj78ctuqRvUjAaQkPQqNIwHsW3t CXdaX2j1DG4IxgQUpzIykoYvcNFtQYDnEQwkxM+BZI7qC/IqRM9HpFvBu8NH+nluNSVY AyI9In2IAqNMjAey3PACh0FwmQXKlz5kUUEzg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=aTeM8uLkJMGr5eOWp/GVTcxUT23JsvZzErO8Mchn9WQ=; b=K+PnAKNRzIxPOS05Q4pAiUGHdA8ig48sF0NuPcxET8GjhBklrceRe4feapzgbNhP2Z 2bV330XQVVdm+K32f07PfbmHbFoWipJb+NeK75E0NVqEmmlSGiFBBN1cwwngYLM9gSqR DhvywkcXCqiY+fMW3ioUhQIy23SwvTgvyCD0U54pb0crtrqwXjUFGACdtaOekB96bYrS vRlnXDC4dRUGxtQNLIIXXQOAE1xHQiHBrw+LihMjIvimjjNz261B3/OjMYKg7zla9DuQ Lq4YJ5M2/QDteCCbbStErp+ScapGgewE6n9X4Ie8ApxVOYyCLFTxSDfyO5QOKSy4j0Wh AUkA==
X-Gm-Message-State: AIVw111j25jzywBYN84Q5C5rgimmfVGlncl45hODq4+GL3ZfmWwZ5Xwt 3TlmjM2BSojLjlptQfllPRC9HxjYQnAdFsg=
X-Received: by with SMTP id i127mr2041642ywe.452.1500525937341; Wed, 19 Jul 2017 21:45:37 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 19 Jul 2017 21:44:56 -0700 (PDT)
X-Originating-IP: [2605:a601:1167:d300:1455:9f38:5fe6:12ef]
In-Reply-To: <>
References: <> <>
From: Sam Whited <>
Date: Wed, 19 Jul 2017 23:44:56 -0500
Message-ID: <>
To: Peter Saint-Andre <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt
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, 20 Jul 2017 04:45:40 -0000

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.

For now we've avoided dealing with this in the Go implementation by
documenting that the nickname profile (which I think is the only
profile to suffer from this right now?) is not idempotent and passing
the requirement to iterate on to the users (application developers
using the library).
However, I suspect many of them will not read the warning in the docs
and will apply the profile once, which may be a security concern.
Because we can't be absolutely sure (or can we?) that a string will
stabilize after any given number of iterations or that the number of
required iterations won't change in the future as new characters are
added, and because this introduces a tradeoff that must be made
between performance and correctness, I think that idempotency should
be a requirement for all standardized PRECIS profiles.
However, I understand that this is a large change that may not be
possible to make this late in the game.

I don't think we'll special case the nickname profile to to make it
run multiple times in our implementation, but I'm also not sure what
we'll end up doing. It may be that we roll our own profile for
nicknames and break compatibility with other libraries (although this
is obviously not desired), or we may not support the nickname profile
at all and leave it up to application developers to implement if they
need it, or we may simply leave a big scary warning in the
documentation. None of the options sound appealing.