[secdir] Use of StringPrep/Unicode (was Re: SecDir and AppsDir review of draft-ietf-storm-iscsi-cons-06)

Alexey Melnikov <alexey.melnikov@isode.com> Thu, 11 October 2012 11:34 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3028D21F8611; Thu, 11 Oct 2012 04:34:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.33
X-Spam-Level:
X-Spam-Status: No, score=-103.33 tagged_above=-999 required=5 tests=[AWL=1.269, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfZAeuJlWnIU; Thu, 11 Oct 2012 04:34:49 -0700 (PDT)
Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2617D21F856F; Thu, 11 Oct 2012 04:34:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1349955287; d=isode.com; s=selector; i=@isode.com; bh=4VK3IEqzimh1EyEjibaRfdYvEiV+2EmkBtFi/+2mM1Q=; 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=QXN0FnNp9lOrfJHetXFi+n0IWliR0VotlCtwzFaWVgPNL7IB0QrH7EfIqF6EWrcWtvl4eb Uoxt05rm9nxjNigIs40wV3mc9FLn3E8sxizMRd5YYhtCaHSMzYmsdB1w6O55N5wRJPRqlr 5p7qEHY+dV9BK007m0h2sT7Rkhgu6zg=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id <UHau1QB4nphg@waldorf.isode.com>; Thu, 11 Oct 2012 12:34:47 +0100
Message-ID: <5076AEDB.7030900@isode.com>
Date: Thu, 11 Oct 2012 12:34:51 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
To: Mallikarjun Chadalapaka <cbm@chadalapaka.com>
References: <4FBFAE5F.8010305@gmail.com> <506C43AA.9010206@isode.com> <E160851FCED17643AE5F53B5D4D0783A4C410C95@BL2PRD0610MB361.namprd06.prod.outlook.com>
In-Reply-To: <E160851FCED17643AE5F53B5D4D0783A4C410C95@BL2PRD0610MB361.namprd06.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-storm-iscsi-cons.all@tools.ietf.org" <draft-ietf-storm-iscsi-cons.all@tools.ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: [secdir] Use of StringPrep/Unicode (was Re: SecDir and AppsDir review of draft-ietf-storm-iscsi-cons-06)
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Oct 2012 11:34:50 -0000

Hi,
Sorry for the delay with this reply.

On 09/10/2012 04:42, Mallikarjun Chadalapaka wrote:
>     all iSCSI implementations complying with this document. Protocol
>     behavior defined in this Section MUST be exhibited by iSCSI
>     implementations on an iSCSI session when they negotiate the
>     TaskReporting (Section 13.23) key to "FastAbort" on that session.
>     The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT
>     RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests
>     consists of the following sequence of actions in the specified
>     order on the specified party.
>
> In Section 4.2.7.1
>
>        iSCSI names are composed only of displayable characters.
>
> What does "displayable" means here? "ASCII printable"? "Unicode
> printable"?
> [Mallikarjun:] The latter. Note that all normative statements make it clear that we refer to Unicode-encoding - especially look at Section 4.2.7.2 where it discusses the stringprep-normalization. This section (4.2.7.1) is just a non-normative discussion of the user-visible characteristics.
At this point I haven't read 4.2.7.2 and it is not clear that this 
section is non normative. I wish you would use more standard terminology 
and/or forward references.
>>           iSCSI
>>           names allow the use of international character sets but are
>>           not case sensitive.
>>
>> What does this mean exactly? Do you mean ASCII case sensitivity? Unicode
>> case sensitivity?
>   [Mallikarjun:] See above
>
>>           No whitespace characters are used in
>>           iSCSI names.
>>
>> What is "whitespace". U+0020? (ASCII space) Something else?
Any comments on this?
>> 4.2.7.2. iSCSI Name Encoding
>>
>>     The stringprep process is described in [RFC3454]; iSCSI's use of
>>     the stringprep process is described in [RFC3722]. Stringprep is a
>>     method designed by the Internationalized Domain Name (IDN) working
>>     group to translate human-typed strings into a format that can be
>>     compared as opaque strings. Strings MUST NOT include punctuation,
>>     spacing, diacritical marks, or other characters that could get in
>>     the way of readability.
>>
>> This MUST NOT is not well defined. You need to define specific Unicode
>> codepoints or character classes.
> [Mallikarjun:] Given the number of scripts that Unicode supports, this does not strike me a trivial exercise. I suspect that's why the original ips WG left it as such, and this level of specificity has worked well for over a decade. However, I am not a Unicode expert at all, so I may be overlooking something obvious you have in mind?
Unicode Consortium has defined classes of characters (e.g. "letters", 
"digits", "punctuation", etc.). You can just reference such classes.
Happy to try to suggest some text or find a person who can help you 
reword this.

Without specific details your MUST NOT is not implementable and not 
enforceable. Worse, I suspect nobody has implemented it anyway. I think 
your choices are: (a) delete the sentence as it is not useful or (b) fix 
it so that it actually ensures interoperability.
>>     The stringprep process also converts
>>     strings into equivalent strings of lower-case characters.
>>
>>
>>     The stringprep process does not need to be implemented if the
>>     names are only generated using numeric and lower-case (any
>>     character set) alphabetic characters.
>>
>> Lower-case is not well defined, unless you say you mean ASCII or
>> something else.
>> Also, "any character set"? This really doesn't look correct.
>   [Mallikarjun:] The entire iSCSI Name discussion is in the context of Unicode, and it is called out in normative sentences in appropriate places. This is non-normative descriptive text. OTOH, if you have specific suggestions, they are welcome.
I think you meant to write:

    The stringprep process does not need to be implemented if the
    names are only generated using ASCII numeric and Unicode characters with "Lowercase" property.