Re: [precis] rationale of rfc7613 decisions

Peter Saint-Andre <stpeter@stpeter.im> Fri, 31 March 2017 01:45 UTC

Return-Path: <stpeter@stpeter.im>
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 1BB84129444 for <precis@ietfa.amsl.com>; Thu, 30 Mar 2017 18:45:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 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, URIBL_BLOCKED=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=k2y1Tsys; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=N6VJ/ohV
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 sXWxqGrWLtoS for <precis@ietfa.amsl.com>; Thu, 30 Mar 2017 18:45:10 -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 CB9AC1286CA for <precis@ietf.org>; Thu, 30 Mar 2017 18:45:10 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 412C320C4E; Thu, 30 Mar 2017 21:45:10 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 30 Mar 2017 21:45:10 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= 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:x-sasl-enc; s=fm1; bh=HSgcMdd8XKuXoH9ivX 6/fKgHGOduTFNBLSqmQaD+4X4=; b=k2y1Tsys1rFUZCvdW0Kfx6fYVyeSGirULo Otl8ZnKnQ1NwssXrHv6nSpV4lah2gIIZfl+pKxb21vS3AU5UHHTzWOtkkDJ4g4k7 frh8yYST212f3PGNW+bFJoMmGl/wJToqkgNb7nw1ZxynLgT6TL5MZOZfoTrBThL5 Iq2I/EmsM6+NgiwIgEb/L8YnNiI4i5HbA4VecSPleVuVLetCJWXaJwHSVtYOERIc oNyiMkXwRanh4E5IIoKOdZih99rTOXhMeuJOoOXHllcPN/OECQ8bj2Htx5sOC4BB +TgVPP03/4osuoRaiBdzlgsn/dutr59umbMie2tgahGMFeEsagYg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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:x-sasl-enc; s= fm1; bh=HSgcMdd8XKuXoH9ivX6/fKgHGOduTFNBLSqmQaD+4X4=; b=N6VJ/ohV oT9a+XXe3QoVw2RHTATwh/W7IKE8yc0nMyjMwtQoYaoyVIKhlKeV1jqYx/TsdKzk l1JQbJGl8PuR1ufvYjnnxKaCKzyuVnfJBqQzLZBSW2+zFO4Eyh+QbM9qrpfL+uJt D0LgkgJeBcXiQulXnzyyKbZHmV8V9My9wxAO/aJUrbltxpL5GBCLq4YkE9eRR2CO Ea15rVzfXNoR1NnBZk+Jo221LomQjFQInHv+pqZM5Pp9ZPqxM3EBZt2WQM4ync7m Q7tNnDNvPKR9rzWBbuZMfyEeScnofvXQ3LVkBkjbBxw5ZI5fZ+ENLNl8XCcl8IDO L55pllYP3UHy4Q==
X-ME-Sender: <xms:prTdWKutQlnEJktww8jknQVkwFaA0TLmhtn7926SGhSXYpmKBV1cRQ>
X-Sasl-enc: fe2eMQbreZt5HuGuMSp8nliWPDp+yxcPk/0BlIAyhAeR 1490924709
Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id BDEFA24370; Thu, 30 Mar 2017 21:45:09 -0400 (EDT)
To: Nikos Mavrogiannopoulos <nmav@redhat.com>, precis@ietf.org
References: <1490885635.10364.10.camel@redhat.com>
From: Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <5d02a0bc-5f53-a9fe-33fe-be0c66de24ee@stpeter.im>
Date: Thu, 30 Mar 2017 19:45:08 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <1490885635.10364.10.camel@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/precis/pPBPqLMNIJDxhOiwAADRBaCs28w>
Subject: Re: [precis] rationale of rfc7613 decisions
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: Fri, 31 Mar 2017 01:45:13 -0000

On 3/30/17 8:53 AM, Nikos Mavrogiannopoulos wrote:
> Hi,
>  I'd like to update an rfc in order to follow the rfc7613
> recommendations for passwords, however I'd like first to understand the
> reason of the restrictions applied to passwords (i.e., freeformclass
> choice, space elimination, etc.).

Thanks for asking!

> I'm checking both rfc7564 and rfc7613, and I cannot find the rationale
> of the restrictions being done. In particular:
>  1. why rfc7613 restricts all spaces for passwords to U+0020?

First, RFC 4013 prohibited non-ASCII space code points (see §2.3), and
RFC 7613 was intended as much as possible to not change handling of code
points.

Second, there are many issues with non-ASCII space code points, such as
zero-width spaces that aren't visible to a user and variations in input
methods across devices that are "localized" for different scripts and
locales. You can find some discussion about it here:

https://www.ietf.org/mail-archive/web/precis/current/msg00251.html

>  2. what is the purpose of "Contextual Rule Required" in section 4.3.2
> of rfc7564?

It's complicated, but in essence PRECIS is consistent with IDNA2008 here
(see RFC 5891, RFC 5892, and RFC 5894). In particular, the code points
ZERO WIDTH JOINER (U+200D) and ZERO WIDTH NON-JOINER (U+200C) are
necessary to produce certain combinatiosn of characters in certain
scripts (e.g., Arabic, Persian, and Indic scripts) but if used in other
contexts can have consequences that violate the principle of least user
astonishment.

>  3. why freeform class doesn't allow "Old Hangul Jamo characters"?

As explained in §2.9 of RFC 5892:

   Elimination of conjoining Hangul Jamo from the set of PVALID
   characters results in restricting the set of Korean PVALID characters
   just to preformed, modern Hangul syllable characters.

Here again PRECIS is consistent with IDNA2008.

>  4. why freeform class doesn't allow ignorable charaters?

These are things like soft hyphen, certain joiners, specialized code
points for use within Unicode itself (e.g., language tags and variation
selectors), and so on. They were disallowed in RFC 4013 and are
disallowed in IDNA2008, too.

By saying "PRECIS is consistent with IDNA2008" I'm not appealing to
authority or saying that a consistency is necessarily a good thing.
Instead, defining as few string handling methods as possible helps users
because strings aren't handled differently in different protocols and
contexts (see §5.1 of RFC 7564). This has security implications, too,
because the more such methods exist the easier it will be for attackers
to trick users.

> The context of that, is that I am trying to understand what would be
> the drawbacks from recommending a fixed normalization form (e.g., NFC),
> for passwords, in contrast to recommending rfc7613.

Nikos, instead of asking us why the foregoing restrictions were made,
ask yourself why you would want to ignore them and whether you
understand internationalization well enough to independently craft
appropriate rules and guidelines for the RFC you're updating. Because
you actively work on security technologies, think of it this way: would
you want someone who doesn't understand all the issues to "just use TLS"
without specifying appropriate cipher suites (ignoring RFC 7525) or
certificate checking procedures (ignoring RFC 5280 and RFC 6125)? The
issues involved with internationalization are just as complex (albeit in
different ways) and the whole reason we developed IDNA2008 and PRECIS is
so that well-meaning folks like you don't shoot yourselves in the foot.
I strongly encourage you to use the PRECIS profile for passwords in RFC
7613, and we'd be happy to help you do so in the safest ways possible.

Peter