Subject: APPAREA Meeting Agenda Items

From: "Scott Hollenbeck" <[email-masked]>
Date: Tue, 22 Feb 2005 10:27:42 -0500

Does anyone have anything that they'd like to talk about during the APPAREA
meeting we have scheduled for IETF-62?  If not, it may end up being a pretty
short meeting!

-Scott-

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Wed, 23 Feb 2005 21:58:19 -0500

Yoneya-san,

There's more to this topic than meets the eye.  This discussion has led me
into another conversation with other ADs and IAB members to see how we can
approach the topic constructively.  Let me se where that goes and I'll get
back to you ASAP.  I do believe we can put the topic on the agenda, but I'm
not yet sure how I want to approach it.

-Scott-

> -----Original Message-----
> From: Yoshiro YONEYA [mailto:[email-masked]] 
> Sent: Wednesday, February 23, 2005 8:53 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: APPAREA Meeting Agenda Items
> 
> Scott,
> 
> Sorry, I forgot to attach I-D.
> 
> On Thu, 24 Feb 2005 10:45:43 +0900 (JST) Yoshiro YONEYA 
> <[email-masked]> wrote:
> 
> > Scott,
> > 
> > Thank you for your response.  I submitted attached Internet 
> Draft but 
> > I'm not sure it is processed or not.  I'm going to make a 
> presentation 
> > about this, and want to gather comments.  Actually, this is 
> not my own 
> > idea and already discussed in ietf/idn mailing lists.  I 
> think making 
> > summary and drafting common guideline for application 
> implementation 
> > is very important.  I think it will need 30min.
> > 
> > --
> > Yoshiro YONEYA <[email-masked]>
> > 
> > On Wed, 23 Feb 2005 07:18:01 -0500 "Scott Hollenbeck" 
> <[email-masked]> wrote:
> > 
> > > Sure, we can do that.  Would you be willing to prepare some 
> > > materials and lead the discussion?  How much time would be needed?
> > > 
> > > -Scott-
> > > 
> > > > -----Original Message-----
> > > > From: Yoshiro YONEYA [mailto:[email-masked]]
> > > > Sent: Wednesday, February 23, 2005 12:31 AM
> > > > To: [email-masked]
> > > > Cc: [email-masked]; [email-masked]
> > > > Subject: Re: APPAREA Meeting Agenda Items
> > > > 
> > > > 
> > > > Scott,
> > > > 
> > > > This is Yoneya at JPRS.  I send attatched mail last 
> night to this 
> > > > list but it seems not delivered.
> > > > 
> > > > --
> > > > Yoshiro YONEYA
> > > > 
> > > > On Tue, 22 Feb 2005 10:27:42 -0500 "Scott Hollenbeck" 
> > > > <[email-masked]> wrote:
> > > > 
> --
> Yoshiro YONEYA <[email-masked]>
>

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Wed, 23 Feb 2005 07:18:01 -0500

Sure, we can do that.  Would you be willing to prepare some materials and
lead the discussion?  How much time would be needed?

-Scott-

> This is Yoneya at JPRS.  I send attatched mail last night to this list
> but it seems not delivered.
> 
> -- 
> Yoshiro YONEYA
>

---

From: Yoshiro YONEYA <[email-masked]>
Date: Wed, 23 Feb 2005 14:31:22 +0900 (JST)

Scott,

-- 
Yoshiro YONEYA

> meeting we have scheduled for IETF-62?  If not, it may end up being a pretty

Subject: BoF Agenda?
From: Yoshiro YONEYA <[email-masked]>
To: [email-masked]
Date: Wed, 23 Feb 2005 01:22:24 +0900 (JST)

On the Draft Agenda of the Sixty-second IETF, apparea meeting is
scheduled on Monday morning.  Is there any agenda items?  I'd like to
propose to have discussion about IDN aware application implementation
guideline.

---

From: Yoshiro YONEYA <[email-masked]>
Date: Thu, 24 Feb 2005 10:53:17 +0900 (JST)

Scott,

On Thu, 24 Feb 2005 10:45:43 +0900 (JST) Yoshiro YONEYA <[email-masked]> wrote:

> Scott,
> 
> Thank you for your response.  I submitted attached Internet Draft but
> I'm not sure it is processed or not.  I'm going to make a presentation
> about this, and want to gather comments.  Actually, this is not my own
> idea and already discussed in ietf/idn mailing lists.  I think making
> summary and drafting common guideline for application implementation
> On Wed, 23 Feb 2005 07:18:01 -0500 "Scott Hollenbeck" <[email-masked]> wrote:
> 

-- 
Yoshiro YONEYA <[email-masked]>
Network Working Group					       Y. Yoneya
Internet-Draft							    JPRS
Expires: Aug 20, 2005	   				    Feb 20, 2005

	    IDN aware application implementation guideline
		   draft-yoneya-idn-app-guideline-00

Status of this Memo

  This document is an Internet-Draft and is subject to all provisions of
  section 3 of RFC 3667.  By submitting this Internet-Draft, I certify
  that any applicable patent or other IPR claims of which I am aware
  have been disclosed, or will be disclosed, and any of which I become
  aware will be disclosed, in accordance with RFC 3668.

  Internet-Drafts are working documents of the Internet Engineering Task
  Force (IETF), its areas, and its working groups.  Note that other
  groups may also distribute working documents as Internet-Drafts.

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time.  It is inappropriate to use Internet-Drafts as reference
  material or to cite them other than a "work in progress."

  The list of current Internet-Drafts can be accessed at
  http://www.ietf.org/ietf/1id-abstracts.txt.

  The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html.

  This Internet-Draft will expire on August 20, 2005.

Copyright Notice

  Copyright (C) The Internet Society (2005).

Abstract

  Since IDN Standards [RFC3490-3492] were published, some of gTLDs and
  ccTLDs began IDN registration and resolution service.  Furthermore,
  many major Web browsers became IDN aware.  IDNs seem to be popularized
  soon.

  Meanwhile, IDN introduces huge number of characters which can
  represent domain name, so it increases human misreading of domain name
  with similar looking characters.  This issue was discussed deeply
  during IDN standardization and service development, and as a result,
  JET Guideline [RFC3743] and ICANN IDN Guideline [ICANN-IDN] was
  published.  Even if TLD registries comply such guidelines, bad-faith
  guys may use IDNs to deceive human eyes with similar looking
  characters.

  To protect users from such deceiver, implementation guideline for how
  to handle IDNs at the User Interface level is important.  This
  document is intended to be such guideline for application
  implementers.

1. Introduction

  IDN Standards allows using any sequence of non-prohibited Unicode
  characters to compose Internationalized domain name.  It have to be
  considered as technical margin, and have to be recognized unlimited
  use of IDN specification will cause confusion of users.

  JET Guideline and ICANN IDN Guideline were developped to decrease such
  confusion, but bad-faith guys are still possible to use such IDN
  specification to deceive Internet users.  Through IDN experiences, to
  decrease such confusion, importance of additional User Interface level
  support is recognized.

2. IDN aware application implementation guideline

  [ At this moment, this guideline is narrowing its scope to Web
    browsers. ]
 
2.1 Visibility support

  If user typed and / or copy-and-pasted URI included Internationalized
  character(s) in domain name part, then displayed URI should be colored
  or have icon like HTTPS access.

  If the terminal doesn't have color or attribute capability, then
  displayed URI should be Punycode as a default.

  Having toggle switch to display IDN and Punycode in address bar will
  be helpful.

2.2 Introduce additional mapping

  Some of mathematical operators have the same shape with ASCII
  punctuations which have special meaning in many protocols.
  Those characters may be "map"ped to ASCII characters.

  U+2212 -> U+002D
  U+2215 -> U+002F
  U+2236 -> U+003A

  If applications don't want to against protocol specification, those
  characters should be displayed strongly distinguishable form or
  color or code such as %-encoding.

2.3 Introduce additional prohibit characters

  At this moment, there is no significant advantage to use symbolic
  characters in IDN.  Treating such characters as "prohibited" in
  NAMEPREP [RFC3491] stage won't be a serious problem.

  Followings may be treated as "prohibited" in applications. 

  U+2000-U+2AFF: Punctuations, Symbols, Marks, and so on.
  U+3200-U+32FF: Enclosed CJK Letters and Months
  U+3300-U+33FF: CJK Compatibility

  If applications don't want to against protocol specification, those
  characters should be displayed strongly distinguishable form or
  color or code such as %-encoding.

2.4 IDN Language Table reference

  [ TBD. some sort of table lookup mechanism for IDN Language Table will
    be helpful ]

3. References

  [RFC3454]	P. Hoffman and M. Blanchet, "Preparation of
  		Internationalized Strings ("stringprep")", RFC 3454,
		December 2002.
  [RFC3490]	P. Faltstrom, P. Hoffman, and A. Costello,
		"Internationalizing Domain Names in Applications (IDNA)",
		RFC 3490, March 2003.
  [RFC3491]	P. Hoffman, and M. Blanchet, "Nameprep: A Stringprep
		Profile for Internationalized Domain Names (IDN)", RFC
		3491, March 2003.
  [RFC3492]	A. Costello, "Punycode: A Bootstring encoding of Unicode
		for Internationalized Domain Names in Applications
		(IDNA)", RFC 3492, March 2003.
  [RFC3743]	K. Konishi, K. Huang, H. Qian, and Y. Ko, "Joint
		Engineering Team (JET) Guidelines for Internationalized
		Domain Names (IDN) Registration and Administration for
		Chinese, Japanese, and Korean", RFC 3743, April 2004.
  [ICANN-IDN]	Internet Corporation for Assigned Names and Numbers,
		"Guidelines for the Implementation of Internationalized
		Domain Names, Version 1.0", June 2003.

4. Security considerations

   See "Security Considerations" section in STRINGPREP [RFC3454].

5. Author's Address

  Yoshiro YONEYA
  Japan Registry Services Co., Ltd.
  Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda-ku,
  Tokyo 101-0065, JAPAN
  [email-masked]

Disclaimer of Validity

  This document and the information contained herein are provided on an
  "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
  OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
  ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
  INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
  INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
  WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright statement

  Copyright (C) The Internet Society (2005). This document is subject to
  the rights, licenses and restrictions contained in BCP 78, and except
  as set forth therein, the authors retain all their rights.

Acknowledgment

  Funding for the RFC Editor function is currently provided by the
  Internet Society.

---

From: Yoshiro YONEYA <[email-masked]>
Date: Thu, 24 Feb 2005 10:45:43 +0900 (JST)

Scott,

---

From: Martin Duerst <[email-masked]>
Date: Fri, 25 Feb 2005 16:34:56 +0900

Hello Yoshiro, others,

I'll unfortuately not be at the meeting, so I'm just
using this opportunity for comments on this document.
If this is not an appropriate venue for such comments,
please tell me where to send them.

Also, I guess that Yoshiro wrote the first draft in
quite some hurry before the deadline, so I understand
that it's far from final.

Overall, I think it is a good idea that the IETF does
something re. IDN spoofing/phishing as it has recently
received quite some attention. The main goal would be
to make clear that "just switch off IDN" isn't a solution
(the same way as "just plug the cable" (or these days
"just switch off wireless" :-) isn't an answer to
other security problems), and to provide implementers
with help, advice, ideas, and guidance.

But this has to be done very carefully. We should avoid
the impression that we know what user interface works
best, we should avoid the impression that this is
mainly an user interface issue (it is at least as much,
if not more, a registry issue, and also very much a
user education and law enforcement issue).

Some more comments inline. I'll not comment on purely
grammatical or editorial issues, that can wait for a later
round.

 >  guys may use IDNs to deceive human eyes with similar looking

I'd suggest that this be written a bit more generally, i.e. not
as if the JET and ICANN guidelines were the only ones, and will not
change.

 >  use of IDN specification will cause confusion of users.

will -> may

 >  decrease such confusion, importance of additional User Interface level

I'd write something like "a carefully designed user interface may
help to decrease confusion and avoid deception".

 >  character(s)

Better use "non-ASCII characters" than "Internationalized characters".
URIs can't include non-ASCII characters. IRIs can (see RFC 3987).
URIs can include %-encoded non-ASCII characters in the domain name
part if such encoding is based on UTF-8 according to the latest
version of the URI spec [RFC 3986]. Browsers may take such %-encodings
and convert them to readable characters automatically (e.g. Opera does).

 >in domain name part, then displayed URI should be colored

This is WAY TOO general. Take the average Japanese user.
In a year or two, they may see a lot of Japanese domain names
every day, most of them completely okay and with little or no
chance for spoofing. The icon would always be up. When they
see an purportedly ASCII-only domain name, they'll not notice
anything special.

 >  Those characters may be "map"ped to ASCII characters.

We'd probably better recommend that such stuff is never registered.

 >  color or code such as %-encoding.

What might make more sense is to color, or otherwise visually
identify, different parts of an URI/IRI, or to visually
identify the characters with special meaning. This may
help with other spoofing attacks, such as when it looks
like one part of an URI is the domain name when indeed
something else is used for that function.

 >  U+3300-U+33FF: CJK Compatibility

I'd probably also include the ones from 2.2 here.

 >  color or code such as %-encoding.

There should probably be something about cross-script
attacks, because that's what the recent example was,
and that's a well-identified threat.

 >  [ TBD. some sort of table lookup mechanism for IDN Language Table will

Is that e.g. for characters that we propose to prohibit?
Or for all kinds of language tables? If the later, that
may not make sense, because such tables will grow in number
and also may change. Also, I hope we can slowly but steadily
move away from the term "Language Table", because it is often
confusing. Most of the theats we are looking at are not at all,
or just only barely, related to language.

 >3. References

We should also point to Unicode TR #36.

Regards,    Martin.