Subject: [idn] :Re: Last Call: Preparation of Internationalized Strings ('strin

From: Erik Nordmark - Sun Microsystems <[email-masked]>
Date: Thu, 30 May 2002 08:41:50 -0000

gprep') to Proposed Standard (Fwd)
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Forwarded with permission.

>----------------Begin Forwarded Message----------------<

Date: Mon, 27 May 2002 09:52:09 +0100 (BST)
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Last Call: Preparation of Internationalized Strings         ('strin
gprep') to Proposed Standard
To: [email-masked]

>To: IETF-Announce:;;@loki.ietf.org
>From: The IESG <[email-masked]>
>SUBJECT: Last Call: Preparation of Internationalized Strings 
>          ('stringprep') to Proposed Standard
>Date: Wed, 22 May 2002 11:13:01 -0400

>The IESG has received a request to consider Preparation of 
>Internationalized Strings ('stringprep') 
><draft-hoffman-stringprep-03.txt> as a Proposed Standard.  This has 
>been reviewed in the IETF but is not the product of an IETF Working 
>Group.
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send any comments to the 
>[email-masked] or [email-masked] mailing lists by June 4, 2002.

This draft is based upon Unicode 3.1, but I see that the latest Unicode
Standard is now version 3.2 (issued on 2002-03-27).

It might be better to update this draft to 3.2 before acceptance as a
Proposed Standard, and to do the same with the other drafts in the IDNA
set. There would appear to be little that would need doing, beyond a
routine updating of the tables in the draft, and with a bit of luck the
whole IDNA series could then be published before Unicode 3.3 happens
(which should be at least 12 months away).

Moreover, since these drafts are so written that they are intended to be
updated each time a new Unicode Version appears, it would be useful to
have actual experience of doing that exercise on a draft, rather than on a
published RFC.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

>----------------End Forwarded Message----------------<

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 30 May 2002 12:16:42 +0200

> have actual experience of doing that exercise on a draft, rather than on a

This is interesting -- has the Unicode consortium promised to always
update the CK normalization tables in a forward compatible way?  Since
IDNs will be used to identify hosts for security critical purposes, a
change in the normalization could in theory be exploited to spoof
identities in, e.g., TLS.

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 30 May 2002 13:01:12 +0200

--On 2002-05-30 12.16 +0200 Simon Josefsson <[email-masked]> wrote:

> update the CK normalization tables in a forward compatible way?

Yes.

   paf -- Liason in IETF to Unicode Consortium

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 30 May 2002 15:20:58 +0200

--On 2002-05-30 14.24 +0200 Simon Josefsson <[email-masked]> wrote:

> A further security consideration of IDNA could be that whenever such
> modifications is done in the Unicode standards, they may be exploited
> and it should be an operational consideration to never register
> domains, issues PKIX certifices for domains, create Kerberos realms,
> create PGP keys, etc, for IDNs that contains characters that have
> their decomposition mapping changed by the Unicode consortium.
> 
> It seems as if a modification of this kind occured between Unicode 3.0
> and 3.1: http://www.unicode.org/versions/corrigendum2.html.
> 
> The conclusion here is that this isn't a practical problem -- only one
> character changed normalization between 3.0 and 3.1 and none between
> 3.1 and 3.2 AFAIK.  I am more worried about the transcoding problem.

(a) There was one change between 3.1 and 3.2.

(b) If Unicode consortium decides to make a change which "we" (in the form
of IETF community) don't think is safe enough, then we can choose to _NOT_
follow the update of Unicode, and stay with the version we are following
(which include the errors which Unicode Consortium corrects to the new
version).

I.e. just because the documents point at a specific version of Unicode, we
have to choice of not following and upgrading. That's the emergency break
we have.

Still, I (aswell as Unicode Consortium as you can see in their statement
which you pointed at) don't want to see this happens. The day it does, if
it does, we can talk again about it.

   paf

---

From: "Soobok Lee" <[email-masked]>
Date: Fri, 31 May 2002 00:26:38 +0900

If  new version of Unicode is not proved to be safe enough, we have choices

  1) wait until newer , correc, mature and stable version of Unicode come out

  2) go with previous version of Unicode, regardless of whether the version has errors or not.

if we choose 2), we have the following chance of failures and security concerns

  NFKC3.1(CaseFold3.1(IDN1)) != NFKC3.2(CaseFold3.2(IDN1))
  NFKC3.1(CaseFold3.1(  NFKC3.2(CaseFold3.2(IDN1))  ))  !=  NFKC3.2(CaseFold3.2(IDN1))

This may happen when ,for example, Canonical XML (which use NFC) facility applies new NFC3.2
  to IDN-containing tag values ,and that canonicalized IDN go through
    NFKC3.1 in further nameprep/ACE coding.

This issues were raised at the time of IDN WG last call,  3 months ago.

Soobok Lee

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 30 May 2002 18:11:52 +0200

> This issues were raised at the time of IDN WG last call,  3 months ago.

And my answer was exactly the same then as now. We can not do better. If
Unicode is updated, you will either get inconsistency with the parties
using the new version of Unicode (if IDN is not upgraded) or inconsistency
with old registered names (if IDN is upgraded).

The point is that the current scheme (a) trust Unicode when they say that
changes will be backward compatble and (b) IF they do an incompatible
change, we can at that point in time make the desicion -- we don't have to
decide now what path we take.

   paf

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 30 May 2002 18:09:18 +0200

> (a) There was one change between 3.1 and 3.2.

So the Unicode consortium has already broken the promise?

The assumption that normalization tables are not changed in a
backwards incompatible way should be stated in the security
considerations IMHO, as the security of IDN depends on that.
Especially if the assumption doesn't hold in all cases.

> have to choice of not following and upgrading. That's the emergency break

This means Unicode-based systems will implement two versions of
Unicode (normalization, encoding etc) at the same time.  One
implementation for IDNA, one for the rest of the system that need new
features in Unicode.  That should probably also made more clear; that
an implementator MUST NOT use Unicode 3.2 or any other Unicode version
provided by the system, but must pick Unicode 3.1 (without the
Corrigendum, it seems, since they aren't referenced in IDNA),
otherwise security may be jeopardized.

Again, it would be useful to see a study on how serious these problems
are in practice.  I'm not sure if this (and the transcoding)
discussion is purely theoretical or, at the other extreme, there will
not only be security problems but even interoperability problems
(application A can connect to bank with funny characters but
application B cannot connect, all because of differences in
normalization and/or transcoding mapping tables).

> it does, we can talk again about it.

If indeed there was a change between 3.1 and 3.2, the day has already
come.

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 30 May 2002 18:37:45 +0200

> If indeed there was a change between 3.1 and 3.2, the day has already

No. They said very explicitly that the change could be done (i.e. the
correction could be done) just because IDN is not deployed.

Yes, that involvs we choosing to go with 3.2 and not 3.1 (which was last
called), but that has already been suggested as a last call comment so that
horse is already dead.

  paf

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 30 May 2002 11:50:06 -0500

Patrik Fältström wrote:
> using the new version of Unicode (if IDN is not upgraded) or
> inconsistency with old registered names (if IDN is upgraded).

There are some alternatives here. We can certainly define our own Unicode
mapping table and make it available through a variety of means, and also
encourage synchronization. When unicode changes, we change the mapping
tables to handle any conflicts.

We could even put this stuff into a zone, and let people replicate from
that periodically, to encourage faster synchronization.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/