Subject: draft-hoffman-utf8-rfcs-03.txt

From: John C Klensin <[email-masked]>
Date: Mon, 06 Oct 2008 14:38:56 -0400

Hi.

A few brief comments on this document....

(1) A mailing list for discussion is not designated.  While I
would normally suggested rfc-interest, the document appears to
be written on the assumption that approval of this proposal
rests with the IETF (presumably via the IESG) and IAOC and not
with the RFC Editor (with presumed review by the IAB), so I am
sending to this list.

(2) The document seems to assume that availability of UTF-8
systems (or other systems based on Unicode with easy
transcoding) is now near-ubiquitous.  Actual experience,
especially with documents being transmitted between computers by
email and similar means, appears to be different.  While I look
forward to the day at which comprehensive UTF-8 support is
universally available, at least as an interchange format, I do
not believe that we are there yet... and that there is still a
considerable gap, especially among systems that, instead of
being ASCII-only, have been developed with a focused on either
ISO 8859-1 or on a national coding system in East Asia.

(3) The document indicates that display systems that cannot
properly handle UTF-8 usually display an incorrect character
from which the user can make inferences.   While that sometimes
happens --sometimes with considerable information loss as we
have seen with a common anomaly with quoted sections of email
when the system on which the response is being composed and
those on both sides do not all prefer UTF-8-- it is at least
equally common to see an "undisplayable character" indication
which is the same for all such characters, e.g., a small box or
question-mark.  The problem is less likely with RFCs than with
random email, but we do, often, quote from RFCs and I-Ds in
email messages while working on them.  Once those "undisplayable
character" indicators are transferred from one system to
another, information is irretrievably lost... finding "better
display software" (rarely a realistic choice) is not an option
for recovering that information.

(4) Permitting critical information in RFCs (including any
information that is considered normative and author contact
information) to be exclusively in non-ASCII UTF-8 creates the
possibilities that a would-be implementer may not be able to
interpret the document or that it will be impossible to contact
the author(s), especially if, as an anti-spam precaution,
authors supply postal addresses and not email ones.

(5) I think we could quibble at great length about the advice
that should be given about compatibility characters.  While it
is probably sensible to discourage their use, it is quite easy
to imagine cases in which they might be important if a string
was going to be represented correctly.   Those cases
specifically include correct spelling of author names in some
parts of the world and examples that, for one reason or another,
actually have to illustrate the role of those characters... and
author names and examples appear to be the main justifications
for this proposal.  On the other hand, as the authors point out,
the issues with input methods and display of compatibility
characters are often much more serious than they are with their
equivalents, especially when display routines start performing
character substitutions for characters for which they lack
precise and accurate display capability.

I suggest that the authors concentrate less on painting a rosy
picture of how widely UTF-8 is deployed and how easily the
problems can be overcome (e.g., "just get better display
software [, even if that requires replacing hardware and
operating systems ]"), and, instead, concentrate on a definition
that would provide reasonable and effective fallbacks when
things go wrong as, at least for the present, they certainly
will.  For example, permitting UTF-8 (with arbitrary non-ASCII
characters) by itself in contact information is not sensible for
the reasons given above, but permitting UTF-8 only with a
requirement for either ASCII transliteration (or equivalent) or
RFC 5137 encoding to be present as an alternative might be
perfectly sensible at the current level of UTF-8 deployment and
availability.  Similar comments would apply to references,
especially normative ones (the principle that the IETF operates
in English and that English, and only English, is needed to
understand its technical specifications goes well beyond the
question of UTF-8 in RFCs and this document does not appear to
intend to change it), and to at least some examples that were
necessary to understand the normative text.

    --john

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Oct 2008 21:22:09 +0200

John,

it seems to me that you're really over-stating the risk of UTF-8.

I understand & agree that there may be systems out there which have 
trouble displaying UTF-8.

However (!): I would think that it is sufficient that we can reasonably 
assume that any *person* who needs to read an RFC does have access to a 
Web browser less than 5 years old (picking a somewhat arbitrary number), 
  which *will* display UTF-8 just fine -- availability of fonts aside 
(or is that your point?).

As a matter of fact, the IETF is telling protocol designers that they 
*have* to support Unicode -- why can we require it for protocols, but 
not for the documents we produce ourselves?

Regarding the other point about transmitting quotes from RFCs: of course 
it's wise to phrase the normative parts of RFCs so that they don't 
require transmission of non-ASCII characters. And yes, that needs to be 
stated, if it isn't already.

On the other hand, it would be extremely useful to have examples that 
*do* contain non-ASCII characters; if only to make implementers aware of 
the fact they they can *not* rely on ASCII and things are going to work 
(I've seen authors not doing I18N examples because they didn't know how 
to publish them as RFC...).

BR, Julian

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 6 Oct 2008 13:42:59 -0700

On 6 Oct, 2008, at 11:38, John C Klensin wrote:

> not believe that we are there yet...

John, Paul Hoffman appears to be operating on the assumption that  
UTF-8-capable software is widely available today on most platforms;  
you appear to believe otherwise.

It might be helpful if both of you (and others) could provide  
specific examples supporting those positions. Then we can work out  
how many people in reality are likely to have trouble reading UTF-8  
documents.

Speaking from my own experience, Unicode and UTF-8 have been  
supported in all versions of Mac OS X, and in Mac OS 9 before that.  
This means that any Macintosh computer sold in about the last ten  
years can handle UTF-8. Windows, Linux, etc., have probably had UTF-8  
support for a similar length of time (others may be able to supply  
precise dates). A ten-year old Mac running Mac OS 9 certainly won't  
be able to display every glyph in today's Unicode character set, but  
it can read a UTF-8 format file, decode the bytes correctly, display  
the Unicode characters it knows, and display placeholders for the  
ones it doesn't. Perhaps a workable compromise is to specify UTF-8 as  
the encoding for RFCs, but limited today to some subset of the full  
Unicode character set.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* Internet Architecture Board
* www.stuartcheshire.org

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 6 Oct 2008 14:25:18 -0700

>with the RFC Editor (with presumed review by the IAB), so I am

An earlier thread had already moved the discussion to rfc-interest, and I think it is more productive to have this discussed in one place. There is already an active discussion going on over there. I will put a note to that effect in the -04 version.

If the document moves to IETF Last Call, it will certainly get discussed here.

--Paul Hoffman, Director
--VPN Consortium

---

From: <[email-masked]>
Date: Tue, 7 Oct 2008 11:13:19 +0100

> Perhaps a workable compromise is to specify 
> UTF-8 as the encoding for RFCs, but limited today to some 
> subset of the full Unicode character set.

If UTF-8 is the *ARCHIVAL* encoding for RFCs, that does not prohibit
a repository from converting this encoding to some set of formats
that are more universally readable. For instance, a PDF file
with all character glyphs included, and an ASCII HTML file with
GIFs for non-ASCII characters all in one folder bundled into 
a .ZIP file.

In moving from a pure-ASCII environment, it is necessary to
decompose the process of creating, publishing and using an RFC.
At different stages in that process, different formats may be
required in order to maintain universal access to the document.

Note that if the UTF-8 document is in XML, there are a wide
variety of tools currently available that can transform it
into any imaginable format. Instead of seeking for the holy
grail of one true and universal format, it would be far better
to define a process workflow and an archival base format.

--Michael Dillon

---

From: Douglas Otis <[email-masked]>
Date: Wed, 8 Oct 2008 12:19:45 -0700

Here is a draft that outlines a few concerns for draft-ietf-dkim-ssp-06:

http://www.ietf.org/internet-drafts/draft-otis-dkim-adsp-sec-issues-03.txt

These concerns were not fully discussed on the DKIM list expect for  
voting for an "as is".  Unfortunately a voting process offers little  
clarity.

There appears to be a factual error in the draft.  Any restrictive  
ADSP assertion such as "ALL" or "DISCARDABLE" creates an additional  
requirement for what valid DKIM signature remains valid with respect  
to compliance with ADSP assertions.

See:  draft-ietf-dkim-ssp-06 Section 2.7.  Author Signature

This section defines an Author Signature as a valid signature where  
the "on-behalf-of" (DKIM signature i=value or its default) matches  
against the From header field.

Section 3.2 ADSP Usage however says:
.----
|If a message has a Valid Signature from an Author Domain, ADSP
| provides no benefit relative to that domain since the message is
| already known to be compliant with any possible ADSP for that
| domain.
'----

Clearly, these two sections are in conflict.  In addition, the Author  
Signature definition is in serious conflict with the working group's  
charter.

Since the DKIM key itself can assert a restriction upon the "on-behalf- 
of" local-part, there might be some justification to generally require  
signatures using local-part restricted keys to also match against the  
 From header field before being considered valid.  It would be  
dangerous to only impose this requirement based upon the existence of  
an ADSP record.  SSP attempts to use DNS "SERVFAIL" to detect an  
attempt to block the ADSP records, but this status may not be apparent  
behind a resolver.  A conditional requirement is ill considered from a  
security standpoint, and may even invite abuse.

Once the issue of restricted local-part keys is properly handled in an  
independent fashion, then attempts to require the "on-behalf-of" match  
against the From header field conflates DKIM and an ADSP record into a  
poor replacement for either S/MIME or OpenPGP.  After all, the DKIM  
signature and it's "on-behalf-of" fields are normally invisible to the  
recipient, and DKIM in conjunction with an ADSP still does not assure  
control over the Display Name being seen.  An MUA can always annotate  
a message to indicate specifically what portions of the message match  
against the DKIM signature's "on-behalf-of" and domain.   The SSP  
draft is conflating a valid DKIM signature and ADSP record into  
becoming an assertion of the identity of the message's Author.  Such  
conflation clearly and dangerously exceeds the DKIM charter.

The underlying goal of ADSP was to afford a domain control over the  
use of their domain within a From header field.  This goal can be  
fully met without stipulating that the DKIM signature be "on-behalf- 
of" the identity within the From header field.  The "on-behalf-of"  
should relate to what the domain authenticated, even when the "on- 
behalf-of" is opaque.   It is common for what is being authenticated  
by a provider to not be the email-address within the From header  
field.  Had SSP permitted an "ALL" assertion and a practice of the "on- 
behalf-of" to opaquely or otherwise reflect what the signing domain  
authenticated, then DKIM and ADSP would be effective at detecting Bot- 
Net related abuse, the current email/Internet plague.  Perhaps some  
stats will soon be published regarding this concern.  A link will be  
published when ready.

It even seems SSP might be attempting to sabotage DKIM's anti-abuse  
utility.  There is no ADSP assertion that a domain is not used to send  
or sign email, and ADSP "DISCARDABLE" at every node is how a domain  
might wish to protect their hierarchy.  Requiring the ADSP record to  
also be below the "_domainkey" makes it impossible to also know  
whether the domain does not publish DKIM public keys as well.  Rather  
than a term like DISMISSABLE, DISCARDABLE also implies that DSN can be  
lost.  SSP fails to even indicate that its assertions pertain to  
SMTP.  This lack of protocol specificity might therefore disrupt any  
message where the From header field domain is not published in DNS as  
a result of implied DNS existence.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 08 Oct 2008 22:28:17 +0100

Doug,

Firstly, this draft is not yet in IETF LC, so you've jumped the gun
a bit.

In any case, I believe you had, and took, a number of opportunities
to present your concerns at f2f meetings, on the list and in I-Ds
like the one cited below. However, you did not garner support
for your suggested changes. (Frankly, you didn't succeed in fully
explaining your concerns, at least I still don't quite get what
worries you.) But hopefully we'll get the benefit of IETF wide review
in the near future so maybe someone else will be able to see what
the DKIM list didn't.

Lastly, by "voting process," I guess you must mean the question I
asked after the end of WGLC, (thread at [1]). That wasn't a voting
process, it was me checking that relatively few WGLC comments didn't
reflect a lack of consensus, that the changes to handle the few WGLC
comments that were posted had been processed ok, and that there was
in fact no one at all on the list to speak up and agree with your
concerns. So, I checked, and we got a bunch of "+1" messages to
the effect that the draft was ready to send to the IESG and, so
far, zero messages agreeing with your position.

Stephen.

[1] http://mipassoc.org/pipermail/ietf-dkim/2008q3/010706.html

Douglas Otis wrote:
> There appears to be a factual error in the draft.  Any restrictive ADSP
> assertion such as "ALL" or "DISCARDABLE" creates an additional
> requirement for what valid DKIM signature remains valid with respect to
> compliance with ADSP assertions.
> 
> This section defines an Author Signature as a valid signature where the
> "on-behalf-of" (DKIM signature i=value or its default) matches against
> the From header field.
> 
> Since the DKIM key itself can assert a restriction upon the
> "on-behalf-of" local-part, there might be some justification to
> generally require signatures using local-part restricted keys to also
> match against the From header field before being considered valid.  It
> would be dangerous to only impose this requirement based upon the
> existence of an ADSP record.  SSP attempts to use DNS "SERVFAIL" to
> detect an attempt to block the ADSP records, but this status may not be
> apparent behind a resolver.  A conditional requirement is ill considered
> from a security standpoint, and may even invite abuse.
> 
> control over the Display Name being seen.  An MUA can always annotate a
> message to indicate specifically what portions of the message match
> against the DKIM signature's "on-behalf-of" and domain.   The SSP draft
> is conflating a valid DKIM signature and ADSP record into becoming an
> assertion of the identity of the message's Author.  Such conflation
> clearly and dangerously exceeds the DKIM charter.
> 
> The underlying goal of ADSP was to afford a domain control over the use
> of their domain within a From header field.  This goal can be fully met
> without stipulating that the DKIM signature be "on-behalf-of" the
> identity within the From header field.  The "on-behalf-of" should relate
> to what the domain authenticated, even when the "on-behalf-of" is
> opaque.   It is common for what is being authenticated by a provider to
> not be the email-address within the From header field.  Had SSP
> permitted an "ALL" assertion and a practice of the "on-behalf-of" to
> opaquely or otherwise reflect what the signing domain authenticated,
> then DKIM and ADSP would be effective at detecting Bot-Net related
> abuse, the current email/Internet plague.  Perhaps some stats will soon
> be published regarding this concern.  A link will be published when ready.
> 
> also be below the "_domainkey" makes it impossible to also know whether
> the domain does not publish DKIM public keys as well.  Rather than a
> term like DISMISSABLE, DISCARDABLE also implies that DSN can be lost. 
> SSP fails to even indicate that its assertions pertain to SMTP.  This
> lack of protocol specificity might therefore disrupt any message where
> the From header field domain is not published in DNS as a result of
> implied DNS existence.
> 
> -Doug
> 
> 
> 
> 
>

---

From: Douglas Otis <[email-masked]>
Date: Wed, 8 Oct 2008 19:11:09 -0700

On Oct 8, 2008, at 2:28 PM, Stephen Farrell wrote:

> like the one cited below. However, you did not garner support for  
> your suggested changes. (Frankly, you didn't succeed in fully  
> worries you.)

A praiseworthy goal of SSP, when widely adopted, would be as a  
mechanism to help limit the use of a domain in the From header field  
for email by requiring a signature by that domain.  Unfortunately SSP  
extends this goal to an area beyond their charter.  Who should cry foul?

For a signature to be compliant with even the lesser of the two ADSP  
restrictive assertions, the signature's "on-behalf-of"  or its default  
must match against the From header field, the message's author.  Why  
is that?

This contrived requirement prevents a proper use of the "on-behalf-of"  
field as a means to indicate what had been authenticated.  This  
authentication information is needed to better deal with replay abuse  
without collaterally blocking the entire domain.  The overhead of  
verifying two DKIM signatures will then be needed to accommodate an  
"on-behalf-of" not matching against the From header field.   Also as a  
result, the signature associated with the From header field is likely  
to be a blank "on-behalf-of".  Two signatures where one informative  
signature could have been employed is not being practical.  Requiring  
a domain's message to include a signatures that is "on-behalf-of" of  
the From header field is a bad practice.  This practice is wasteful.   
This practice is bad for the environment.  There is nothing gained by  
a blank "on-behalf-of" value, except as a requirement to implement  
this very bad practice.  As a rhetorical question, why would large  
domains not wish to give recipients any option other than all-or- 
nothing?  Clearly the "on-behalf-of" the From header field compliance  
requirement gives larger domains a distinct and unfair advantage in  
this respect.

Some large providers manage to control outbound traffic to where only  
5% of their traffic is likely the result of Bot-Net or bad-actor  
related abuse.  When considered within the context of a signature  
lacking meaningful replay abuse prevention, a blank "on-behalf-of"   
offers nothing to improve the situation.  There is also a real danger  
where message annotations that are based upon the existence of ADSP  
record and a DKIM signature might be seen by recipients as an  
assurance the From header field has been validated.  With the DKIM WG  
being within the Security Area, this should have been a concern, since  
ADSP compliance provides no other option than to have the DKIM  
signature be "on-behalf-of" the From header field.

> But hopefully we'll get the benefit of IETF wide review in the near  
> future so maybe someone else will be able to see what the DKIM list  
> didn't.

My hope as well.  I hope to see DKIM to offer a practical means for  
ushering in IPv6 email.  IPv6 is soon too massive and soon too tangled  
to be properly handled by black-hole lists.

> concerns. So, I checked, and we got a bunch of "+1" messages to the  
> effect that the draft was ready to send to the IESG and, so far,  
> zero messages agreeing with your position.

IMHO, the damaging decisions were not the result of mailing list  
discussions.  When attempting to discern what lead to the decisions,  
little can be discerned from a long series of empty votes.  The  
reference to voting was not about whether to go to last call.  Of  
course, this too was rather typical.  How is it that a statement of a  
factual error in the draft not find thoughtful discussion on the  
mailing list,  other than a vote on some suggested fixes?  The lack of  
reasoning goes to heart of the concern.  When asked for how or why a  
critical decision was made, an ensuing discussion offer an assurance  
that the reasoning was principled.  "You can always add two  
signatures" sounds too much like "Let them eat cake" from my  
perspective.

-Doug

>> ADSP
>> the
>> draft
>> use
>> whether