Subject: [Syslog] Unicode - was: AD Review for draft-ietf-syslog-protocol-14

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 14 Oct 2005 15:49:50 +0200

Hi WG,

I address the following issue Sam mentioned:

> 2) You do not discuss Unicode security at all.  I suggest that people
>     in the working group read Unicode TR 36 and also consider the
>     implications of the Unicode security presentation given at the
>     last SAAG presentation.  particularly consider comments from
>     operators concerned about Unicode characters interacting with
>     existing scripts.  Then write up a security considerations
>     section.  You need to at least explain the security risks
>     associated with your choice to support all Unicode characters.  It
>     would be a good idea to discuss other alternatives that were
>     considered and to explain why this choice was made.

I have gone through the material Sam mentions. For those not already
done so, the following links might be helpful. The first link is to the
presentation, which very quickly provides an overview of the magnitude
of the issues.

http://www3.ietf.org/proceedings/05aug/slides/saag-4.pdf
http://www3.ietf.org/proceedings/05aug/saag.html#cmr
http://www.unicode.org/reports/tr36/ (the UTR36)

In a brief (and not 100% correct) summary, there are two issues with
Unicode: one is the technical aspect of using non-common encoding forms
that may lead to trick an application's security check code. This is
addressed in section 3.1 of UTR 36. This issue is relatively
straightforward to solve in requiring applications to use the shortest
possible encoding only. I have already done some text change in
syslog-protocol to cover this.

The second issue is more subtle: that of visual security issues
(outlined in section 2 of UTR36). In short, there are visually easily
confusable characters - just like l (lower case letter L) and 1 (digit
1) in many fonts. This issue is of major concern if used in identifying
information. UTR36 also gives some insights into the international DNS
decisions and issues with visual confusability. The bottom line is that
whenever we use something as identifying information, targeted somewhere
down the road towards humans, we have an issue.

UTR36 defines some mechanisms to at least partly solve the confusabilty.
However, in the context of syslog I consider none of them to be
straightforward. If we require them in syslog-protocol, that will
probably be a thing that costs us much acceptance at the implementor
side.

So it might be useful to think about where we have an issue at all. The
MSG field, I think, does not count as identifying information. It is
meant as a human-readable message. Even though it obviously carries
information, I think it is not subject to an easy visual spoofing
attack. Ok, one can think about scenarios where visual spoofing might
cause confusion, but the severity level of this should be fairly low. I
think it has the same implications as hoax mails, where misinformation
in the textual part is a simple fact of life and not avoidable without
stopping to use that service. So I conclude that supporting the full set
of Unicode characters inside MSG is fine.

The STRUCTURED-DATA is another story. Here, it includes information that
might primarily be used as identifying information. Reviewing the
current defined SD-IDs, I hardly see any need for using Unicode
encoding. As far as I recall, we have selected Unicode instead of
US-ASCII because we thought it might be benefitial for further
extensions. However, given the fact of visual confusability and the need
to deal with it, I am questioning if it acually is a good idea to encode
STRUCTURED-DATA in Unicode. Wouldn't it be better to use US-ASCII, which
relievs us of all of these issues? So far, I do not see a compelling
reason for full Unicode support in SD-IDs.

Of course, we could just go ahead and document these issues in security
considerations. I think, however, that we should try to solve them
before resorting to that. I think we have a good chance of finding a
workable solution.

My suggestion to the WG is that we drop Unicode encoding for
STRUCTURED-DATA and use printable US-ASCII instead.

I would appreciate feedback on the following:

#1 Is it OK the support Unicode - without restriction - in MSG?
#2 Is there support in the WG for changing STRUCTURED-DATA encoding
   from Unicode to US-ASCII?

If the answer to #2 is "no", please provide reasoning as that will help
speed up the process.

--
Rainer

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 17 Oct 2005 11:27:04 +0200

I think Unicode is a must, even if it then means we have other problems to
solve.  US-ASCII is fine for the northern part of that small island that sits
between the Pacific and Atlantic oceans but not for the most of the world:-).
This is more political than technical but I do take the actions of UN/WSIS/ITU
seriously and do not want to give them ammunition to take control of technology
away from the engineers of the IETF and into the bureaucracy of some other body
(think OSI).

So we must cater for the majority of the world (even if there is little sign of
calls for i18n on this particular list) and take Unicode on board.

Ambiguity?  Yes I have lived with the confusion of 0/O 1/I/| 2/Z 5/S for decades
and see it as primarily the choice of the 'name space authority' not to choose
symbols, 'names',  that are ambiguous.

Tom Petch

----- Original Message -----
From: "Rainer Gerhards" <[email-masked]>
To: <[email-masked]>
Sent: Friday, October 14, 2005 3:49 PM
Subject: [Syslog] Unicode - was: AD Review for draft-ietf-syslog-protocol-14

Hi WG,

--
Rainer