Re: NF* (Re: PKCS#11 URI slot attributes & last call)

Patrik Fältström <paf@frobbit.se> Wed, 31 December 2014 07:54 UTC

Return-Path: <paf@frobbit.se>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904F11A8A9E; Tue, 30 Dec 2014 23:54:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.261
X-Spam-Level:
X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 6-eF_NcB7iVG; Tue, 30 Dec 2014 23:54:02 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 754AF1A8A9D; Tue, 30 Dec 2014 23:54:02 -0800 (PST)
Received: from [192.168.1.84] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id 20A722026F; Wed, 31 Dec 2014 08:54:01 +0100 (CET)
Subject: Re: NF* (Re: PKCS#11 URI slot attributes & last call)
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Content-Type: multipart/signed; boundary="Apple-Mail=_235D3920-0E8C-435A-B65C-DEF6018F1E1D"; protocol="application/pgp-signature"; micalg=pgp-sha1
X-Pgp-Agent: GPGMail 2.5b4
From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <paf@frobbit.se>
In-Reply-To: <20141231074641.GM24442@localhost>
Date: Wed, 31 Dec 2014 08:54:00 +0100
Message-Id: <947CA101-D717-4B56-8EEE-84B3A53BF4A1@frobbit.se>
References: <20141217230150.GB9443@localhost> <alpine.GSO.2.00.1412171513520.4549@keflavik> <CAK3OfOjnRCmiu-TKCJ-AFanpCsqnw1o2w_EC2AKMUnQ2A4DqVw@mail.gmail.com> <alpine.GSO.2.00.1412292234010.1509@keflavik> <CAK3OfOgm_ZYj-rY+4ExZzY8KY4G3rz2KLrZ8hQJi7ZUR4yiP0Q@mail.gmail.com> <alpine.GSO.2.00.1412300946340.4549@keflavik> <CAK3OfOha9qu=uDtqwDTdV78waLMaorYq0T6cq1YX3VzQn2OpKA@mail.gmail.com> <A4CC6CEC-D17E-4235-B615-9D2AD88096D4@frobbit.se> <20141231070328.GK24442@localhost> <B08B813F-B8B4-49F1-A0B9-60F322C8E9C7@frobbit.se> <20141231074641.GM24442@localhost>
To: Nico Williams <nico@cryptonector.com>
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/vGPsEOVKnxtKHE7L14GTE5BDbk0
Cc: Darren J Moffat <Darren.Moffat@oracle.com>, "saag@ietf.org" <saag@ietf.org>, Jan Pechanec <jan.pechanec@oracle.com>, "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Dec 2014 07:54:06 -0000

> On 31 dec 2014, at 08:46, Nico Williams <nico@cryptonector.com> wrote:
> 
> The NFD case is obnoxious because even on those systems the input system
> tends to produce NFC...  But anyways.  When you have no canonical form
> for whatever reason, you can try form-insensitive matching.

Ok, got it (and yes, I have been bitten myself a few times on the NFD issues with HFS+).

What I think is then needed is for this case:

1. A simple explanation what you really is talking about

What is the requirement on whom regarding normalization/mapping/whatever?

2. An evaluation whether the choice is the right one or not

The tricky part regarding choice of normalization (together with selection of code points allowed) is of course whether false positives or false negatives is the most troublesome event when trying to do matching.

I.e. say that matching algorithm is not defined. Is there a larger risk you will get false positives, and because of that possible attacks using some kind of "hamming-distance"/"homograph" (based on normalization)? Or rather, a description must be part of the security considerations section to explain what should not be done to not increase the risk for such attacks.


Let me just be clear here, I am very much in favor of specifications that say that "server side matching" should NOT do normalization, as that give most freedom for the applications that use whatever mechanism is defined. But, that to me set requirements on "client side" to do the right thing (for example like in IDNA2008 only be allowed to use certain code points).

So, given your choice on server side matching, what are the requirements on client side?

   Patrik