Re: [precis] Enforcement as an Idempotent operation

William Fisher <william.w.fisher@gmail.com> Wed, 19 April 2017 21:37 UTC

Return-Path: <william.w.fisher@gmail.com>
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 16AE3128B37 for <precis@ietfa.amsl.com>; Wed, 19 Apr 2017 14:37:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 szYg1eP9-iwv for <precis@ietfa.amsl.com>; Wed, 19 Apr 2017 14:37:21 -0700 (PDT)
Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5820F128799 for <precis@ietf.org>; Wed, 19 Apr 2017 14:37:21 -0700 (PDT)
Received: by mail-io0-x236.google.com with SMTP id a103so39240438ioj.1 for <precis@ietf.org>; Wed, 19 Apr 2017 14:37:21 -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=/LOTt941wSkP45OyZt1ljouv2eJTMqQ2ypS4ys/+Kr8=; b=sWRdNR8ig1QJCkJCNzrx/yf6FiCPRGZLUZKwY11xim6HMTwUa5IXA5LeGJ5SjdctM9 D8C6ZehEJBr8ddiwg0FiC7QBPxTcKVuMzqxZI4qiRDBku/W4eSrC++SEJoVoYcaTTlhe GAt0YDtWXjivxnXM8HP5qCrgtRf5KqRoUhIzD1onTZoBOd0bkyoR+R+9IaXCRMv9kgrU JpIkr4LgN1d1Tks92vg1e0iNzrB3HCuv+8eGJ3j1EgvJqH1wLpkAL7QA4cdLWr8hQKiJ vVPMxLBUIIB6mqHvljps6+kPvV3Rq97PzuZGjMfNrQig/Wn3/qWbJe9Bl4Ree6+UGpfy DCbg==
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=/LOTt941wSkP45OyZt1ljouv2eJTMqQ2ypS4ys/+Kr8=; b=I3B/2xNY3kuydiUQy0mECEvL8ZvBBDzUa1705xDU9hUO+SrTW8p1CfH4uw6pIfI9VU tkr2nIeCUNBVXH4uiSYoxbn4oSw3eU6mx4UuFeZshd52q6XnYOTcunznDeAwz2YROHDI PNjpl9DEVuOcxrs8KfHDxd1aLwDdzeMltaZJe3LJMbEjB3jXIzlRJjv95U14vd4N94PW xeCL0BikHUrj76h3kAl02w8RQICFGPOG+wiylhS3SZgMXbTrk9s1Aabf5xpVaJKYXfj1 IpvoWmiX/WVPTng/f+2OhsIbi/k9dOO+3B3WXqPgOic94Qvi497Sa5ydvsSJ/4N/SHS2 jxmw==
X-Gm-Message-State: AN3rC/6FI1kxYf6htgaZABGyQ7U6djCwOhkIojTBL6BLKQFyRsXqfrpq TU+6qR3obSXxvuIuQ4tXtfW3GF3tgg==
X-Received: by 10.107.58.197 with SMTP id h188mr5511709ioa.221.1492637840306; Wed, 19 Apr 2017 14:37:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.12.13 with HTTP; Wed, 19 Apr 2017 14:37:19 -0700 (PDT)
In-Reply-To: <CAHbk4RLm=h08Dku7A1wjRv5Zho=vGXsK1vR=dxuKSiWktsMM2Q@mail.gmail.com>
References: <CAHVjMKHVvmS6jty3-jwnnuqy-xdw-xY2j+5ExLRr6tXCMRbC2Q@mail.gmail.com> <f9b49a96-2189-bccd-5dc0-a4dc8146cbcc@stpeter.im> <CAHVjMKEVTOCV68OTfXnXhWKiXT798m2osGkwHVRhw4Cs0RLw0w@mail.gmail.com> <15c31273-c278-af61-2a01-0b68ab8af182@stpeter.im> <CAHVjMKHXL_gHrQ1+jC2T4VrJj5n+mRB5j7iD7kGHc06wpq+PEA@mail.gmail.com> <0f5b55f8-5fcb-2a61-435e-7b93d2d8f9e6@stpeter.im> <6df28263-cdfa-cc61-4ba9-1bdae17bcca8@stpeter.im> <CAHbk4RLm=h08Dku7A1wjRv5Zho=vGXsK1vR=dxuKSiWktsMM2Q@mail.gmail.com>
From: William Fisher <william.w.fisher@gmail.com>
Date: Wed, 19 Apr 2017 14:37:19 -0700
Message-ID: <CAHVjMKEFcLc58Z2i+Mubuzd8UAy4MYyFBt__LzuOa5h74G618g@mail.gmail.com>
To: Sam Whited <sam@samwhited.com>
Cc: Peter Saint-Andre <stpeter@stpeter.im>, precis@ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/precis/6YkLfHxSBeKbNy3nIxHPvtFGcsE>
Subject: Re: [precis] Enforcement as an Idempotent operation
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Preparation and Comparison of Internationalized Strings <precis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/precis>, <mailto:precis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/precis/>
List-Post: <mailto:precis@ietf.org>
List-Help: <mailto:precis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/precis>, <mailto:precis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Apr 2017 21:37:23 -0000

An alternative is to treat finalization as an application/protocol
responsibility. RFC 7564 section 6.2. "Further Excluded Characters"
can be interpreted as allowing a protocol to post-process PRECIS
output, just like section 6.3. "Building Application-Layer Constructs"
allows pre-processing input before passing it to PRECIS.

PRECIS is the recommended whitelist ("inclusion model"). A
protocol/application can still blacklist specific inputs, which may
include "fixing" non-idempotent results.

-Bill


On Wed, Apr 19, 2017 at 8:35 AM, Sam Whited <sam@samwhited.com> wrote:
> On Tue, Mar 21, 2017 at 8:30 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
>> Thinking about this further, I now lean against making this change in
>> the PRECIS processing rules, for several reasons:
>
> Sorry for dragging this back up again, but I ran into this for the
> first time "in the real world" recently (a comprison using the
> nickname profile that was unexpectedly failing in a non-obvious way)
> and wanted to weigh in:
>
> With the nickname profile in particular this might not be that big of
> a deal, but other as-yet-unthought-of future security focused profiles
> may need to use NFKC for some handwavey reason (although if they are
> security focused they probaly shouldn't be using NFKC, but let's
> assume that they have too), but may need to be idempotent for security
> reasons. It is currently not possible (as far as I can tell) to create
> a profile that both uses NFKC, and is idempotent. I know we don't want
> to encourage profile proliferation, but I suspect at some point
> someone will have a valid reason to write a new profile, so future
> proofing would be nice.
>
> Maybe it would be beneficial to add a new step to the PRECIS framework
> (with the understanding that current profiles just don't have this
> step, making them backwards compatible), a "finalization mapping"
> step: this could be used to eg. run the additional mapping rule a
> second time, run normalization again, or just perform specific known
> mappings that fix edge cases. I'm not sure how generally useful it
> would be, or if it would just be a huge change for relatively little
> benefit (or maybe it would even be an actively bad thing somehow?);
> just a thought.
>
> Best,
> Sam