Subject: [mile] IESG Review and Internationalization

From: <[email-masked]>
Date: Thu, 19 Jan 2012 17:52:30 -0500

Hello,

An issue came up in the IESG review for the reuse of the Node class from IODEF.  IODEF doesn't handle internationalization issues with respect to fully qualified domain names (FQDNs).  The following text was agreed upon by the IESG:

> 11. Internationalization Considerations
>
>     The Node class identifies a host or network device.  This document
>     re-uses the definition of Node from the IODEF specification
>     [RFC5070], Section 3.16.  However, that document did not clearly
>     specify whether a NodeName could be an Internationalized Domain Name
>     (IDN).  RID systems MUST treat the NodeName class as a domain name
>     slot [RFC5890].  RID systems SHOULD support IDNs in the NodeName
>     class; if they do so, they MUST ensure that the domain name is
>     represented only using ASCII characters, i.e., all of its labels
>     MUST be either A-labels or NR-LDH labels [RFC5890] and
>     internationalized labels MUST be encoded as A-labels using the
>     Punycode encoding [RFC3492] as described in the protocol
>     specification for Internationalized Domain Names in Applications
>     [RFC5891].

If this will cause any issues for implementations, please speak now.  I think it will be fine as we mainly use it to ensure incident numbers are unique (that was the purpose in the IncidentID for this value).  It would also be used in pulling reports and could be tied to your trust relationship management.

Thank you!
Kathleen

Kathleen M. Moriarty, CISSP | GRC Strategy | Office of the CTO | 617-851-5807 | [email-masked]  | EMC Corporation

---

From: <[email-masked]>
Date: Thu, 19 Jan 2012 22:34:08 -0500

Please post any objections or positive comments before Wednesday.

Thank you!
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, January 19, 2012 5:53 PM
To: [email-masked]
Subject: [mile] IESG Review and Internationalization

Hello,

Thank you!
Kathleen

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

---

From: "Martin, Robert A." <[email-masked]>
Date: Thu, 19 Jan 2012 22:44:48 -0500

This change makes sense given the role envisioned for these efforts in 
coordination and sharing of incident information across the world.

Bob

On 1/19/12 10:34 PM, [email-masked] wrote:
> .

---

From: <[email-masked]>
Date: Fri, 20 Jan 2012 18:42:14 -0500

Hello Kathleen,

> An issue came up in the IESG review for the reuse of the Node class from IODEF.  IODEF doesn't handle
> internationalization issues with respect to fully qualified domain names (FQDNs).  The following text
> was agreed upon by the IESG:
> 
> If this will cause any issues for implementations, please speak now.  I think it will be fine as we
> mainly use it to ensure incident numbers are unique (that was the purpose in the IncidentID for this
> value).  It would also be used in pulling reports and could be tied to your trust relationship
> management.

I'm not a RID implementer, and so would like to hear from those who are (or expect to be).

I have a design concern about this proposed approach, based in part upon your other suggestion
that UTF-8 should be the only encoding for RID documents (FWIW, that suggestion seems like a good
idea to me).  This concern is not major, as the above punycode approach is workable, but there
may be a difference in usability of RID in practice.

Punycode was originally devised to cope with the fact that the deployed DNS could not deal directly
with Unicode, and in particular with UTF-8, courtesy of the DNS not being 8-bit [character] clean.
In contrast, it appears that RID is about to require that UTF-8 be the only XML document encoding,
and hence all systems that process RID have to be 8-bit clean and capable of dealing with UTF-8.

Punycode uses a subset of the 7-bit ASCII characters to encode the offset numbers for a finite
state machine that generates the non-ASCII Unicode characters, and hence punycode is not really
human-readable (humans can't readily determine what the Unicode was that generated the punycode
- the punycode suffix looks like ASCII gobbledygook).  See http://en.wikipedia.org/wiki/Punycode,
and keep in mind that the simple example on that page only has one non-ASCII character whose
Unicode code point has a relatively small value.

In contrast, UTF-8 is byte-encoded, and hence is human readable, albeit with some effort to
understand multi-byte characters when they don't display as Unicode.  That effort's akin to
remembering that %20 in a URL encodes a space, although it's not that simple.

Assuming that RID is going to require UTF-8, it seems simpler to put IDNs into RID as UTF-8 and
do any Unicode-punycode conversion in the DNS clients used by systems that process RID messages.

In contrast, using punycode in RID either displays punycode (may be ok if it never has to be
matched against the domain name elsewhere), or requires additional functionality to convert
between Unicode and punycode in systems that process RID, instead of isolating that functionality
to the DNS clients (where punycode belongs, IMHO).  Beyond that, there's a distinct possibility
that the same IDN may be sent as punycode in the Node class and as UTF-8 elsewhere in the same
RID message (e.g., in a syslog or trace record in the XML that's enveloped by RID), and that
doesn't seem helpful to an incident handler.

I wouldn't ban punycode - if the only alternative to using punycode is to not send the incident
information, then punycode probably ought to be used.  OTOH, banning use of UTF-8 for IDNs in a
document that MUST be in UTF-8 seems peculiar.

What do other people think about this?

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, 20 Jan 2012 19:27:06 -0500

Thank you, David.  You make really good points and the explanation is appreciated.  Do others have opinions?

Thanks,
Kathleen

Sent from my iPhone

---

From: Brian Trammell <[email-masked]>
Date: Tue, 24 Jan 2012 15:03:08 +0100

Hi, Kathleen, all,

Speaking as a contributor, I agree in the large with David's assessment here.

First off, mandating UTF-8 for RID in general, as in another thread, seems to me to really be the only choice. This makes the choice of Punycode look a little odd, especially since there doesn't seem to be much benefit to being "closer to the wire" for DNS.

While Node will be used by RID implementations for display, it will probably also be commonly used in comparisons (lookups will often be done based on IncidentSource, for instance). In this case, a normalized representation is crucial. Either U-label or A-label forms of an IDN suffice here, I believe.

So I think it makes sense to call NodeName in the Node class in RID a domain name slot [RFC5890], but to allow the U-label and A-label (and by extension NR-LDH) forms. Since U- and A-labels are both 1. programmatically recognizable and 2. mutually convertible to each other, this allows RID implementations to use whichever form is more convenient at the time without losing any information.

None of this fixes the fact that we have the same issue in IODEF; I think after we have finished 6045-bis and 6046-bis, we should look into what can be done to define IDN support for IODEF, based on the 6045-bis definition.

Best regards,

Brian (author hat)