Subject: [precis] Late comments on problem-statement-06

From: <[email-masked]>
Date: Fri, 3 Aug 2012 12:04:51 -0400

I've finally been able to take a look at the problem-statement-06 draft,
primarily to check the iSCSI material, but I also took a look at the main
portion of the draft.  I have a few comments, and greatly appreciate the
patience of the authors and WG chairs in being willing to look at these
after WG Last Call.  Everything I found here is minor.

-- Section 2:

   A single Unicode code point in this memo is denoted by "U+" followed
   by four to six hexadecimal digits.  Compare to [Unicode61], Appendix
   A.

I don't understand what is intended by "Compare".  Is this representation
the same as, similar to or different from the cited reference?

-- Section 3

   During IETF 77, a BOF discussed the current state of the protocols
   that have defined Stringprep profiles [NEWPREP].

I'd suggest adding the month and year of IETF 77 in parens after the 77.

   o  Stringprep is bound to version 3.2 of Unicode.  Stringprep has not
      been updated to new versions of Unicode.  Therefore, the protocols
      using Stringprep are stuck to Unicode 3.2.

   o  The protocols need to be updated to support new versions of
      Unicode.  The protocols would like to not be bound to a specific
      version of Unicode, but rather have better Unicode agility in the
      way of IDNA2008.  This is important partly because it is usually
      impossible for an application to require Unicode 3.2; the
      application gets whatever version of Unicode is available on the
      host.

I suggest merging first sentence of second bullet into the first bullet
so that the second bullet focuses on Unicode version agility.  The last
sentence of the first bullet could then be:

      Therefore, the protocols using Stringprep are stuck at Unicode 3.2,
      and their specifications need to be updated to support newer versions
      of Unicode.

Also, "Unicode agility" -> "Unicode version agility".

The following iSCSI bullet is incorrect:

   o  iSCSI uses a Stringprep profile for the IQN, which is very similar
      to (often is) a DNS domain name.

with

   o  iSCSI uses a Stringprep profile for the names of protocol participants
	(called initiators and targets).  The IQN format of iSCSI names contains
	a reversed DNS domain name.

-- Appendix A

The User entry for RFC 3722 (iSCSI) should be "b", not "a".  The iSCSI name
strings are part of host and storage system configuration; these strings
are entered by and are visible to administrators.

-- Appendix B.1 iSCSI Stringprep Profiles: RFC3722, RFC3721, RFC3720

There is one profile, and it's specified by RFC 3722.  The other two RFCs
describe the naming design and how the strings are used.  It may not b
appropriate to list the other two RFCs in the section name.

   Description:  An iSCSI session consists of an Initiator (i.e., host
      or server that uses storage) communicating with a target (i.e., a
      storage array or other system that provides storage).  Both the
      iSCSI initiator and target are named by iSCSI Names.  The iSCSI
      stringprep profile is used for iSCSI names.

Initiator -> initiator in first line.

   What is the impact if the comparison results in a false positive?
      Potential access to the wrong storage. - If the initiator has no
      access to the wrong storage, an authentication failure is the
      probable result. - If the initiator has access to the worng
      storage, the resulting mis-identificaiton could result in use of
      the wrong data and possible corruption of stored data.

Correct two spelling errors:
	- worng -> wrong
	- identificaiton -> identification.

   What are the security impacts?  iSCSI names are often used as the
      authentication identities for storage systems.  Comparison
      problems could result in authentication problems, although note
      that authentication failure ameliorates some of the false positive
      cases.

Change "are often used" to "may be used" in the first line.

   How much tolerance for change from existing stringprep approach?
      Good tolerance; the community would prefer that
      internationalization experts solve internationalization problems
      ;-).

Remove the smiley.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: <[email-masked]>
Date: Fri, 3 Aug 2012 12:42:46 -0400

NFS also contains some stringprep profiles:

	- NFSv4: RFC 3530, Section 11
	- NFSv4.1: RFC 5661, Section 14

There are also concerns that the stringprep approach doesn't work well for NFSv4.
See section 12 of draft-ietf-nfsv4-rfc3530bis-18.txt for some current thinking
on this topic.

Thanks,
--David

> -----Original Message-----
> From: Black, David
> Sent: Friday, August 03, 2012 12:05 PM
> To: [email-masked]
> Cc: Black, David
> Subject: Late comments on problem-statement-06
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 03 Aug 2012 11:44:22 -0600

> See section 12 of draft-ietf-nfsv4-rfc3530bis-18.txt for some current thinking

I see that they devote over 20 pages to internationalization issues. I
looked at the first 5 pages and then realized I'd need to spend
significant time grokking it all...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 3 Aug 2012 10:48:54 -0700

-08 now includes all your changes. However, for:

"-- Appendix B.1 iSCSI Stringprep Profiles: RFC3722, RFC3721, RFC3720
> appropriate to list the other two RFCs in the section name."

I wanted to keep the three RFCs in the list since they had been identified as to be reviewed during our stringprep customers review process. (so that we show the coverage we made). So I rewrote as:

iSCSI Stringprep Profile: RFC3722 (and RFC3721, RFC3720).

hope this is acceptable to you.

Marc.

Le 2012-08-03 à 09:04, <[email-masked]> a écrit :

> _______________________________________________
> precis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/precis

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 3 Aug 2012 10:50:12 -0700

> See section 12 of draft-ietf-nfsv4-rfc3530bis-18.txt for some current thinking

ok. but I'm not sure what to do or include into the problem statement. 

Do you want to sketch something?

Marc.

---

From: <[email-masked]>
Date: Fri, 3 Aug 2012 14:37:22 -0400

That works for me, Thanks, --David

> From: Marc Blanchet [mailto:[email-masked]]
> Sent: Friday, August 03, 2012 1:49 PM
> To: Black, David
> Cc: [email-masked]
> Subject: Re: [precis] Late comments on problem-statement-06
> 
> I wanted to keep the three RFCs in the list since they had been identified as
> to be reviewed during our stringprep customers review process. (so that we
> show the coverage we made). So I rewrote as:
>

---

From: <[email-masked]>
Date: Fri, 3 Aug 2012 14:49:10 -0400

I'd just mention the existence of these stringprep profiles to the list in Section 1.
I would not go into their details, particularly given the text in 3530bis that moves
away from use of stringprep.

Thanks,
--David

> Sent: Friday, August 03, 2012 1:50 PM
> To: Black, David
> Cc: [email-masked]
> Subject: Re: [precis] Late comments on problem-statement-06 [NFSv4]
> 
>

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 3 Aug 2012 11:58:10 -0700

> I'd just mention the existence of these stringprep profiles to the list in Section 1.

they have been since the first version of the draft, aren't they?

<extract>
1.  Introduction

   Internationalizing Domain Names in Applications (here called
   IDNA2003) [RFC3490], [RFC3491], [RFC3492], [RFC3454] describes a
   mechanism for encoding Unicode labels making up Internationalized
   Domain Names (IDNs) as standard DNS labels.  The labels were
   processed using a method called Nameprep [RFC3491] and Punycode
   [RFC3492].  That method was specific to IDNA2003, but is generalized
   as Stringprep [RFC3454].  The general mechanism is used by other
   protocols with similar needs, but with different constraints than
   IDNA2003.

   Stringprep defines a framework within which protocols define their
   Stringprep profiles.  Known IETF specifications using Stringprep are
   listed below:
   o  The Nameprep profile [RFC3490] for use in Internationalized Domain
      Names (IDNs);
   o  NFSv4 [RFC3530] and NFSv4.1 [RFC5661];

</extract>

Marc.

---

From: <[email-masked]>
Date: Fri, 3 Aug 2012 20:42:14 -0400

Indeed they have been - missed that, sorry, --David

> Sent: Friday, August 03, 2012 2:58 PM
> To: Black, David
> Cc: [email-masked]