Re: [secdir] Use of StringPrep/Unicode (was Re: SecDir and AppsDir review of draft-ietf-storm-iscsi-cons-06)
"Black, David" <david.black@emc.com> Thu, 11 October 2012 15:10 UTC
Return-Path: <david.black@emc.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 C20EE21F86F0; Thu, 11 Oct 2012 08:10:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.642
X-Spam-Level:
X-Spam-Status: No, score=-103.642 tagged_above=-999 required=5 tests=[AWL=0.957, 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 qxBJimT8buJx; Thu, 11 Oct 2012 08:10:57 -0700 (PDT)
Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id A898421F86D4; Thu, 11 Oct 2012 08:10:57 -0700 (PDT)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q9BFAnXn002115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Oct 2012 11:10:53 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 11 Oct 2012 11:10:35 -0400
Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.222.70.203]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q9BFAKHs004204; Thu, 11 Oct 2012 11:10:29 -0400
Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub06.corp.emc.com ([128.222.70.203]) with mapi; Thu, 11 Oct 2012 11:08:14 -0400
From: "Black, David" <david.black@emc.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Date: Thu, 11 Oct 2012 11:08:13 -0400
Thread-Topic: Use of StringPrep/Unicode (was Re: SecDir and AppsDir review of draft-ietf-storm-iscsi-cons-06)
Thread-Index: Ac2nuGAbyZjkPXXESy2DU08CJJws+wABPMdA
Message-ID: <8D3D17ACE214DC429325B2B98F3AE7120DFAEA08@MX15A.corp.emc.com>
References: <4FBFAE5F.8010305@gmail.com> <506C43AA.9010206@isode.com> <E160851FCED17643AE5F53B5D4D0783A4C410C95@BL2PRD0610MB361.namprd06.prod.outlook.com> <5076AEDB.7030900@isode.com> <8D3D17ACE214DC429325B2B98F3AE7120DFAE9D4@MX15A.corp.emc.com> <5076D036.3060602@isode.com>
In-Reply-To: <5076D036.3060602@isode.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
X-Mailman-Approved-At: Thu, 11 Oct 2012 08:22:42 -0700
Cc: Mallikarjun Chadalapaka <cbm@chadalapaka.com>, "Black, David" <david.black@emc.com>, "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: Re: [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 15:10:58 -0000
Alexey - thank you for the quick response. I think we're aligned on these stringprep/Unicode concerns, and this should all get dealt with in the next version of the draft. I'm working through the rest of your review ... but (IMHO) a serious draft revision will be needed before it'll make sense for any of the Discuss positions to be cleared. Thanks, --David > -----Original Message----- > From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] > Sent: Thursday, October 11, 2012 9:57 AM > To: Black, David > Cc: Mallikarjun Chadalapaka; secdir@ietf.org; draft-ietf-storm-iscsi- > cons.all@tools.ietf.org; iesg@ietf.org > Subject: Re: Use of StringPrep/Unicode (was Re: SecDir and AppsDir review of > draft-ietf-storm-iscsi-cons-06) > > On 11/10/2012 14:35, Black, David wrote: > > Alexey, > Hi David, > > Thanks for splitting this out into a separate thread. More comments inline. > > > >> 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. > > > > "Unicode printable" is intended - the details are in 4.2.7.2 and the > > stringprep profile in RFC 3722. I would change "displayable characters" > > to "printable ASCII and Unicode characters". Yes, I know that ASCII is a > > subset of Unicode, but not every reader of this RFC will have that level > > of Unicode familiarity. > > Ok. > > >>>> 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? > > > > There's been a separate email exchange with Pete Resnick about this text. > > The conclusion is that the words "case sensitive" above are misleading, > > so the above sentence needs to be rewritten and expanded as follows: > > > > iSCSI names allow the use of international characters > > but uppercase characters are prohibited. The iSCSI stringprep > > profile [RFC3722] maps uppercase characters to lowercase and > > SHOULD be used to prepare iSCSI names from input that may > > include uppercase characters. > > This would be Ok, if you update the above to say ASCII or Unicode. No problem. > >>>> No whitespace characters are used in > >>>> iSCSI names. > >>>> > >>>> What is "whitespace". U+0020? (ASCII space) Something else? > >> Any comments on this? > > > > Something else - see RFC 3722, which specifies the explicit prohibitions > > beyond U+0020, specifically it prohibits the space characters in tables > > C.1.1 and C.1.2 from RFC 3454. If it helps, we could add ", see [RFC3722] > > for details" at the end of that sentence. > > Sounds good. > > >>>> 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. > > > > Alexey is correct about this one - that "MUST NOT" is too strong and not > > implementable, even though it's a "good idea" in principle. > > > > This text was originally intended as usage guidance on avoidance of > > characters that result in different strings that look the same or similar > > to humans. This is already a concern in ASCII (e.g., courtesy of l, 1, 0 > > and O), but is much more of a concern for Unicode. > > > > The sentence needs a rewrite as guidance that avoids using "MUST NOT", e.g.: > > > > iSCSI names are expected to be used by administrators for purposes > > such as system configuration - for this reason, characters that may > > lead to human confusion among different iSCSI names (e.g., punctuation, > > spacing, diacritical marks) should be avoided, even when such > > characters are allowed as stringprep processing output by [RFC3722]. > > Ok. This is not what I expected the replacement text to say, but this is > better. Right - that was a good catch, thank you. > > > The mandatory requirements on allowed vs. prohibited characters are in > > RFC 3722, and (IMHO) it's best to not expand on them here. > > > >>>> 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. > > > > Actually it is well-defined in RFC 3722 via its reference to table B.2 > > in RFC 3454. > > Well, it is only well defined if you say what it means ;-). Adding a > reference to B.2 from RFC 3454 would address this. Ok. > >>>> Also, "any character set"? This really doesn't look correct. > > > > OTOH, that's definitely not correct - "(any character set)" should just > > be deleted. This text was intended to refer to what Unicode calls a > > "script" and it's probably better to just not mention that concept here. > > > >>> [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. > > > > Unfortunately, that's not quite right, because the actual specification > > is what RFC 3722 allows via the tables in RFC 3454. Those RFC 3454 tables are > > definitive, as opposed to the Unicode specifications of character > > properties (which were used to generate those tables). > > > > The following text should get this right: > > > > The stringprep process does not need to be implemented if the > > names are generated using only characters allowed as output by > > the stringprep processing specified in [RFC3722]. Those allowed > > characters include all ASCII lowercase and numeric characters, > > as well as lowercase Unicode characters as specified in [RFC3722]. > > This new text is better and addresses my concern. (The whole paragraph > is sort of "if you are too lazy to implement StringPrep, this is what > you can safely use", but as long as this is correct, I don't mind.) Thank you for understanding that. > > The PRECIS work should allow a future update that uses the Unicode > > "Lowercase" property (and other Unicode) properties. > > Right. >
- [secdir] SecDir review of draft-camarillo-rai-med… Yaron Sheffer
- Re: [secdir] SecDir review of draft-camarillo-rai… Gonzalo Camarillo
- Re: [secdir] SecDir review of draft-camarillo-rai… Gonzalo Camarillo
- [secdir] SecDir review of draft-yegin-pana-encr-a… Yaron Sheffer
- [secdir] SecDir review of draft-ietf-krb-wg-kerbe… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-krb-wg-k… Sean Turner
- Re: [secdir] SecDir review of draft-ietf-krb-wg-k… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-krb-wg-k… Stephen Farrell
- Re: [secdir] SecDir review of draft-ietf-krb-wg-k… Sam Hartman
- Re: [secdir] SecDir review of draft-ietf-krb-wg-k… Tom Yu
- [secdir] SecDir and AppsDir review of draft-ietf-… Alexey Melnikov
- Re: [secdir] SecDir and AppsDir review of draft-i… Alexey Melnikov
- [secdir] Use of StringPrep/Unicode (was Re: SecDi… Alexey Melnikov
- Re: [secdir] Use of StringPrep/Unicode (was Re: S… Alexey Melnikov
- Re: [secdir] SecDir and AppsDir review of draft-i… Mallikarjun Chadalapaka
- Re: [secdir] SecDir and AppsDir review of draft-i… Mallikarjun Chadalapaka
- Re: [secdir] Use of StringPrep/Unicode (was Re: S… Black, David
- Re: [secdir] Use of StringPrep/Unicode (was Re: S… Black, David
- Re: [secdir] SecDir and AppsDir review of draft-i… Black, David
- Re: [secdir] SecDir and AppsDir review of draft-i… Alexey Melnikov
- Re: [secdir] SecDir and AppsDir review of draft-i… Mallikarjun Chadalapaka
- Re: [secdir] SecDir and AppsDir review of draft-i… Alexey Melnikov
- [secdir] SecDir review of draft-ietf-6renum-enter… Yaron Sheffer
- [secdir] SecDir repeat review of draft-ietf-6renu… Yaron Sheffer
- [secdir] SecDir review of draft-ietf-rtgwg-ipfrr-… Yaron Sheffer
- [secdir] SecDir review of draft-ietf-clue-telepre… Yaron Sheffer
- [secdir] SecDir review of draft-ietf-v6ops-64shar… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-v6ops-64… Vízdal Aleš
- Re: [secdir] SecDir review of draft-ietf-v6ops-64… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-v6ops-64… Vízdal Aleš