From nobody Wed May 6 21:22:37 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA5B1A00CD; Wed, 6 May 2015 21:22:35 -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] autolearn=ham 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 7soJ5qFyQ_iV; Wed, 6 May 2015 21:22:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 934451A9114; Wed, 6 May 2015 21:22:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150507042233.13619.17210.idtracker@ietfa.amsl.com> Date: Wed, 06 May 2015 21:22:33 -0700 Archived-At: Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-mappings-10.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 04:22:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. Title : Mapping characters for PRECIS classes Authors : Yoshiro YONEYA Takahiro Nemoto Filename : draft-ietf-precis-mappings-10.txt Pages : 12 Date : 2015-05-06 Abstract: The framework for preparation and comparison of internationalized strings ("PRECIS") defines several classes of strings for preparation and comparison. Case mapping is defined because many protocols perform case-sensitive or case-insensitive string comparison and so preparation of the string is mandatory. The Internationalized Domain Names in Applications (IDNA) and the PRECIS problem statement describes mappings for internationalized strings that are not limited to case, but include width mapping and mapping of delimiters and other specials that can be taken into consideration. This document provides guidelines for authors of protocol profiles of the PRECIS framework and describes several mappings that can be applied between receiving user input and passing permitted code points to internationalized protocols. The mappings described here are expected to be applied as an additional mapping and locale-/context- dependent case mapping. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-mappings/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-precis-mappings-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-precis-mappings-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 6 22:32:12 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058ED1ACD71 for ; Wed, 6 May 2015 22:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 U5L0Wugsj3VK for ; Wed, 6 May 2015 22:32:10 -0700 (PDT) Received: from mail.kmd.keio.ac.jp (mail.kmd.keio.ac.jp [IPv6:2001:200:167:2e90::164]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7A31A1EF5 for ; Wed, 6 May 2015 22:32:10 -0700 (PDT) Received: from [100.64.32.16] (unknown [133.2.56.33]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kmd.keio.ac.jp (Postfix) with ESMTPSA id C812D7FBD1 for ; Thu, 7 May 2015 14:32:07 +0900 (JST) (envelope-from t.nemo10@kmd.keio.ac.jp) From: Takahiro Nemoto Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 7 May 2015 14:31:59 +0900 References: <20150507042233.13619.17210.idtracker@ietfa.amsl.com> To: precis@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [precis] Fwd: I-D Action: draft-ietf-precis-mappings-10.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 07 May 2015 05:32:12 -0000 Dear all,=20 Yoneya-san and I have submitted the latest version of precis mappings = document.=20 In this document, we reflected comments received during the WG LC. If this version looks ok, I would be grateful if you could proceed to = the next step for the IETF LC. Regards, Nemo -- Takahiro Nemoto t.nemo10@kmd.keio.ac.jp > =E8=BB=A2=E9=80=81=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=83=E3=82=BB= =E3=83=BC=E3=82=B8=EF=BC=9A >=20 > =E5=B7=AE=E5=87=BA=E4=BA=BA: internet-drafts@ietf.org > =E4=BB=B6=E5=90=8D: [precis] I-D Action: = draft-ietf-precis-mappings-10.txt > =E6=97=A5=E4=BB=98: 2015=E5=B9=B45=E6=9C=887=E6=97=A5 13:22:33 JST > =E5=AE=9B=E5=85=88: > CC: precis@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Preparation and Comparison of = Internationalized Strings Working Group of the IETF. >=20 > Title : Mapping characters for PRECIS classes > Authors : Yoshiro YONEYA > Takahiro Nemoto > Filename : draft-ietf-precis-mappings-10.txt > Pages : 12 > Date : 2015-05-06 >=20 > Abstract: > The framework for preparation and comparison of internationalized > strings ("PRECIS") defines several classes of strings for = preparation > and comparison. Case mapping is defined because many protocols > perform case-sensitive or case-insensitive string comparison and so > preparation of the string is mandatory. The Internationalized = Domain > Names in Applications (IDNA) and the PRECIS problem statement > describes mappings for internationalized strings that are not = limited > to case, but include width mapping and mapping of delimiters and > other specials that can be taken into consideration. This document > provides guidelines for authors of protocol profiles of the PRECIS > framework and describes several mappings that can be applied between > receiving user input and passing permitted code points to > internationalized protocols. The mappings described here are > expected to be applied as an additional mapping and locale-/context- > dependent case mapping. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-precis-mappings/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-precis-mappings-10 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-precis-mappings-10 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis From nobody Fri May 15 19:07:09 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169321ACE67; Fri, 15 May 2015 19:07:07 -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] autolearn=ham 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 mfBCYF-nntTE; Fri, 15 May 2015 19:06:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E941ACE72; Fri, 15 May 2015 19:06:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150516020655.25848.92394.idtracker@ietfa.amsl.com> Date: Fri, 15 May 2015 19:06:55 -0700 Archived-At: Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-saslprepbis-17.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 02:07:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. Title : Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords Authors : Peter Saint-Andre Alexey Melnikov Filename : draft-ietf-precis-saslprepbis-17.txt Pages : 23 Date : 2015-05-15 Abstract: This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454). The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. The PRECIS framework, RFC YYYY, obsoletes RFC 3454, and this document obsoletes RFC 4013. [[ NOTE TO RFC EDITOR: please replace "YYYY" in the previous paragraph with the RFC number assigned to draft-ietf-precis- framework. ]] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-precis-saslprepbis-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-precis-saslprepbis-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 15 19:09:27 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB03D1ACE6A for ; Fri, 15 May 2015 19:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 YZ9ZV0b_Nm_Z for ; Fri, 15 May 2015 19:09:25 -0700 (PDT) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (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 11EFC1AC42C for ; Fri, 15 May 2015 19:09:25 -0700 (PDT) Received: by iebgx4 with SMTP id gx4so135530530ieb.0 for ; Fri, 15 May 2015 19:09:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yy5ciEBBKWsa+7u1WKYTepSFMYBoUGeqO1Y6hWvZZLY=; b=X2zTOU3wzQfjMJxUE9tgijh8sQWcXiwbYuoDfdiszY7yqAVDCRRkVL0VXp2Ts8Sr6H 9Z/Hm1gdMhqEcb7wJjQcEcPvT4mmZH2We/ljuJ3o2ZypJOJpnyGHlZrq6DYan+NuMtTu hqc5k12iQaxmItqAKL3j05eqQQ00fD1aw7C7HF/MpqWcIe0ghTLqLHLRGe2ecK+cyN94 Y2D/0cuITrlVlM5tByEeuN++UmtbnBmuUNADzccCkHP9salak0ooqvuHD3C6I5AtxtBW jnbyVAz+uLXaVens919vZI+DOWEZyS4bbqQJQerNhZSwuRPvTymNfNY3n4SXnbgD1n7l O+xw== X-Gm-Message-State: ALoCoQkM7hJEd28UeCDMbgZtzDfSD+o9px2s7kjpzfn7R82YcaQ1djvUV10owNB8QHNFTibSIn/5 X-Received: by 10.42.104.143 with SMTP id r15mr1193892ico.33.1431742164563; Fri, 15 May 2015 19:09:24 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id n9sm452161igy.2.2015.05.15.19.09.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 May 2015 19:09:24 -0700 (PDT) Message-ID: <5556A6D3.1090401@andyet.net> Date: Fri, 15 May 2015 20:09:23 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "precis@ietf.org" References: <20150516020655.25848.92394.idtracker@ietfa.amsl.com> In-Reply-To: <20150516020655.25848.92394.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [precis] I-D Action: draft-ietf-precis-saslprepbis-17.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 02:09:27 -0000 A few editorial changes to address feedback from IANA's expert reviewer. On 5/15/15 8:06 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. > > Title : Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords > Authors : Peter Saint-Andre > Alexey Melnikov > Filename : draft-ietf-precis-saslprepbis-17.txt > Pages : 23 > Date : 2015-05-15 > > Abstract: > This document describes updated methods for handling Unicode strings > representing usernames and passwords. The previous approach was > known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454). > The methods specified in this document provide a more sustainable > approach to the handling of internationalized usernames and > passwords. The PRECIS framework, RFC YYYY, obsoletes RFC 3454, and > this document obsoletes RFC 4013. > > [[ NOTE TO RFC EDITOR: please replace "YYYY" in the previous > paragraph with the RFC number assigned to draft-ietf-precis- > framework. ]] > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-precis-saslprepbis-17 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-precis-saslprepbis-17 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis > From nobody Wed May 20 08:43:46 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C591A88ED; Wed, 20 May 2015 08:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 TAvqO3zJoiCR; Wed, 20 May 2015 08:43:32 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 415BB1A88C0; Wed, 20 May 2015 08:43:32 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2BCAB180207; Wed, 20 May 2015 08:41:49 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150520154149.2BCAB180207@rfc-editor.org> Date: Wed, 20 May 2015 08:41:49 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, precis@ietf.org, rfc-editor@rfc-editor.org Subject: [precis] RFC 7564 on PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 15:43:38 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7564 Title: PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols Author: P. Saint-Andre, M. Blanchet Status: Standards Track Stream: IETF Date: May 2015 Mailbox: peter@andyet.com, Marc.Blanchet@viagenie.ca Pages: 40 Characters: 93580 Obsoletes: RFC 3454 I-D Tag: draft-ietf-precis-framework-23.txt URL: https://www.rfc-editor.org/info/rfc7564 DOI: http://dx.doi.org/10.17487/RFC7564 Application protocols using Unicode characters in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode characters and thus is agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). This document obsoletes RFC 3454. This document is a product of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed May 20 17:53:57 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C816A1ACDFA for ; Wed, 20 May 2015 17:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 WObxGtAulRUR for ; Wed, 20 May 2015 17:53:54 -0700 (PDT) Received: from off-send01.osa.jprs.co.jp (off-send01.osa.jprs.co.jp [IPv6:2001:218:3001:17::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFBC81ACDF5 for ; Wed, 20 May 2015 17:53:53 -0700 (PDT) Received: from off-sendsmg01.osa.jprs.co.jp (off-sendsmg01.osa.jprs.co.jp [172.23.8.61]) by off-send01.osa.jprs.co.jp (8.14.4/8.14.4) with ESMTP id t4L0rqSk012292 for ; Thu, 21 May 2015 09:53:52 +0900 Received: from off-sendsmg01.osa.jprs.co.jp (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 4B93618008A for ; Thu, 21 May 2015 09:53:52 +0900 (JST) Received: from NOTE701 (off-cpu04.osa.jprs.co.jp [172.23.4.14]) by off-sendsmg01.osa.jprs.co.jp (Postfix) with SMTP id 36B87180083 for ; Thu, 21 May 2015 09:53:52 +0900 (JST) Date: Thu, 21 May 2015 09:53:50 +0900 From: Yoshiro YONEYA To: precis@ietf.org Message-Id: <20150521095350.97c7f2fff5ba5f6704086125@jprs.co.jp> In-Reply-To: <20150520154149.2BCAB180207@rfc-editor.org> References: <20150520154149.2BCAB180207@rfc-editor.org> X-Mailer: Sylpheed 3.4.2 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1690-7.5.0.1018-21558.003 X-TM-AS-Result: No--13.619-5.0-31-10 X-imss-scan-details: No--13.619-5.0-31-10 X-TMASE-MatchedRID: e01xcIcDidBITndh1lLRAe5i6weAmSDKWDesRNOOJ5S4Kkg59mswF8kU hKWc+gwPwQTqbLJ40jvML8wBL67mTkCwax7Kf3TzwMyV95EWVHz6rVj794QCtp+7oM+WVIAGwvi eYviT183WsBqRfU1d82nSgMzqcvaW+zoAW8R15l/hG1IOMb7PsIzuaz5bbS8aWthoc/ryGpffl0 PvqvMF9w1M1a25PDJZDgI8Wzh9BmJ/dZAjNXEbFuw8wbnnSw8bI5K4Cd+0ao9ElaZ44wdr5CauO FATuLMAXzSwTEbZ9U5zt6EQzpc7ynjxgHkp9duCxDtI40oHM24a4M6Y6n4rsCSPufJfHBYzUaUi 0dz59AEc4RxPyT9JSbiwCI4RwXun8qDKfg0IOPyQmLXB14cW2pJOcXMQc4jBmyiLZetSf8nJ4y0 wP1A6AB8AKgKWeNGhxTWcrUfjNQQwziKhrKXi3XnVOpTXYxva6WhiDOOieuw7AFczfjr/7KYHgw OHaEL3guzj4N8A9Pxgg0+XPGKjccRR8lhJwS93ScLfMEVR9sI= Archived-At: Subject: Re: [precis] RFC 7564 on PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 21 May 2015 00:53:56 -0000 Congratulations! -- Yoshiro YONEYA On Wed, 20 May 2015 08:41:49 -0700 (PDT) rfc-editor@rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. > > > RFC 7564 > > Title: PRECIS Framework: Preparation, Enforcement, and > Comparison of Internationalized Strings in > Application Protocols > Author: P. Saint-Andre, M. Blanchet > Status: Standards Track > Stream: IETF > Date: May 2015 > Mailbox: peter@andyet.com, > Marc.Blanchet@viagenie.ca > Pages: 40 > Characters: 93580 > Obsoletes: RFC 3454 > > I-D Tag: draft-ietf-precis-framework-23.txt > > URL: https://www.rfc-editor.org/info/rfc7564 > > DOI: http://dx.doi.org/10.17487/RFC7564 > > Application protocols using Unicode characters in protocol strings > need to properly handle such strings in order to enforce > internationalization rules for strings placed in various protocol > slots (such as addresses and identifiers) and to perform valid > comparison operations (e.g., for purposes of authentication or > authorization). This document defines a framework enabling > application protocols to perform the preparation, enforcement, and > comparison of internationalized strings ("PRECIS") in a way that > depends on the properties of Unicode characters and thus is agile > with respect to versions of Unicode. As a result, this framework > provides a more sustainable approach to the handling of > internationalized strings than the previous framework, known as > Stringprep (RFC 3454). This document obsoletes RFC 3454. > > This document is a product of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. > > This is now a Proposed Standard. > > STANDARDS TRACK: This document specifies an Internet Standards Track > protocol for the Internet community, and requests discussion and suggestions > for improvements. Please refer to the current edition of the Official > Internet Protocol Standards (https://www.rfc-editor.org/standards) for the > standardization state and status of this protocol. Distribution of this > memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/rfc.html > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis > > From nobody Wed May 20 18:57:10 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069FA1ACE3F for ; Wed, 20 May 2015 18:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_QP_LONG_LINE=0.001, 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 Bcz30ulvLApA for ; Wed, 20 May 2015 18:57:07 -0700 (PDT) Received: from mail.kmd.keio.ac.jp (mail.kmd.keio.ac.jp [IPv6:2001:200:167:2e90::164]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6F31ACE36 for ; Wed, 20 May 2015 18:57:07 -0700 (PDT) Received: from [10.73.220.189] (pw126152167114.10.panda-world.ne.jp [126.152.167.114]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kmd.keio.ac.jp (Postfix) with ESMTPSA id BD53A7FBEF for ; Thu, 21 May 2015 10:57:03 +0900 (JST) (envelope-from t.nemo10@kmd.keio.ac.jp) From: Takahiro Nemoto Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: <6CD8B49B-6A50-42CA-92AE-24BC465CAFA4@kmd.keio.ac.jp> Date: Thu, 21 May 2015 10:57:02 +0900 References: <20150520154149.2BCAB180207@rfc-editor.org> <20150521095350.97c7f2fff5ba5f6704086125@jprs.co.jp> In-Reply-To: <20150521095350.97c7f2fff5ba5f6704086125@jprs.co.jp> To: "precis@ietf.org" X-Mailer: iPhone Mail (12F70) Archived-At: Subject: Re: [precis] RFC 7564 on PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 21 May 2015 01:57:09 -0000 Congratulations!! Nemo 2015/05/21 9:53=1B$B!"=1B(BYoshiro YONEYA =1B$B$= N%a%C%;!<%8=1B(B: > Congratulations! >=20 > --=20 > Yoshiro YONEYA >=20 >> On Wed, 20 May 2015 08:41:49 -0700 (PDT) rfc-editor@rfc-editor.org wrote:= >>=20 >> A new Request for Comments is now available in online RFC libraries. >>=20 >>=20 >> RFC 7564 >>=20 >> Title: PRECIS Framework: Preparation, Enforcement, and=20 >> Comparison of Internationalized Strings in >> Application Protocols=20 >> Author: P. Saint-Andre, M. Blanchet >> Status: Standards Track >> Stream: IETF >> Date: May 2015 >> Mailbox: peter@andyet.com,=20 >> Marc.Blanchet@viagenie.ca >> Pages: 40 >> Characters: 93580 >> Obsoletes: RFC 3454 >>=20 >> I-D Tag: draft-ietf-precis-framework-23.txt >>=20 >> URL: https://www.rfc-editor.org/info/rfc7564 >>=20 >> DOI: http://dx.doi.org/10.17487/RFC7564 >>=20 >> Application protocols using Unicode characters in protocol strings >> need to properly handle such strings in order to enforce >> internationalization rules for strings placed in various protocol >> slots (such as addresses and identifiers) and to perform valid >> comparison operations (e.g., for purposes of authentication or >> authorization). This document defines a framework enabling >> application protocols to perform the preparation, enforcement, and >> comparison of internationalized strings ("PRECIS") in a way that >> depends on the properties of Unicode characters and thus is agile >> with respect to versions of Unicode. As a result, this framework >> provides a more sustainable approach to the handling of >> internationalized strings than the previous framework, known as >> Stringprep (RFC 3454). This document obsoletes RFC 3454. >>=20 >> This document is a product of the Preparation and Comparison of Internati= onalized Strings Working Group of the IETF. >>=20 >> This is now a Proposed Standard. >>=20 >> STANDARDS TRACK: This document specifies an Internet Standards Track >> protocol for the Internet community, and requests discussion and suggesti= ons >> for improvements. Please refer to the current edition of the Official >> Internet Protocol Standards (https://www.rfc-editor.org/standards) for th= e=20 >> standardization state and status of this protocol. Distribution of this=20= >> memo is unlimited. >>=20 >> This announcement is sent to the IETF-Announce and rfc-dist lists. >> To subscribe or unsubscribe, see >> https://www.ietf.org/mailman/listinfo/ietf-announce >> https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >>=20 >> For searching the RFC series, see https://www.rfc-editor.org/search >> For downloading RFCs, see https://www.rfc-editor.org/rfc.html >>=20 >> Requests for special distribution should be addressed to either the >> author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless >> specifically noted otherwise on the RFC itself, all RFCs are for >> unlimited distribution. >>=20 >>=20 >> The RFC Editor Team >> Association Management Solutions, LLC >>=20 >>=20 >> _______________________________________________ >> precis mailing list >> precis@ietf.org >> https://www.ietf.org/mailman/listinfo/precis >=20 > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis From nobody Wed May 27 05:56:22 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337701A888B; Wed, 27 May 2015 05:56:21 -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] autolearn=ham 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 QJNDg8-YL3bG; Wed, 27 May 2015 05:56:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0F81A887B; Wed, 27 May 2015 05:56:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150527125619.24017.77007.idtracker@ietfa.amsl.com> Date: Wed, 27 May 2015 05:56:19 -0700 Archived-At: Cc: draft-ietf-precis-saslprepbis@ietf.org, precis@ietf.org, draft-ietf-precis-saslprepbis.ad@ietf.org, precis-chairs@ietf.org, draft-ietf-precis-saslprepbis.shepherd@ietf.org Subject: [precis] Stephen Farrell's Discuss on draft-ietf-precis-saslprepbis-17: (with DISCUSS and COMMENT) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 12:56:21 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-precis-saslprepbis-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 4.1: zero length password - I think you're wrong on that one but it is arguable. If RFC4013 also prohibited zero length passwords (I couldn't tell at a quick glance) or if the WG did debate this and having done so decided to prohibit zero length passwords then I will clear the discuss immediately. But if not, I'd like to chat about it... There are situations where an empty password is ok (say when I'm not "protecting" something but just want to know what user's profile to use, e.g. for weather) and that is supported in many systems (that hence won't be able to exactly adopt this) and insisting on a non-empty password could be more damaging than allowing a zero-length password, whenever a user re-uses a password for something for which no password is really needed (and which hence is less likely to be well protected) and where that password is also used to protect something of significantly higher value. The zero-length password is also not an interesting subset of the set of stupid passwords really so doesn't deserve to be called out as such (and you say that in the draft when you talk about length-1 passwords.) So I think allowing zero length passwords is better overall, and more consistent with implementations. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - Unsurprisingly, the diff between this and RFC4013 isn't useful, so I read from scratch. If I'm commenting on something that was already true of 4013, just tell me and that'll be fine. - intro: given the unsolved i18n issues and the fact that passwords are crap (security wise) would it be fair to ask that you add a sentence here to encourage folks to not use passwords at all but some better form of authentication, when that's possible? (Which is sadly not nearly common enough for user authentication.) - nitty nit: intro, 2nd last para on p3: once a password is chosen, there are no more entropy changes so you cannot maximise entropy *during* authentication. Maybe s/during/for/ works though. - 3.2.2, bullet 3: I read this as saying to use the latest Unicode default case folding and not to stick with v7.0 even if a new and in this sense different version is published. This is just to check that that is what you intended and that I've not misread the text. From nobody Wed May 27 06:06:58 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE5C1A88F0; Wed, 27 May 2015 06:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 yDME4X1F0G2I; Wed, 27 May 2015 06:06:51 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [217.34.220.150]) by ietfa.amsl.com (Postfix) with ESMTP id B261A1A88E9; Wed, 27 May 2015 06:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1432732004; d=isode.com; s=selector; i=@isode.com; bh=JbkBQsojO2NvnXFbXY3gCCA4Jbuc3EbWjuVmswLkZZM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=l9zWs26oOtG4UssdtTpy7RR2ZIulpI52JZNkLga0eJhic+5wcAjF/XS6M4BoJAoUU9AGba t4B86mb8tGZayqWGRmWPfVohe5xmBknaAHMSs6kQZeQpFACFtWStgNLh/n/U+Ic3C3EvFR V3xcyjCCwqpKtGH6DdgYIShR6/jcn8w=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 27 May 2015 14:06:44 +0100 Message-ID: <5565C153.1030708@isode.com> Date: Wed, 27 May 2015 14:06:27 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 To: Stephen Farrell , The IESG References: <20150527125619.24017.77007.idtracker@ietfa.amsl.com> In-Reply-To: <20150527125619.24017.77007.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-precis-saslprepbis@ietf.org, precis@ietf.org, draft-ietf-precis-saslprepbis.ad@ietf.org, precis-chairs@ietf.org, draft-ietf-precis-saslprepbis.shepherd@ietf.org Subject: Re: [precis] Stephen Farrell's Discuss on draft-ietf-precis-saslprepbis-17: (with DISCUSS and COMMENT) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 13:06:53 -0000 Hi Stephen, On 27/05/2015 13:56, Stephen Farrell wrote: [...] > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > 4.1: zero length password - I think you're wrong on that > one but it is arguable. If RFC4013 also prohibited zero > length passwords (I couldn't tell at a quick glance) Yes, zero length password was always prohibited by RFC 4013. If you look at various RFCs that reference SASLPrep, they say "if the password is invalid or zero length after applying SASLPrep normalization, then reject it" (or similar words). > or if > the WG did debate this and having done so decided to > prohibit zero length passwords then I will clear the > discuss immediately. But if not, I'd like to chat about > it... > > There are situations where an empty password is ok (say > when I'm not "protecting" something but just want to know > what user's profile to use, e.g. for weather) and that is > supported in many systems (that hence won't be able to > exactly adopt this) and insisting on a non-empty password > could be more damaging than allowing a zero-length > password, whenever a user re-uses a password for something > for which no password is really needed (and which hence is > less likely to be well protected) and where that password > is also used to protect something of significantly higher > value. The zero-length password is also not an interesting > subset of the set of stupid passwords really so doesn't > deserve to be called out as such (and you say that in the > draft when you talk about length-1 passwords.) So I think > allowing zero length passwords is better overall, and more > consistent with implementations. The main reason for disallowing it was because with SASLPrep (or Precis), a non empty sequence of characters can result in empty password after canonicalization, which seems misleading/dangerous if allowed. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - Unsurprisingly, the diff between this and RFC4013 isn't > useful, so I read from scratch. If I'm commenting on > something that was already true of 4013, just tell me and > that'll be fine. > > - intro: given the unsolved i18n issues and the fact that > passwords are crap (security wise) would it be fair to ask > that you add a sentence here to encourage folks to not use > passwords at all but some better form of authentication, > when that's possible? (Which is sadly not nearly common > enough for user authentication.) Can you suggest specific text? It is a bit hard to agree/disagree in abstract. From nobody Wed May 27 06:14:18 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C273C1A88E8; Wed, 27 May 2015 06:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 KO6a-FABtfoV; Wed, 27 May 2015 06:14:08 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B961A8877; Wed, 27 May 2015 06:14:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DFB64BEE7; Wed, 27 May 2015 14:14:04 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gLEFeFWvV3J; Wed, 27 May 2015 14:14:04 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A0701BECF; Wed, 27 May 2015 14:14:04 +0100 (IST) Message-ID: <5565C31C.3020309@cs.tcd.ie> Date: Wed, 27 May 2015 14:14:04 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Alexey Melnikov , The IESG References: <20150527125619.24017.77007.idtracker@ietfa.amsl.com> <5565C153.1030708@isode.com> In-Reply-To: <5565C153.1030708@isode.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-precis-saslprepbis@ietf.org, precis@ietf.org, draft-ietf-precis-saslprepbis.ad@ietf.org, precis-chairs@ietf.org, draft-ietf-precis-saslprepbis.shepherd@ietf.org Subject: Re: [precis] Stephen Farrell's Discuss on draft-ietf-precis-saslprepbis-17: (with DISCUSS and COMMENT) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 13:14:13 -0000 Hiya, On 27/05/15 14:06, Alexey Melnikov wrote: > Hi Stephen, > > On 27/05/2015 13:56, Stephen Farrell wrote: > [...] >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> 4.1: zero length password - I think you're wrong on that >> one but it is arguable. If RFC4013 also prohibited zero >> length passwords (I couldn't tell at a quick glance) > Yes, zero length password was always prohibited by RFC 4013. If you look > at various RFCs that reference SASLPrep, they say "if the password is > invalid or zero length after applying SASLPrep normalization, then > reject it" (or similar words). That wins. I'll clear the discuss and make this a comment. >> or if >> the WG did debate this and having done so decided to >> prohibit zero length passwords then I will clear the >> discuss immediately. But if not, I'd like to chat about >> it... >> >> There are situations where an empty password is ok (say >> when I'm not "protecting" something but just want to know >> what user's profile to use, e.g. for weather) and that is >> supported in many systems (that hence won't be able to >> exactly adopt this) and insisting on a non-empty password >> could be more damaging than allowing a zero-length >> password, whenever a user re-uses a password for something >> for which no password is really needed (and which hence is >> less likely to be well protected) and where that password >> is also used to protect something of significantly higher >> value. The zero-length password is also not an interesting >> subset of the set of stupid passwords really so doesn't >> deserve to be called out as such (and you say that in the >> draft when you talk about length-1 passwords.) So I think >> allowing zero length passwords is better overall, and more >> consistent with implementations. > The main reason for disallowing it was because with SASLPrep (or > Precis), a non empty sequence of characters can result in empty password > after canonicalization, which seems misleading/dangerous if allowed. >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> - Unsurprisingly, the diff between this and RFC4013 isn't >> useful, so I read from scratch. If I'm commenting on >> something that was already true of 4013, just tell me and >> that'll be fine. >> >> - intro: given the unsolved i18n issues and the fact that >> passwords are crap (security wise) would it be fair to ask >> that you add a sentence here to encourage folks to not use >> passwords at all but some better form of authentication, >> when that's possible? (Which is sadly not nearly common >> enough for user authentication.) > Can you suggest specific text? It is a bit hard to agree/disagree in > abstract. Will do in the updated comment. Cheers, S. > > From nobody Wed May 27 06:21:15 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17C81AD080; Wed, 27 May 2015 06:21:11 -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] autolearn=ham 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 8gJC3-j9-K3P; Wed, 27 May 2015 06:21:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EAFB51AD06D; Wed, 27 May 2015 06:21:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150527132109.25645.76593.idtracker@ietfa.amsl.com> Date: Wed, 27 May 2015 06:21:09 -0700 Archived-At: Cc: draft-ietf-precis-saslprepbis@ietf.org, precis@ietf.org, draft-ietf-precis-saslprepbis.ad@ietf.org, precis-chairs@ietf.org, draft-ietf-precis-saslprepbis.shepherd@ietf.org Subject: [precis] Stephen Farrell's No Objection on draft-ietf-precis-saslprepbis-17: (with COMMENT) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 13:21:11 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-precis-saslprepbis-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - Unsurprisingly, the diff between this and RFC4013 isn't useful, so I read from scratch. If I'm commenting on something that was already true of 4013, just tell me and that'll be fine. - intro: given the unsolved i18n issues and the fact that passwords are crap (security wise) would it be fair to ask that you add a sentence here to encourage folks to not use passwords at all but some better form of authentication, when that's possible? (Which is sadly not nearly common enough for user authentication.) Maybe something like: "While this document specifies how to handle passwords to the best of our current abilities, those designing and implementing protocols would be much better off if they can avoid any use of passwords. Using passwords means having to deal with the inherent insecurity of passwords, and of password verifier databases, and also the i18n issues described here. Authentication schemes based on digital signatures or other cryptographic mechanisms are, where usable, far preferable." - nitty nit: intro, 2nd last para on p3: once a password is chosen, there are no more entropy changes so you cannot maximise entropy *during* authentication. Maybe s/during/for/ works though. - 3.2.2, bullet 3: I read this as saying to use the latest Unicode default case folding and not to stick with v7.0 even if a new and in this sense different version is published. This is just to check that that is what you intended and that I've not misread the text. 4.1: zero length password - I think you're wrong on that one but it is arguable. This was a discuss until you told me that 4013 prohibited 'em too so probably no point in changing now if it's just my opinion. There are situations where an empty password is ok (say when I'm not "protecting" something but just want to know what user's profile to use, e.g. for weather) and that is supported in many systems (that hence won't be able to exactly adopt this) and insisting on a non-empty password could be more damaging than allowing a zero-length password, whenever a user re-uses a password for something for which no password is really needed (and which hence is less likely to be well protected) and where that password is also used to protect something of significantly higher value. The zero-length password is also not an interesting subset of the set of stupid passwords really so doesn't deserve to be called out as such (and you say that in the draft when you talk about length-1 passwords.) So I think allowing zero length passwords is better overall, and more consistent with implementations. From nobody Wed May 27 07:58:21 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCD71B2C41 for ; Wed, 27 May 2015 07:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 HPp5nN5N86h1 for ; Wed, 27 May 2015 07:58:14 -0700 (PDT) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (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 7A5901B2BB4 for ; Wed, 27 May 2015 07:58:10 -0700 (PDT) Received: by iepj10 with SMTP id j10so15434326iep.3 for ; Wed, 27 May 2015 07:58:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2srT0kRMgEwfl6tvPtq3O3nyH0i2eX78RGz/ltaEgUM=; b=F/GIvkSj3ZZCOfFa2nigyp2UWq1ZuWdGblwJhJ9i2bNcgBw+w97jJS8NR/HBCPpmz9 39TKTcu38wtIThjkGhLAUMMo80VM0ZobCy8dvQPBhCW6JjGDutPxNikcqfCcGrGD1QzR npMDOI4Y8Amy5PWVRhXsSoPxJvLVSszuCa9giHs/nxrNUpVbAv3d9IR59DsPCSh2l9Xx yX/eGt4DhKQErMPANr/QVhy8dJYbrlGJw4MNI/9F/5Hx+xwnqn2BtYff/bGYdtf23hJX UCGj13RXKvRLmZ9gUJUBub/cqCWR3qLOnAiwbKPMzI10J9Y1wCNxdV2JjfT3gUXbf/Xa 5p3A== X-Gm-Message-State: ALoCoQkjNS13C2LYlM1rq97Jysj3cfWqLOQ3iq3OCIlJ1HQtdC0tkd8lDty/AspQYz2fPQ0BYhqA X-Received: by 10.50.49.46 with SMTP id r14mr36321564ign.45.1432738689790; Wed, 27 May 2015 07:58:09 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id j3sm1942973igx.21.2015.05.27.07.58.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 May 2015 07:58:08 -0700 (PDT) Message-ID: <5565DB7E.6080508@andyet.net> Date: Wed, 27 May 2015 08:58:06 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Stephen Farrell , The IESG References: <20150527132109.25645.76593.idtracker@ietfa.amsl.com> In-Reply-To: <20150527132109.25645.76593.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-precis-saslprepbis@ietf.org, precis@ietf.org, draft-ietf-precis-saslprepbis.ad@ietf.org, precis-chairs@ietf.org, draft-ietf-precis-saslprepbis.shepherd@ietf.org Subject: Re: [precis] Stephen Farrell's No Objection on draft-ietf-precis-saslprepbis-17: (with COMMENT) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 14:58:18 -0000 On 5/27/15 7:21 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-precis-saslprepbis-17: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - Unsurprisingly, the diff between this and RFC4013 isn't > useful, so I read from scratch. If I'm commenting on > something that was already true of 4013, just tell me and > that'll be fine. Truly, the diff is so large that it's more sensible to read this document anew. > - intro: given the unsolved i18n issues and the fact that > passwords are crap (security wise) would it be fair to ask > that you add a sentence here to encourage folks to not use > passwords at all but some better form of authentication, > when that's possible? (Which is sadly not nearly common > enough for user authentication.) Maybe something like: > > "While this document specifies how to handle passwords > to the best of our current abilities, those designing and > implementing protocols would be much better off if they > can avoid any use of passwords. Using passwords means > having to deal with the inherent insecurity of passwords, > and of password verifier databases, and also the i18n > issues described here. Authentication schemes based on > digital signatures or other cryptographic mechanisms > are, where usable, far preferable." Is it really the place of this document to discourage the use of passwords? I'm all in favor of the sentiment, but it seems to me that a BCP on the topic would have a lot more force and could claim IETF consensus. > - nitty nit: intro, 2nd last para on p3: once a password is > chosen, there are no more entropy changes so you cannot > maximise entropy *during* authentication. Maybe > s/during/for/ works though. +1 > - 3.2.2, bullet 3: I read this as saying to use the latest > Unicode default case folding and not to stick with v7.0 > even if a new and in this sense different version is > published. This is just to check that that is what you > intended and that I've not misread the text. We might do this: OLD (at the time of this writing, the algorithm is specified in Chapter 3 of [Unicode7.0]) NEW (at the time of this writing, the algorithm is specified in Chapter 3 of [Unicode7.0], but the chapter number might change in a future version of the Unicode Standard) The idea behind including the Unicode7.0 reference was to enable the reader to quickly find the relevant discussion as of today, but we know that the exact pointer might change. > 4.1: zero length password - I think you're wrong on that > one but it is arguable. This was a discuss until you told > me that 4013 prohibited 'em too so probably no point > in changing now if it's just my opinion. > > There are situations where an empty password is ok (say > when I'm not "protecting" something but just want to know > what user's profile to use, e.g. for weather) and that is > supported in many systems (that hence won't be able to > exactly adopt this) and insisting on a non-empty password > could be more damaging than allowing a zero-length > password, whenever a user re-uses a password for something > for which no password is really needed (and which hence is > less likely to be well protected) and where that password > is also used to protect something of significantly higher > value. The zero-length password is also not an interesting > subset of the set of stupid passwords really so doesn't > deserve to be called out as such (and you say that in the > draft when you talk about length-1 passwords.) So I think > allowing zero length passwords is better overall, and more > consistent with implementations. I see your point. Do you have a sense of what kind of systems today allow zero-length passwords? Given that RFC 4013 prohibited zero-length passwords and that they provide no security whatsoever, I don't see a compelling reason to modify the recommendation. However, as you say this document doesn't provide general guidance on password strengthy anyway, so I suppose I'd be fine with changing it to SHOULD NOT as long as we provide some text about why zero-length passwords are acceptable in some existing systems. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed May 27 08:13:01 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9570A1B2AEA; Wed, 27 May 2015 08:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 hHFVtQTx0Z2g; Wed, 27 May 2015 08:12:55 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A9741B2D20; Wed, 27 May 2015 08:12:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 555EBBEE1; Wed, 27 May 2015 16:12:54 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbCOI5cAFJCs; Wed, 27 May 2015 16:12:54 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C0E5DBEDF; Wed, 27 May 2015 16:12:53 +0100 (IST) Message-ID: <5565DEF5.6090405@cs.tcd.ie> Date: Wed, 27 May 2015 16:12:53 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Peter Saint-Andre - &yet , The IESG References: <20150527132109.25645.76593.idtracker@ietfa.amsl.com> <5565DB7E.6080508@andyet.net> In-Reply-To: <5565DB7E.6080508@andyet.net> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-precis-saslprepbis@ietf.org, precis@ietf.org, draft-ietf-precis-saslprepbis.ad@ietf.org, precis-chairs@ietf.org, draft-ietf-precis-saslprepbis.shepherd@ietf.org Subject: Re: [precis] Stephen Farrell's No Objection on draft-ietf-precis-saslprepbis-17: (with COMMENT) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 15:13:00 -0000 Hiya, On 27/05/15 15:58, Peter Saint-Andre - &yet wrote: > On 5/27/15 7:21 AM, Stephen Farrell wrote: >> Stephen Farrell has entered the following ballot position for >> draft-ietf-precis-saslprepbis-17: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> - Unsurprisingly, the diff between this and RFC4013 isn't >> useful, so I read from scratch. If I'm commenting on >> something that was already true of 4013, just tell me and >> that'll be fine. > > Truly, the diff is so large that it's more sensible to read this > document anew. > >> - intro: given the unsolved i18n issues and the fact that >> passwords are crap (security wise) would it be fair to ask >> that you add a sentence here to encourage folks to not use >> passwords at all but some better form of authentication, >> when that's possible? (Which is sadly not nearly common >> enough for user authentication.) Maybe something like: >> >> "While this document specifies how to handle passwords >> to the best of our current abilities, those designing and >> implementing protocols would be much better off if they >> can avoid any use of passwords. Using passwords means >> having to deal with the inherent insecurity of passwords, >> and of password verifier databases, and also the i18n >> issues described here. Authentication schemes based on >> digital signatures or other cryptographic mechanisms >> are, where usable, far preferable." > > Is it really the place of this document to discourage the use of > passwords? I'm all in favor of the sentiment, but it seems to me that a > BCP on the topic would have a lot more force and could claim IETF > consensus. Perhaps. But I'd still argue that this is a good place, even if not *the* place. I'm thinking that realising just how i18n is horrible might be the straw that breaks the camel's back and causes some coders to go use crypto instead:-) But, we probably shouldn't spend effort debating it, so I'd say best is if you folks decide to include something or not and I'll be fine with whatever you decide. > >> - nitty nit: intro, 2nd last para on p3: once a password is >> chosen, there are no more entropy changes so you cannot >> maximise entropy *during* authentication. Maybe >> s/during/for/ works though. > > +1 > >> - 3.2.2, bullet 3: I read this as saying to use the latest >> Unicode default case folding and not to stick with v7.0 >> even if a new and in this sense different version is >> published. This is just to check that that is what you >> intended and that I've not misread the text. > > We might do this: > > OLD > (at the time of this writing, the algorithm is specified in > Chapter 3 of [Unicode7.0]) > > NEW > (at the time of this writing, the algorithm is specified in > Chapter 3 of [Unicode7.0], but the chapter number might change > in a future version of the Unicode Standard) > > The idea behind including the Unicode7.0 reference was to enable the > reader to quickly find the relevant discussion as of today, but we know > that the exact pointer might change. I'm not sure NEW is that different and seems like I did get the right message from OLD, so you're probably fine with no change. > >> 4.1: zero length password - I think you're wrong on that >> one but it is arguable. This was a discuss until you told >> me that 4013 prohibited 'em too so probably no point >> in changing now if it's just my opinion. >> >> There are situations where an empty password is ok (say >> when I'm not "protecting" something but just want to know >> what user's profile to use, e.g. for weather) and that is >> supported in many systems (that hence won't be able to >> exactly adopt this) and insisting on a non-empty password >> could be more damaging than allowing a zero-length >> password, whenever a user re-uses a password for something >> for which no password is really needed (and which hence is >> less likely to be well protected) and where that password >> is also used to protect something of significantly higher >> value. The zero-length password is also not an interesting >> subset of the set of stupid passwords really so doesn't >> deserve to be called out as such (and you say that in the >> draft when you talk about length-1 passwords.) So I think >> allowing zero length passwords is better overall, and more >> consistent with implementations. > > I see your point. Do you have a sense of what kind of systems today > allow zero-length passwords? Given that RFC 4013 prohibited zero-length > passwords and that they provide no security whatsoever, I don't see a > compelling reason to modify the recommendation. However, as you say this > document doesn't provide general guidance on password strengthy anyway, > so I suppose I'd be fine with changing it to SHOULD NOT as long as we > provide some text about why zero-length passwords are acceptable in some > existing systems. I think most operating systems either allow empty passwords or else try insist on what they think is "strong" or else give some strength feedback to the user. Many CLI tools allow for empty passwords in case they're used in a script and the same goes for passwords needed by servers that might ever need to restart without a human. (And yes in most cases such tools provide a way to input a password from e.g. a file, but that's often no more secure than no password given how filesystem access control works.) I'll leave it to you folks to decide if you think a SHOULD NOT is ok or not, but I suspect you might want to check that the WG are ok with that change from 4013. I suppose an alternative might be to just note some of the issues above and say that in a bunch of cases an application will have to accept as input either or . I guess that's what's done now in any case and I'd be fine with handling it that way too if you prefer. Cheers, S. > > Peter > From nobody Wed May 27 08:28:33 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB831A8A7A for ; Wed, 27 May 2015 08:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 Ne3A-eV8Qk1U for ; Wed, 27 May 2015 08:28:28 -0700 (PDT) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (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 D0F0C1B2D5C for ; Wed, 27 May 2015 08:28:24 -0700 (PDT) Received: by iebgx4 with SMTP id gx4so16325723ieb.0 for ; Wed, 27 May 2015 08:28:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qcVP7rUGT7Pz3NE7heomKqsPdK347MwzJYK/279FjRk=; b=G7uuNYwPlNOygXzSw1Q1WhwHs327cTcmahSLv00KEBlU6vSKXz7u1cx4waK/FZuoLF JOAGlySqfODAaxf8sPyS75XEQzFr0ZelmxoCbBVn4z+a2DDSoU8V1llF+/2xpy6Wc2Y2 37OlBh6mjU8vG0mMnnhBpTIymEpWzs00/5YQVV2hqcLAS4bk/D2V55MoKQXQQEVFGV5Y +kyO7FzV/tcsJZurRGUKcvjTcaz5hQCjsKq4y+NYiMlgJHTlsm7l+PwsmvB1xkFz3Riu khzUur7CQ7Rqsc/v/pu9jXMUHVTwsZrd2CNAJon8jo6gpO1tlAnEzEpGlZrMI65hkHfh qUhw== X-Gm-Message-State: ALoCoQlWZeyJ0bHLC/uTbjK1cbz/RPczhKWljm9iILmFTk3Kni5uK6HjF3ezP5BDYD88ZTGhaTe6 X-Received: by 10.107.138.208 with SMTP id c77mr39901859ioj.24.1432740504268; Wed, 27 May 2015 08:28:24 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id z195sm13701510iod.33.2015.05.27.08.28.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 May 2015 08:28:23 -0700 (PDT) Message-ID: <5565E295.1010505@andyet.net> Date: Wed, 27 May 2015 09:28:21 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Stephen Farrell , The IESG References: <20150527132109.25645.76593.idtracker@ietfa.amsl.com> <5565DB7E.6080508@andyet.net> <5565DEF5.6090405@cs.tcd.ie> In-Reply-To: <5565DEF5.6090405@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-precis-saslprepbis@ietf.org, precis@ietf.org, draft-ietf-precis-saslprepbis.ad@ietf.org, precis-chairs@ietf.org, draft-ietf-precis-saslprepbis.shepherd@ietf.org Subject: Re: [precis] Stephen Farrell's No Objection on draft-ietf-precis-saslprepbis-17: (with COMMENT) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 15:28:31 -0000 On 5/27/15 9:12 AM, Stephen Farrell wrote: > > Hiya, > > On 27/05/15 15:58, Peter Saint-Andre - &yet wrote: >> On 5/27/15 7:21 AM, Stephen Farrell wrote: >>> Stephen Farrell has entered the following ballot position for >>> draft-ietf-precis-saslprepbis-17: No Objection >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> >>> - Unsurprisingly, the diff between this and RFC4013 isn't >>> useful, so I read from scratch. If I'm commenting on >>> something that was already true of 4013, just tell me and >>> that'll be fine. >> >> Truly, the diff is so large that it's more sensible to read this >> document anew. >> >>> - intro: given the unsolved i18n issues and the fact that >>> passwords are crap (security wise) would it be fair to ask >>> that you add a sentence here to encourage folks to not use >>> passwords at all but some better form of authentication, >>> when that's possible? (Which is sadly not nearly common >>> enough for user authentication.) Maybe something like: >>> >>> "While this document specifies how to handle passwords >>> to the best of our current abilities, those designing and >>> implementing protocols would be much better off if they >>> can avoid any use of passwords. Using passwords means >>> having to deal with the inherent insecurity of passwords, >>> and of password verifier databases, and also the i18n >>> issues described here. Authentication schemes based on >>> digital signatures or other cryptographic mechanisms >>> are, where usable, far preferable." >> >> Is it really the place of this document to discourage the use of >> passwords? I'm all in favor of the sentiment, but it seems to me that a >> BCP on the topic would have a lot more force and could claim IETF >> consensus. > > Perhaps. But I'd still argue that this is a good place, even > if not *the* place. I'm thinking that realising just how i18n > is horrible might be the straw that breaks the camel's back > and causes some coders to go use crypto instead:-) Hope does spring eternal, eh? Yet somehow I don't think i18n (which no one cares about) is going to push those coders over the edge, when multi-billion dollar breaches of password databases haven't done the job already. > But, we probably shouldn't spend effort debating it, so I'd > say best is if you folks decide to include something or not > and I'll be fine with whatever you decide. I'm inclined to leave it out. But would you like to work together on that I-D about why passwords must die a horrible death? ;-) >>> - nitty nit: intro, 2nd last para on p3: once a password is >>> chosen, there are no more entropy changes so you cannot >>> maximise entropy *during* authentication. Maybe >>> s/during/for/ works though. >> >> +1 >> >>> - 3.2.2, bullet 3: I read this as saying to use the latest >>> Unicode default case folding and not to stick with v7.0 >>> even if a new and in this sense different version is >>> published. This is just to check that that is what you >>> intended and that I've not misread the text. >> >> We might do this: >> >> OLD >> (at the time of this writing, the algorithm is specified in >> Chapter 3 of [Unicode7.0]) >> >> NEW >> (at the time of this writing, the algorithm is specified in >> Chapter 3 of [Unicode7.0], but the chapter number might change >> in a future version of the Unicode Standard) >> >> The idea behind including the Unicode7.0 reference was to enable the >> reader to quickly find the relevant discussion as of today, but we know >> that the exact pointer might change. > > I'm not sure NEW is that different and seems like I did get > the right message from OLD, so you're probably fine with no > change. Can't hut to be crystal clear! >>> 4.1: zero length password - I think you're wrong on that >>> one but it is arguable. This was a discuss until you told >>> me that 4013 prohibited 'em too so probably no point >>> in changing now if it's just my opinion. >>> >>> There are situations where an empty password is ok (say >>> when I'm not "protecting" something but just want to know >>> what user's profile to use, e.g. for weather) and that is >>> supported in many systems (that hence won't be able to >>> exactly adopt this) and insisting on a non-empty password >>> could be more damaging than allowing a zero-length >>> password, whenever a user re-uses a password for something >>> for which no password is really needed (and which hence is >>> less likely to be well protected) and where that password >>> is also used to protect something of significantly higher >>> value. The zero-length password is also not an interesting >>> subset of the set of stupid passwords really so doesn't >>> deserve to be called out as such (and you say that in the >>> draft when you talk about length-1 passwords.) So I think >>> allowing zero length passwords is better overall, and more >>> consistent with implementations. >> >> I see your point. Do you have a sense of what kind of systems today >> allow zero-length passwords? Given that RFC 4013 prohibited zero-length >> passwords and that they provide no security whatsoever, I don't see a >> compelling reason to modify the recommendation. However, as you say this >> document doesn't provide general guidance on password strengthy anyway, >> so I suppose I'd be fine with changing it to SHOULD NOT as long as we >> provide some text about why zero-length passwords are acceptable in some >> existing systems. > > I think most operating systems either allow empty passwords > or else try insist on what they think is "strong" or else > give some strength feedback to the user. Many CLI tools allow > for empty passwords in case they're used in a script and > the same goes for passwords needed by servers that might > ever need to restart without a human. (And yes in most cases > such tools provide a way to input a password from e.g. a > file, but that's often no more secure than no password > given how filesystem access control works.) > > I'll leave it to you folks to decide if you think a SHOULD > NOT is ok or not, but I suspect you might want to check that > the WG are ok with that change from 4013. Most definitely. > I suppose an alternative might be to just note some of > the issues above and say that in a bunch of cases an > application will have to accept as input either > or . I guess that's what's done now in any case > and I'd be fine with handling it that way too if you prefer. Ah, true. That seems preferable to me. Let's see if Alexey and I can formulate some text... Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed May 27 08:44:43 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C611B2B81 for ; Wed, 27 May 2015 08:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 WvWZuQRQeKnR for ; Wed, 27 May 2015 08:44:38 -0700 (PDT) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) (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 521CE1B2CD5 for ; Wed, 27 May 2015 08:44:33 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so90549518igb.1 for ; Wed, 27 May 2015 08:44:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uWORLCwbAAZZj6usX6bYEUauOsXS7qaTUZEoUaXlGDc=; b=j6ma9TqvX8dYFnk4Han6PV6CSDHE5k3kOfvFFgYdDyycQuyW6fm/0TFnM34X8lNkUx DnVRFGQuS6MrbGA/Na9QRiFNvPC7IxjR8sgbLMY9VXsf4U7IQd8q9Ed+9dgRlc1zwMHP D5OD8nF1PDKuAFNH0RyyoxP6LuIJ+QQ6c2knw9vsGMsw4EWaZSWYZY9urRVN2TksTFe7 WeEPi0Q6aUgTJE1USK5N+kYtwpLikdtyus3TQ/cNPc0L2e88woMad5EUXV+qUBBKhKQK Nl4qarfG5NXbY5Mul0eeA2V6PFIZUQYbIc/F2zPOdqdAkXddCDJA3DHOtOx6x+ILYbsJ L4oQ== X-Gm-Message-State: ALoCoQl0AGfVYsb/alYQnIbO8o2QKDCGGTXTBUOirCHVSObVWPx1MecZTSvJFpeXE/6nrhPsIlhe X-Received: by 10.50.59.211 with SMTP id b19mr37338212igr.42.1432741472496; Wed, 27 May 2015 08:44:32 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id ot6sm2046713igb.11.2015.05.27.08.44.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 May 2015 08:44:31 -0700 (PDT) Message-ID: <5565E65D.9030605@andyet.net> Date: Wed, 27 May 2015 09:44:29 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Stephen Farrell , The IESG References: <20150527132109.25645.76593.idtracker@ietfa.amsl.com> <5565DB7E.6080508@andyet.net> <5565DEF5.6090405@cs.tcd.ie> <5565E295.1010505@andyet.net> In-Reply-To: <5565E295.1010505@andyet.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-precis-saslprepbis@ietf.org, precis@ietf.org, draft-ietf-precis-saslprepbis.ad@ietf.org, precis-chairs@ietf.org, draft-ietf-precis-saslprepbis.shepherd@ietf.org Subject: Re: [precis] Stephen Farrell's No Objection on draft-ietf-precis-saslprepbis-17: (with COMMENT) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 15:44:40 -0000 On 5/27/15 9:28 AM, Peter Saint-Andre - &yet wrote: > On 5/27/15 9:12 AM, Stephen Farrell wrote: >> >> On 27/05/15 15:58, Peter Saint-Andre - &yet wrote: >>> On 5/27/15 7:21 AM, Stephen Farrell wrote: >>>> Stephen Farrell has entered the following ballot position for >>>> draft-ietf-precis-saslprepbis-17: No Objection >>>> 4.1: zero length password - I think you're wrong on that >>>> one but it is arguable. This was a discuss until you told >>>> me that 4013 prohibited 'em too so probably no point >>>> in changing now if it's just my opinion. >>>> >>>> There are situations where an empty password is ok (say >>>> when I'm not "protecting" something but just want to know >>>> what user's profile to use, e.g. for weather) and that is >>>> supported in many systems (that hence won't be able to >>>> exactly adopt this) and insisting on a non-empty password >>>> could be more damaging than allowing a zero-length >>>> password, whenever a user re-uses a password for something >>>> for which no password is really needed (and which hence is >>>> less likely to be well protected) and where that password >>>> is also used to protect something of significantly higher >>>> value. The zero-length password is also not an interesting >>>> subset of the set of stupid passwords really so doesn't >>>> deserve to be called out as such (and you say that in the >>>> draft when you talk about length-1 passwords.) So I think >>>> allowing zero length passwords is better overall, and more >>>> consistent with implementations. >>> >>> I see your point. Do you have a sense of what kind of systems today >>> allow zero-length passwords? Given that RFC 4013 prohibited zero-length >>> passwords and that they provide no security whatsoever, I don't see a >>> compelling reason to modify the recommendation. However, as you say this >>> document doesn't provide general guidance on password strengthy anyway, >>> so I suppose I'd be fine with changing it to SHOULD NOT as long as we >>> provide some text about why zero-length passwords are acceptable in some >>> existing systems. >> >> I think most operating systems either allow empty passwords >> or else try insist on what they think is "strong" or else >> give some strength feedback to the user. Many CLI tools allow >> for empty passwords in case they're used in a script and >> the same goes for passwords needed by servers that might >> ever need to restart without a human. (And yes in most cases >> such tools provide a way to input a password from e.g. a >> file, but that's often no more secure than no password >> given how filesystem access control works.) >> >> I'll leave it to you folks to decide if you think a SHOULD >> NOT is ok or not, but I suspect you might want to check that >> the WG are ok with that change from 4013. > > Most definitely. > >> I suppose an alternative might be to just note some of >> the issues above and say that in a bunch of cases an >> application will have to accept as input either >> or . I guess that's what's done now in any case >> and I'd be fine with handling it that way too if you prefer. > > Ah, true. That seems preferable to me. > > Let's see if Alexey and I can formulate some text... How's this? (I haven't checked it with Alexey yet but he can reply here.) OLD Note: The prohibition on zero-length passwords is not a recommendation regarding password strength (since a password of only one byte is highly insecure), but is meant to prevent applications from omitting a password entirely. NEW Note: Some existing systems allow an empty string in places where a password would be expected (e.g., command-line tools that might be called from an automated script, or servers that might need to be restarted without human intervention). From the perspective of this document (and RFC 4013 before it), these empty strings are not passwords but are workarounds for the practical difficulty of using passwords in certain scenarios. The prohibition on zero- length passwords is not a recommendation regarding password strength (since a password of only one byte is highly insecure), but is meant to prevent applications from mistakenly omitting a password entirely, since when internationalized characters are accepted a non-empty sequence of characters can result in a zero- length password after canonicalization. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed May 27 08:47:18 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B36F1B2CD5; Wed, 27 May 2015 08:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 d3umGlxTrJaM; Wed, 27 May 2015 08:47:11 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [217.34.220.150]) by ietfa.amsl.com (Postfix) with ESMTP id 954791B2D72; Wed, 27 May 2015 08:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1432741629; d=isode.com; s=selector; i=@isode.com; bh=Da6tJB8zeMF/IA+Uy9f9u4wLjQB0k6Io/Wl5DD/TiyQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Sie9wFJ7nwdDp7z5GOfcDnv20oKqNXpj5u/MOLN7amGe7ThROjO1TR6qKGA1N7OFx3J2rB FaAgqpyUpEgCLv75zZqalyo+eb4JS9p3rnqllg2dEGyJ2iItyGsnd8RfsAlLcSpK9QH72b Vi2IdEQ9LY3Ko1bv/MgKgMyL03kuvTM=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 27 May 2015 16:47:09 +0100 Message-ID: <5565E6EB.7010505@isode.com> Date: Wed, 27 May 2015 16:46:51 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 To: Peter Saint-Andre - &yet , Stephen Farrell , The IESG References: <20150527132109.25645.76593.idtracker@ietfa.amsl.com> <5565DB7E.6080508@andyet.net> <5565DEF5.6090405@cs.tcd.ie> <5565E295.1010505@andyet.net> <5565E65D.9030605@andyet.net> In-Reply-To: <5565E65D.9030605@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-precis-saslprepbis.ad@ietf.org, precis-chairs@ietf.org, precis@ietf.org, draft-ietf-precis-saslprepbis@ietf.org, draft-ietf-precis-saslprepbis.shepherd@ietf.org Subject: Re: [precis] Stephen Farrell's No Objection on draft-ietf-precis-saslprepbis-17: (with COMMENT) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 15:47:13 -0000 On 27/05/2015 16:44, Peter Saint-Andre - &yet wrote: > On 5/27/15 9:28 AM, Peter Saint-Andre - &yet wrote: >> On 5/27/15 9:12 AM, Stephen Farrell wrote: >>> >>> On 27/05/15 15:58, Peter Saint-Andre - &yet wrote: >>>> On 5/27/15 7:21 AM, Stephen Farrell wrote: >>>>> Stephen Farrell has entered the following ballot position for >>>>> draft-ietf-precis-saslprepbis-17: No Objection > > > >>>>> 4.1: zero length password - I think you're wrong on that >>>>> one but it is arguable. This was a discuss until you told >>>>> me that 4013 prohibited 'em too so probably no point >>>>> in changing now if it's just my opinion. >>>>> >>>>> There are situations where an empty password is ok (say >>>>> when I'm not "protecting" something but just want to know >>>>> what user's profile to use, e.g. for weather) and that is >>>>> supported in many systems (that hence won't be able to >>>>> exactly adopt this) and insisting on a non-empty password >>>>> could be more damaging than allowing a zero-length >>>>> password, whenever a user re-uses a password for something >>>>> for which no password is really needed (and which hence is >>>>> less likely to be well protected) and where that password >>>>> is also used to protect something of significantly higher >>>>> value. The zero-length password is also not an interesting >>>>> subset of the set of stupid passwords really so doesn't >>>>> deserve to be called out as such (and you say that in the >>>>> draft when you talk about length-1 passwords.) So I think >>>>> allowing zero length passwords is better overall, and more >>>>> consistent with implementations. >>>> >>>> I see your point. Do you have a sense of what kind of systems today >>>> allow zero-length passwords? Given that RFC 4013 prohibited >>>> zero-length >>>> passwords and that they provide no security whatsoever, I don't see a >>>> compelling reason to modify the recommendation. However, as you say >>>> this >>>> document doesn't provide general guidance on password strengthy >>>> anyway, >>>> so I suppose I'd be fine with changing it to SHOULD NOT as long as we >>>> provide some text about why zero-length passwords are acceptable in >>>> some >>>> existing systems. >>> >>> I think most operating systems either allow empty passwords >>> or else try insist on what they think is "strong" or else >>> give some strength feedback to the user. Many CLI tools allow >>> for empty passwords in case they're used in a script and >>> the same goes for passwords needed by servers that might >>> ever need to restart without a human. (And yes in most cases >>> such tools provide a way to input a password from e.g. a >>> file, but that's often no more secure than no password >>> given how filesystem access control works.) >>> >>> I'll leave it to you folks to decide if you think a SHOULD >>> NOT is ok or not, but I suspect you might want to check that >>> the WG are ok with that change from 4013. >> >> Most definitely. >> >>> I suppose an alternative might be to just note some of >>> the issues above and say that in a bunch of cases an >>> application will have to accept as input either >>> or . I guess that's what's done now in any case >>> and I'd be fine with handling it that way too if you prefer. >> >> Ah, true. That seems preferable to me. Agreed. >> Let's see if Alexey and I can formulate some text... > > How's this? (I haven't checked it with Alexey yet but he can reply here.) > > OLD > Note: The prohibition on zero-length passwords is not a > recommendation regarding password strength (since a password of > only one byte is highly insecure), but is meant to prevent > applications from omitting a password entirely. > > NEW > Note: Some existing systems allow an empty string in places where > a password would be expected (e.g., command-line tools that might > be called from an automated script, or servers that might need to > be restarted without human intervention). From the perspective of > this document (and RFC 4013 before it), these empty strings are > not passwords but are workarounds for the practical difficulty of > using passwords in certain scenarios. The prohibition on zero- > length passwords is not a recommendation regarding password > strength (since a password of only one byte is highly insecure), > but is meant to prevent applications from mistakenly omitting a > password entirely, since when internationalized characters are > accepted a non-empty sequence of characters can result in a zero- > length password after canonicalization. Yes, this looks great. Thank you! From nobody Wed May 27 09:06:36 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041C21A1AFB; Wed, 27 May 2015 09:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 eHoxAFg2Vnjc; Wed, 27 May 2015 09:06:33 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 113381A1AE3; Wed, 27 May 2015 09:06:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5CA12BEE7; Wed, 27 May 2015 17:06:30 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlotBtQ9MAEC; Wed, 27 May 2015 17:06:30 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 173EDBEE1; Wed, 27 May 2015 17:06:30 +0100 (IST) Message-ID: <5565EB85.2060407@cs.tcd.ie> Date: Wed, 27 May 2015 17:06:29 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Alexey Melnikov , Peter Saint-Andre - &yet , The IESG References: <20150527132109.25645.76593.idtracker@ietfa.amsl.com> <5565DB7E.6080508@andyet.net> <5565DEF5.6090405@cs.tcd.ie> <5565E295.1010505@andyet.net> <5565E65D.9030605@andyet.net> <5565E6EB.7010505@isode.com> In-Reply-To: <5565E6EB.7010505@isode.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-precis-saslprepbis.ad@ietf.org, precis-chairs@ietf.org, precis@ietf.org, draft-ietf-precis-saslprepbis@ietf.org, draft-ietf-precis-saslprepbis.shepherd@ietf.org Subject: Re: [precis] Stephen Farrell's No Objection on draft-ietf-precis-saslprepbis-17: (with COMMENT) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 16:06:35 -0000 On 27/05/15 16:46, Alexey Melnikov wrote: >> >> NEW >> Note: Some existing systems allow an empty string in places where >> a password would be expected (e.g., command-line tools that might >> be called from an automated script, or servers that might need to >> be restarted without human intervention). From the perspective of >> this document (and RFC 4013 before it), these empty strings are >> not passwords but are workarounds for the practical difficulty of >> using passwords in certain scenarios. The prohibition on zero- >> length passwords is not a recommendation regarding password >> strength (since a password of only one byte is highly insecure), >> but is meant to prevent applications from mistakenly omitting a >> password entirely, since when internationalized characters are >> accepted a non-empty sequence of characters can result in a zero- >> length password after canonicalization. > Yes, this looks great. Thank you! Same here. That's a fine addition I think. Cheers, S. From nobody Wed May 27 09:19:27 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBCC1A1F00 for ; Wed, 27 May 2015 09:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 CG7U5uZRKTvO for ; Wed, 27 May 2015 09:19:22 -0700 (PDT) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (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 C63311A1EEA for ; Wed, 27 May 2015 09:19:19 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so89183030igb.1 for ; Wed, 27 May 2015 09:19:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uo2RrwJ2o3jWDm7uy+V0m6BDuJy76p4M+zbjkWn3q5k=; b=gEpc1fwyRRI0AWGzySt0URAs5IxzfPZO3jMf4pjYd3OwK6RB2xBOQNq5JHeGIkJHza VXR+bdKja7msgmjoqdwRHAPPrJw53ph1sJd5U5n18OJvNBQtd/uDxTXWed66pSORhHFL KJ/6XDvM5KdyXK6leNH80PjVJSMzfb8QF/pYew4E4tRGP/SEAZC/7+wpYsd4cVhxYPzu Bo8e/0cBKVkF3JOloK9RzRpM4bcR1IUl7x7MSxtfd6ElwTETJ06CSDDcRiSpIbvXIYze mXwS4PRd4IWI6PwZtIkB6D0X9wEkieovD4NDewIRYxB6E68zyvwXQuMqZ/VDoUaMHfVs 4dng== X-Gm-Message-State: ALoCoQl7IgzUK5vssPpDHX27YCmVpYtIiiofdCWEEZXR/eIIoh4+rK0JD2kp28LeZ03fceTDBxXs X-Received: by 10.42.52.4 with SMTP id h4mr4631283icg.32.1432743559302; Wed, 27 May 2015 09:19:19 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id n14sm13815704ion.5.2015.05.27.09.19.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 May 2015 09:19:17 -0700 (PDT) Message-ID: <5565EE83.6070007@andyet.net> Date: Wed, 27 May 2015 10:19:15 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Stephen Farrell , Alexey Melnikov , The IESG References: <20150527132109.25645.76593.idtracker@ietfa.amsl.com> <5565DB7E.6080508@andyet.net> <5565DEF5.6090405@cs.tcd.ie> <5565E295.1010505@andyet.net> <5565E65D.9030605@andyet.net> <5565E6EB.7010505@isode.com> <5565EB85.2060407@cs.tcd.ie> In-Reply-To: <5565EB85.2060407@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-precis-saslprepbis.ad@ietf.org, precis-chairs@ietf.org, precis@ietf.org, draft-ietf-precis-saslprepbis@ietf.org, draft-ietf-precis-saslprepbis.shepherd@ietf.org Subject: Re: [precis] Stephen Farrell's No Objection on draft-ietf-precis-saslprepbis-17: (with COMMENT) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 16:19:23 -0000 On 5/27/15 10:06 AM, Stephen Farrell wrote: > > > On 27/05/15 16:46, Alexey Melnikov wrote: >>> >>> NEW >>> Note: Some existing systems allow an empty string in places where >>> a password would be expected (e.g., command-line tools that might >>> be called from an automated script, or servers that might need to >>> be restarted without human intervention). From the perspective of >>> this document (and RFC 4013 before it), these empty strings are >>> not passwords but are workarounds for the practical difficulty of >>> using passwords in certain scenarios. The prohibition on zero- >>> length passwords is not a recommendation regarding password >>> strength (since a password of only one byte is highly insecure), >>> but is meant to prevent applications from mistakenly omitting a >>> password entirely, since when internationalized characters are >>> accepted a non-empty sequence of characters can result in a zero- >>> length password after canonicalization. >> Yes, this looks great. Thank you! > > Same here. That's a fine addition I think. OK, we'll submit a revised I-D after the telechat. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu May 28 09:10:14 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909211B2C33; Thu, 28 May 2015 09:10:10 -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] autolearn=ham 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 Py9LMIPnGhWZ; Thu, 28 May 2015 09:10:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 382261B2C2F; Thu, 28 May 2015 09:09:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150528160954.20931.730.idtracker@ietfa.amsl.com> Date: Thu, 28 May 2015 09:09:54 -0700 Archived-At: Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-saslprepbis-18.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 16:10:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. Title : Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords Authors : Peter Saint-Andre Alexey Melnikov Filename : draft-ietf-precis-saslprepbis-18.txt Pages : 23 Date : 2015-05-28 Abstract: This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454). The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. The PRECIS framework, RFC 7564, obsoletes RFC 3454, and this document obsoletes RFC 4013. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-precis-saslprepbis-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-precis-saslprepbis-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 28 09:11:04 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA691B2C36 for ; Thu, 28 May 2015 09:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Zo9w51Nr5Vkl for ; Thu, 28 May 2015 09:11:01 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 833111B2C1E for ; Thu, 28 May 2015 09:10:54 -0700 (PDT) Received: from [206.123.31.98] (kuwa.viagenie.ca [206.123.31.98]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 717C0403F8 for ; Thu, 28 May 2015 12:10:56 -0400 (EDT) From: "Marc Blanchet" To: precis@ietf.org Date: Thu, 28 May 2015 12:10:43 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate Trial (1.9.1r5084) Archived-At: Subject: [precis] meeting in Prague? X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 28 May 2015 16:11:02 -0000 The co-chairs do not currently plan to request a meeting slot for next IETF in Prague. Do people have any topic to discuss that requires f2f time in Prague? Regards, Marc. From nobody Thu May 28 09:19:27 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1881E1B2B70 for ; Thu, 28 May 2015 09:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 PiWCGAfPAMo2 for ; Thu, 28 May 2015 09:19:23 -0700 (PDT) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (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 7FF9A1B2ADA for ; Thu, 28 May 2015 09:19:23 -0700 (PDT) Received: by igbsb11 with SMTP id sb11so43420622igb.0 for ; Thu, 28 May 2015 09:19:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vCd3nVvuJXoa1QuKX3DyJnwO8BUC1e5QRxKoAISqOEM=; b=OG7y1JGf0OywAKAUk7e2imur9SLtHwlBSERBqncFYhFU1kYe/oQAT4pjf76PGy5HRT HiS5Nn6WoigvgllXyg1jx0lot7dnNrha3GS4ga7BQQMe0R2lQ9GjYk4qIeHO1PG7pZ4l rMzOTrfLHfwjWSQe8T4XkWl61L3/tFWE2/dW65vojwIqetV5S8FlL2Orug/JMgtlpj3R qmKvjTchwuBllw3/AjJemoghlB0f5qZQEYcOeQv/VepfBYMzhUKbvwTYb2YUep5IrIS/ K9X7VdqaVcha91pHUchvCShTpvMesvF1h2ZokDy+i5QJ9Aoe7lBY6cWKEveG9zCteiMB XI1w== X-Gm-Message-State: ALoCoQk0U8UK5ns8DzZejftxr2g+NkqZRP/iLwSkUEcMS9wmzNElVEAgVFX8a9GPcDvoNZx9Eqbn X-Received: by 10.42.233.142 with SMTP id jy14mr10320162icb.55.1432829962907; Thu, 28 May 2015 09:19:22 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id w4sm2403575igl.22.2015.05.28.09.19.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 May 2015 09:19:22 -0700 (PDT) Message-ID: <55674008.3030509@andyet.net> Date: Thu, 28 May 2015 10:19:20 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: precis@ietf.org References: <20150528160954.20931.730.idtracker@ietfa.amsl.com> In-Reply-To: <20150528160954.20931.730.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [precis] I-D Action: draft-ietf-precis-saslprepbis-18.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 28 May 2015 16:19:25 -0000 Some relatively small changes to address IESG feedback. On 5/28/15 10:09 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. > > Title : Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords > Authors : Peter Saint-Andre > Alexey Melnikov > Filename : draft-ietf-precis-saslprepbis-18.txt > Pages : 23 > Date : 2015-05-28 > > Abstract: > This document describes updated methods for handling Unicode strings > representing usernames and passwords. The previous approach was > known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454). > The methods specified in this document provide a more sustainable > approach to the handling of internationalized usernames and > passwords. The PRECIS framework, RFC 7564, obsoletes RFC 3454, and > this document obsoletes RFC 4013. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-precis-saslprepbis-18 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-precis-saslprepbis-18 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis > From nobody Thu May 28 09:31:28 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C231A893C for ; Thu, 28 May 2015 09:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 pqZpM2prFU5H for ; Thu, 28 May 2015 09:31:25 -0700 (PDT) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) (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 3B3EC1A001B for ; Thu, 28 May 2015 09:31:25 -0700 (PDT) Received: by igbsb11 with SMTP id sb11so43702664igb.0 for ; Thu, 28 May 2015 09:31:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lc6qg6nQW69USr6HT1QiAVH8n6Nl2yBFpCYLFS38y1w=; b=K1b0BAHAtDBx7Mehd8GJ/wQu9ZnJnzk/gDGqLP4lc9/WR4TN2yIrJ4jvsP0WErGfol 099rW97PH98dtNLjBpJDPzmhTda6YtQ5Y8UKkJUIkjVa8t8M8F4zl3cal0ECvInfcvAc EBGCEg0jj41kkDkYSNlG93t01cidp4u2Sgl/vwoKFdLuOu5WwvRwAJ6iDJ8NSv0BKdTU kV03ILX9TP80gYqYlqHyNbA7ksnuSLQPP++3bIhmxCKdPK8r0mF4heT1wFhvZ/TSSgdT pwSgUw88DEo6tn43//z247FTN885LwFsctdYYHkOuq3Uzat3KuEr1yyOc5raa/0YGtC8 MpxA== X-Gm-Message-State: ALoCoQkRPzYLmIe15lO+y3IRd4hCWDtyTPfAVfuJpsw8xUOG8OAiKOYTqQlKwIicXiCzPJyr5afF X-Received: by 10.50.117.106 with SMTP id kd10mr15632661igb.24.1432830684709; Thu, 28 May 2015 09:31:24 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id vk8sm4644907igb.4.2015.05.28.09.31.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 May 2015 09:31:23 -0700 (PDT) Message-ID: <556742D8.4060902@andyet.net> Date: Thu, 28 May 2015 10:31:20 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Marc Blanchet , precis@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [precis] meeting in Prague? X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 28 May 2015 16:31:26 -0000 On 5/28/15 10:10 AM, Marc Blanchet wrote: > The co-chairs do not currently plan to request a meeting slot for next > IETF in Prague. Do people have any topic to discuss that requires f2f > time in Prague? Hi Marc! Well, our documents are moving forward: RFC 7564 has been published draft-ietf-precis-saslprepbis was approved on the IESG telechat today draft-ietf-precis-nickname is waiting on a shepherd writeup draft-ietf-precis-mappings has finished WGLC So that's progress! I suppose we could have a discussion in Prague about next steps, especially how we can encourage other application protocols (Stringprep "customers") to migrate to PRECIS. We've somewhat expected that to happen after the PRECIS WG closes down, so there are perhaps some logistical and expert review issues to figure out. Peter From nobody Fri May 29 13:20:02 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260821A8770; Fri, 29 May 2015 13:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] 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 pZPqD30iS2G1; Fri, 29 May 2015 13:19:57 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 098951A8757; Fri, 29 May 2015 13:19:56 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t4TKJoLq008839 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 29 May 2015 22:19:51 +0200 From: Simon Josefsson To: Stephen Farrell References: <20150527125619.24017.77007.idtracker@ietfa.amsl.com> <5565C153.1030708@isode.com> <5565C31C.3020309@cs.tcd.ie> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150529:precis@ietf.org::rbJ3baB6aGm+JxhN:1hm/ X-Hashcash: 1:22:150529:draft-ietf-precis-saslprepbis@ietf.org::+1QRru2tkRAlKBA9:2mwT X-Hashcash: 1:22:150529:draft-ietf-precis-saslprepbis.ad@ietf.org::PO5FezJsok25CPK1:2i+W X-Hashcash: 1:22:150529:iesg@ietf.org::ojmsdMNL2zstJA/2:76Yg X-Hashcash: 1:22:150529:draft-ietf-precis-saslprepbis.shepherd@ietf.org::FHrVt0IzOLaGShN1:A2DI X-Hashcash: 1:22:150529:stephen.farrell@cs.tcd.ie::5XJGzgpjSyp6lCKk:AI/P X-Hashcash: 1:22:150529:precis-chairs@ietf.org::JCJWB6DMCYGHAWB4:DdjS X-Hashcash: 1:22:150529:alexey.melnikov@isode.com::3mVokO+ICyaMgG/6:Si/k Date: Fri, 29 May 2015 22:19:49 +0200 In-Reply-To: <5565C31C.3020309@cs.tcd.ie> (Stephen Farrell's message of "Wed, 27 May 2015 14:14:04 +0100") Message-ID: <87h9qvxhju.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: draft-ietf-precis-saslprepbis@ietf.org, precis@ietf.org, The IESG , draft-ietf-precis-saslprepbis.ad@ietf.org, precis-chairs@ietf.org, draft-ietf-precis-saslprepbis.shepherd@ietf.org Subject: Re: [precis] Stephen Farrell's Discuss on draft-ietf-precis-saslprepbis-17: (with DISCUSS and COMMENT) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 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, 29 May 2015 20:19:58 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Stephen Farrell writes: > Hiya, > > On 27/05/15 14:06, Alexey Melnikov wrote: >> Hi Stephen, >>=20 >> On 27/05/2015 13:56, Stephen Farrell wrote: >> [...] >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> >>> 4.1: zero length password - I think you're wrong on that >>> one but it is arguable. If RFC4013 also prohibited zero >>> length passwords (I couldn't tell at a quick glance) >> Yes, zero length password was always prohibited by RFC 4013. If you look >> at various RFCs that reference SASLPrep, they say "if the password is >> invalid or zero length after applying SASLPrep normalization, then >> reject it" (or similar words). > > That wins. I'll clear the discuss and make this a comment. I question if this is correct -- my SASLprep implementation accepts zero length passwords. Where in RFC 4013 is the requirement to reject them? I think Stephen's thoughts around empty passwords makes a lot of sense. Empty passwords are used in many places, for good or bad. I'm certain that not all RFCs that refer to SASLprep has the wording above. RFC 5802 (SCRAM) doesn't, as far as I can tell, for example. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVaMnlAAoJEIYLf7sy+BGdmpYIAJgZpSMQ9ulO6ywXyMyTiX2e QCVUDT78TMmxh8YOqt/5oKAODCIRcVnu075ycL9A2+GwnomuQsa3a29SjO7ZzW9C mw2jZcc10I/QEQixaSvQfzRc0XRLmH7sCg4Tk3fRJYdk99ajlBaVKMcFAk2y6hLc v7Tkcooi/PxiIrhksOB6my6S+xQvIDG35gSAUjnLAoikI+SH08NBsHFsVwGkH4GS jYcRZWAZm48iWuLAlp/PUREw9WymbGJOr8oFMiwlKN5VCbAGsamYMAqrPRWzONM2 QBrIV/U840icVWZKJdZshAtQ/QNnp/s9Ilbb9mvwlQ8gidnHR++MC2hSR137liw= =dzXz -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat May 30 10:18:49 2015 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9876C1A9042; Sat, 30 May 2015 10:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 04TwTeN1IMiL; Sat, 30 May 2015 10:18:46 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [217.34.220.151]) by ietfa.amsl.com (Postfix) with ESMTP id 5462C1A9045; Sat, 30 May 2015 10:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1433006325; d=isode.com; s=selector; i=@isode.com; bh=IbmlZX5iPiUbe6e2C6O3MzDJbHSK7jGnizb3CGHan+A=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=X2DYWOiMnZOJf1tVQjNQXD9pnJXnfevgtcovLaVWs2Tnp8YUgZ36QDcazBx08Z6teNJsL9 8zB9lBo9dGO5Q9fy88bjNySPlDq4kRyJYyQFpfZPTQWOrk7VjrF/jEKx/t9nIN10gnMxpD YejvKhFrH2Ixhqcfncb54fGkkuc9Y4Y=; Received: from [192.168.0.6] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 30 May 2015 18:18:44 +0100 X-SMTP-Protocol-Errors: PIPELINING From: Alexey Melnikov X-Mailer: iPad Mail (12F69) In-Reply-To: <87h9qvxhju.fsf@latte.josefsson.org> Date: Sat, 30 May 2015 18:19:40 +0100 Message-Id: References: <20150527125619.24017.77007.idtracker@ietfa.amsl.com> <5565C153.1030708@isode.com> <5565C31C.3020309@cs.tcd.ie> <87h9qvxhju.fsf@latte.josefsson.org> To: Simon Josefsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "draft-ietf-precis-saslprepbis@ietf.org" , "precis@ietf.org" , The IESG , "draft-ietf-precis-saslprepbis.ad@ietf.org" , "precis-chairs@ietf.org" , "draft-ietf-precis-saslprepbis.shepherd@ietf.org" , Stephen Farrell Subject: Re: [precis] Stephen Farrell's Discuss on draft-ietf-precis-saslprepbis-17: (with DISCUSS and COMMENT) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2015 17:18:47 -0000 Hi Simon, > On 29 May 2015, at 21:19, Simon Josefsson wrote: >=20 > Stephen Farrell writes: >=20 >> Hiya, >>=20 >>> On 27/05/15 14:06, Alexey Melnikov wrote: >>> Hi Stephen, >>>=20 >>>> On 27/05/2015 13:56, Stephen Farrell wrote: >>>> [...] >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>>=20 >>>>=20 >>>> 4.1: zero length password - I think you're wrong on that >>>> one but it is arguable. If RFC4013 also prohibited zero >>>> length passwords (I couldn't tell at a quick glance) >>> Yes, zero length password was always prohibited by RFC 4013. If you look= >>> at various RFCs that reference SASLPrep, they say "if the password is >>> invalid or zero length after applying SASLPrep normalization, then >>> reject it" (or similar words). >>=20 >> That wins. I'll clear the discuss and make this a comment. >=20 > I question if this is correct -- my SASLprep implementation accepts zero > length passwords. Where in RFC 4013 is the requirement to reject them? SASL PLAIN and SCRAM have relevant text (in case of SCRAM, this only applies= to usernames, but they are the same SASLPrep profile, so I think the lack o= f similar text for passwords was not intentional)=20 >=20 > I think Stephen's thoughts around empty passwords makes a lot of sense. > Empty passwords are used in many places, for good or bad. >=20 > I'm certain that not all RFCs that refer to SASLprep has the wording > above. RFC 5802 (SCRAM) doesn't, as far as I can tell, for example. See above.=