Subject: [ietf-dkim] ISSUE: non-ascii header text

From: "John Levine" <[email-masked]>
Date: 13 Apr 2011 06:31:42 -0000

Oops, this is a separate issue.  But I hope it's also not
contentious.

3.5, d= and i= tags: references to RFC3490 should be RFC5890. The
reference to ToASCII() should go, or else in both places say IDNs are
represented as A-labels.

Suggested new language under d= on page 22:

Change: Internationalized domain names MUST be encoded as described in
      [RFC3490].

To:  Internationalized domain names MUST be represented as A-labels
     as described in [RFC5890].

Suggested new language under i= on page 23:

Change: Internationalized domain names MUST be converted using the steps
      listed in Section 4 of [RFC3490] using the "ToASCII" function.

To:  Internationalized domain names MUST be represented as A-labels
     as described in [RFC5890].

3.5, z= tag, remove paragraph "Header fields with characters requiring
 conversion (perhaps from legacy MTAs that are not [RFC5322] compliant)
 SHOULD be converted as described in MIME Part Three [RFC2047]."

DKIM only applies to RFC5322 compliant messages, RFC2047 does not
provide conversions for all of the fields that can be copied in a z=
header, and as soon as the EAI RFCs come out, which is likely to be
soon, this advice will be wrong anyway.

Free extra bonus confusion: the EAI WG is working on 5322 extensions
that basically allow UTF-8 anywhere in messages handled by EAI-aware
mail software, specifically including anywhere in an e-mail address.
(That is, the domain part does not have to be an A-label.)  I think it
is reasonable to assume that a DKIM-Signature in an EAI message can
include UTF-8 characters in any data field where it makes sense, e.g.,
d=, i=, s=, z=.  DKIM-quoted-printable doesn't need to change since
there's no need to quote any non-ASCII UTF-8 characters.

The only thing that's not obvious to me is whether the hash functions
should hash the bytes of the UTF-8, or convert them to UTF wide
characters and hash those.  Depending on the way the MTA is written,
either might seem more "natural", but I'm inclined to say you hash the
UTF-8 bytes because the SHA-1 and SHA-256 hash functions are defined
on bytes, not wider things.

R's,
John

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John R. Levine" <[email-masked]>
Date: 13 Apr 2011 02:38:50 -0400

Oh, one other thing:

3.5, s= tag.  Since the selector is components of a domain name, they can
also be IDNs, so on page 26, between the sentence describing s= and the ABNF:

Add:  Internationalized domain names MUST be represented as A-labels
      as described in [RFC5890].

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 13 Apr 2011 10:31:46 -0700

I'm generally in favor of updating the document to match the current state of IDN and EAI work, but I don't know it well enough to comment intelligently on whether John's proposed text does so.

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions

---

From: Barry Leiba <[email-masked]>
Date: Wed, 13 Apr 2011 14:40:38 -0400

> I'm generally in favor of updating the document to match the current state of
> IDN and EAI work, but I don't know it well enough to comment intelligently on
> whether John's proposed text does so.

What John has looks right to me, and is consistent with earlier advice
from John Klensin and with what the IRI group has done.

Barry, as participant

---

From: "John R. Levine" <[email-masked]>
Date: 13 Apr 2011 15:24:39 -0400

> one spec should not try to track fluid developments of other specs.  it 
> should cite stable specs, and preferably ones that have gained adoption.

Agreed.  That's why I only cited 5890.

The other comments were basically saying that as far as I can tell, once 
we take out the reference to 2047 (which we should do anyway), nothing 
we're doing has obvious unpleasant interactions with the current state of 
EAI, so even if we felt like doing something, there'd be nothing to do.

Regards,

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 13 Apr 2011 12:07:17 -0700

> I'm generally in favor of updating the document to match the current state of IDN and EAI work, but I don't know it well enough to comment intelligently on whether John's proposed text does so.

as phrased, I'll disagree with this.

one spec should not try to track fluid developments of other specs.  it should 
cite stable specs, and preferably ones that have gained adoption.

anything more than that is attempting to predict the future.  in the case of 
internationalized character issues, that's proved problematic for at least 20 
years...

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 13 Apr 2011 14:17:20 -0700

On Apr 13, 2011, at 12:07 PM, Dave CROCKER wrote:

> one spec should not try to track fluid developments of other specs.  it should cite stable specs, and preferably ones that have gained adoption.

Yeah, that's a good point.  If that work isn't stable yet, it may be better to simply point to the working group.

---

From: Hector Santos <[email-masked]>
Date: Wed, 13 Apr 2011 18:40:02 -0400

Dave CROCKER wrote:
> one spec should not try to track fluid developments of other specs.  
> it should cite stable specs, and preferably ones that have 
> gained adoption.
>
> anything more than that is attempting to predict the future.  in the 
> case of internationalized character issues, that's proved 
> problematic for at least 20 years...

+1.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 19 Apr 2011 22:53:24 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Levine
> Sent: Tuesday, April 12, 2011 11:32 PM
> To: [email-masked]
> Subject: [ietf-dkim] ISSUE: non-ascii header text
> 
> [...]

Since I'm not exactly an EAI/IDNA expert...

> on bytes, not wider things.

Can you suggest the exact change to make here, or confirm there isn't one?

---

From: Hector Santos <[email-masked]>
Date: Wed, 20 Apr 2011 04:24:26 -0400

> or confirm there isn't one?

Murray,

I viewed this as another layer issue. Adding a DKIM-Signature: header 
is no different than any other RFC5322 header where UTF8 conversion is 
already a consideration.  But maybe to provide guidance for what parts 
of the DKIM-Signature RFC5322 header needs to be UTF8 ready, I think 
that might the following text is useful.

     RFC5322 messages should be prepared with UTF-8 readiness
     when required. For the DKIM-Signature RFC5322 header,
     implementators SHOULD focus on tags d=, s= and i= to be
     UTF8 ready.

I think the above will help implementators with the engineering 
incentive for UTF8 conversions is more for general mail operations 
than it is specifically for DKIM.

--
HLS

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 20 Apr 2011 12:45:17 +0100

>      implementators SHOULD focus on tags d=, s= and i= to be

Is there anything that actually needs to be done with a UTF-8 header that  
is not covered already in our DKIm spec.?

The EAI effort, whilst still formally in the "experimental" stage, is on  
the verge of becoming a Proposed Standard. Indeed, it may even get there  
before we do. So we may as well ensure that DKIM is compatible with it;  
otherwise we shall be asked to make it compatible during AUTH48.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   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
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John Levine" <[email-masked]>
Date: 20 Apr 2011 13:29:48 -0000

>Can you suggest the exact change to make here, or confirm there isn't one?

No change needed, it's all hypothetical at this point anyway.

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 20 Apr 2011 10:09:27 -0400

> is not covered already in our DKIm spec.?

No, it's fine, so long as we make my proposed changes that clarify that 
the bits of domain names in the DKIM-Signature: header (d= i= s=) are 
represented as A-labels.

Regards,

---

From: Hector Santos <[email-masked]>
Date: Wed, 20 Apr 2011 14:57:18 -0400

> is not covered already in our DKIm spec.?

The heads up is mentioned (in an odd way), but I think John's proposal 
to define it as A-label is probably the right way.

-- 
HLS

---

From: Douglas Otis <[email-masked]>
Date: Wed, 20 Apr 2011 14:27:14 -0700

> the bits of domain names in the DKIM-Signature: header (d= i= s=) are
http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis-06#section-3.5

d= ...
       Internationalized domain names MUST be encoded as described in
       [RFC3490  <http://tools.ietf.org/html/rfc3490>].

Should be changed to:

Internationalized domain names MUST be encoded as Non-Reserved LDH, 
A-Labels as described in RFC5891, or equivalent U-Labels.  Validation 
therefore ensures U-Labels resolve DKIM resources published at valid 
A-Labels.  In some cases, labels that were valid per RFC3492 may need 
corresponding resources published at different domains. This may entail 
expressing labels using only lower case characters, for example.  
U-Labels SHOULD be used whenever UTF-8 is known to be supported by the 
receiver.  Otherwise, recipients will be unable to discern relationships 
with email domains also expressed in UTF-8 when A-Labels are used within 
DKIM header fields.

-Doug

---

From: "John R. Levine" <[email-masked]>
Date: 20 Apr 2011 20:02:51 -0400

> A-Labels as described in RFC5891, or equivalent U-Labels.

Repeating this bad idea doesn't make it a good idea,

Besides being a bad idea on its own merits, this would without question 
require us to recyle at proposed standard.

Regards,

---

From: Douglas Otis <[email-masked]>
Date: Thu, 21 Apr 2011 01:34:08 -0700

> require us to recyle at proposed standard.

John,

Use of A-labels within header fields supporting UTF-8 is a bad idea.

Changing a reference of RFC3490 to RFC5890 already represents an 
incompatible change. Clarify use of resources MUST be at NR-LDH or valid 
A-Labels whether or not U-Labels are used within headers.  Mandating use 
of A-labels within header fields defeats the internationalization effort 
and is wrong.

-Doug

---

From: "John R. Levine" <[email-masked]>
Date: 21 Apr 2011 08:25:35 -0400

> Use of A-labels within header fields supporting UTF-8 is a bad idea.

Since DKIM is defined on RFC 5322 messages, and 5322 is ASCII-only, no 
header fields in a compliant message can contain UTF-8.  I don't know why 
you keep repeating this uttetly wrong stuff, but please stop now.

> Changing a reference of RFC3490 to RFC5890 already represents an incompatible 
> change.

Your assertion is noted.

Regards,

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 21 Apr 2011 17:49:35 +0200

On 21/Apr/11 14:25, John R. Levine wrote:
> header fields in a compliant message can contain UTF-8.

It would be surprising if DKIM supported UTF-8 in the header, since it
recommends 7bit encodings for the body  :-/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Thu, 21 Apr 2011 10:57:24 -0700

On 4/21/11 5:25 AM, John R. Levine wrote:
> header fields in a compliant message can contain UTF-8.  I don't know 
> why you keep repeating this uttetly wrong stuff, but please stop now.
http://tools.ietf.org/html/draft-ietf-eai-rfc5336bis-09

While the majority of users within your borough may not care, a large 
population within Asia and elsewhere do.  In fact, much of their email 
already violates RFC5322's ASCII-only requirements.  This limitation 
will change very soon.  Setting DKIM on a sustainable track must deal 
with this natural evolution, despite those saying please stop.  You are 
a good and intelligent person that deserves a great deal of respect.
>> incompatible change.
The desire is not to increase anyone's workload, but the reasons for 
developing DKIM will become even more apparent during the introduction 
of UTF-8.  Unfortunately, the current DKIM specifications ignore 
important aspects about where A-Labels are to exist within a protocol.  
A-Labels are NOT intended for human consumption.   DKIM also failed to 
ensure resources are only obtained at valid A-Labels or NR-LDH defined 
locations.  A significant security flaw, especially when definitions of 
valid A-Labels has significantly changed for the better.

-Doug

---

From: "John R. Levine" <[email-masked]>
Date: 21 Apr 2011 17:23:11 -0400

> already violates RFC5322's ASCII-only requirements.

I have trouble reading this as other than "we're going to leapfrog 
everything that EAI is doing in this minor DKIM revision."

In any event, I'll leave it to the chairs whether they see any support for 
making incompatible changes to support (as opposed to detect or reject) 
messages that are explicitly not 5322.

Regards,

---

From: Hector Santos <[email-masked]>
Date: Fri, 22 Apr 2011 18:19:46 -0400

>> Your assertion is noted.

John, it is correct to reference RFC5890 but for any implementations 
that currently have RFC3490 support there is a conflict verifiers need 
to be aware of. A proposed text change addendum as follows is both 
protocol consistent and provides compatibility insight:

     Internationalized domain names MUST be represented as A-labels
     as described in [RFC5890].  For public key lookups, verifiers
     MUST transform internationalized domain names already encoded as
     described in [RFC3490] to A-labels.

or in less text without a RFC3490 reference:

     Internationalized domain names MUST be represented as A-labels
     as described in [RFC5890] for both DKIM-Signature domain values
     and for Public Key DNS lookups.

> of UTF-8.  

IMO, if someone begins to start thinking about UTF8 support for DKIM, 
they will need to view this expensive revamping for their general 
5321/5322 mail I/O operations.  In the mean time, AFAMUG, RFC5890 
offers an isolated DKIM transition for implementing in operations not 
yet wrapped with Unicode support.

> Unfortunately, the current DKIM specifications ignore 

Are we not specifying all the IDNs within RFC5322 including 
DKIM-Signature, in particular d=, s= and i=?

> A-Labels are NOT intended for human consumption.   

+1, neither is Unicode outside their locales. But displays are 
expected to translate all that for human viewing.

> DKIM also failed to ensure resources are only obtained at valid 
> A-Labels or NR-LDH defined locations.  

Does that mean we need affirmation if we are just talking about 
A-label as input for DNS lookups only.

> A significant security flaw, especially when definitions of

Lost me.  Better for security? Or worst?  Or better for something 
else, worst for security?

-- 
HLS