Subject: [ietf-dkim] Working Group Last Call on 4871bis

From: Barry Leiba <[email-masked]>
Date: Tue, 12 Apr 2011 16:14:51 -0400

Because of the extent of discussion, and the set of changes since the
last WGLC, we'll have another last call within the working group on
4871bis.  The editors are ready to submit a new version, which they
will do when they read this message.  Last call will be on that
version (Murray, please post to this thread after it's been
submitted), and will extend to the end of the month, ending on 30
April.

I'll note that there are a few suggestions that are NOT being
addressed in this version, because we do not have rough consensus to
make the changes.  If you brought something up that isn't reflected in
the upcoming version, it is not a question of your being "ignored" --
we need to see support for your suggestion in order to make the
change.

In particular, there's the issue of removal/deprecation of "i=", which
had a great deal of discussion.  There was significant support for
taking it out, but there was also significant support to keep it in.
As we said in Stockholm, when we discussed the process for removal of
features, the default action is to retain them, and we need rough
consensus for removal.  It's not there.

At this point, I ask that issues be brought out specifically and
individually.  Please post minor editorial things to this thread.  If
you still think there are substantive issues, please start a new
thread for each, and prefix the subject with "Issue:".  As we discuss
those, if any come up, let's keep the discussion focused on the issue,
and not wander off in other directions.  In particular, let's avoid
discussions of what we might change here and there, whether we like
ADSP or not, and so on.

I will also appreciate posts to THIS thread that say "I've reviewed
it, and it's ready to go."

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 12 Apr 2011 14:32:00 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Tuesday, April 12, 2011 1:15 PM
> To: DKIM Mailing List
> Subject: [ietf-dkim] Working Group Last Call on 4871bis
> 

draft-ietf-dkim-rfc4871bis-06 has been posted to the datatracker:

	http://datatracker.ietf.org/doc/draft-ietf-dkim-rfc4871bis/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 12 Apr 2011 16:44:59 -0700

> discussions of what we might change here and there, whether we like

Also, if you do open an issue, please include proposed alternate text for discussion.

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 Apr 2011 20:16:09 -0400

> it, and it's ready to go."

Concur.

But it be should be understood that "ready to go" maybe include 
recognition for amendments that is not just about nits or typos.

I'm ready to endorse the "ready to go" last call with one 
consideration that was now made possible by opening the door with the 
last minute Trust Assessment layer introduction in section 2.3.  That 
addition now makes Author Domain identity Policy Assessment to be 
equally considered as part of the DKIM specs.

So if we wish to preempt these nuisance discussions, we can a) 
continuing to ignore or shun it, b) add policy assessment semantics to 
help serve DKIM total deployment interest  or c) we can remove the 
independent trust assessment service evaluation layer semantic that 
should had been snuck in at the last minute in the first place without 
keeping it open ended.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: "John R. Levine" <[email-masked]>
Date: 12 Apr 2011 21:02:22 -0400

I wish I could say this is ready to ship, but it's not.

It's still full of language in which a verifier creates an edited version 
of the message, and a few other lies.  Here's the fixes, most of which I 
think I sent in last time. Assuming we agree that the verifier does not, 
in fact, create an edited message, none of them should be contentious:

3.4.5, first INFORMATIVE IMPLEMENTATION NOTE, last sentence: delete "or 
remove text that appears after the specified content length" since 
verifiers do not produce an edited message.

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.

3.5, l= tag, INFORMATIVE IMPLEMENTATION WARNING, remove "or remove text 
that appears after the specified content length" since verifiers don't 
produce an edited message.

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 only describes 
conversions for some, not 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.

3.6.2.1, Namespace: remove INFORMATIVE OPERATIONAL NOTE about wildcards, 
because the first sentence is just plain false.

6.1.3, next to last paragraph, remove "by truncating the message at the 
indicated body length" since verifiers do not create an edited message.

6.1.3, remove the INFORMATIVE IMPLEMENTATION NOTE at the end, which is 
entirely about creating the edited message that verifiers don't create.

6.3, remove next to last pp, "The verifier MAY treat unsigned header 
fields with extreme skepticism, including marking them as untrusted or 
even deleting them before display to the end user."

That's both because the verifier doesn't create an edited message, and 
because verifiers don't treat any field with any degree of scepticism. 
They take what they get.

6.3, last sentence: "should be rendered" -> "should be treated"

There's other stuff I would remove or fix if we had unlimited time, but 
these are the important ones.

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: Dave CROCKER <[email-masked]>
Date: Tue, 12 Apr 2011 18:17:33 -0700

> verifiers do not produce an edited message.
...
> produce an edited message.
...
> indicated body length" since verifiers do not create an edited message.

Replacing "remove" and "truncating"  with "ignore" and "ignoring" would 
accomplish the same correction while preserving the reminder about the effect of l=?

d/

-- 

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

---

From: "John R. Levine" <[email-masked]>
Date: 12 Apr 2011 21:24:16 -0400

> accomplish the same correction while preserving the reminder about the effect 

Look at the sections in context, and I think you'll agree that those bits 
should just go.  There's no question that the verifier ignores text beyond 
the l= limit, and in both places the text says so.  But it also says that 
the verifier can munge the message to delete the text it didn't verify, 
which is wrong.

Regards,

---

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

On Apr 12, 2011, at 1:14 PM, Barry Leiba wrote:

> Please post minor editorial things to this thread.

In 3.1, the examples of selectors are "january2005" and "february2005" and such, which clearly shows the age of the text.  Maybe update 'em to 2011?  (This may be the most minor nit ever.)

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

---

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

> In 3.1, the examples of selectors are "january2005" and "february2005" and
> such, which clearly shows the age of the text.  Maybe update 'em to 2011?

A reasonable suggest, and one which I'll leave to the whim of the
editors and not put in the tracker.

> (This may be the most minor nit ever.)

You look up "nit" in the dictionary, and they have a pointer to your post.

Barry, as issue-tracker-manager

---

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

> In 3.1, the examples of selectors are "january2005" and "february2005" and such, which clearly shows the age of the text.  Maybe update 'em to 2011?  (This may be the most minor nit ever.)

well, hell, if you want ageless, take out the year entirely and just leave month 
references...

i'm also tempted to suggest using months in a different language, with enero or 
Januari...

d/

-- 

   Dave Crocker

---

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

> i'm also tempted to suggest using months in a different language, with enero or

If you're going to change it, change it to 一月 or يناير

Regards,

---

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

> If you're going to change it, change it to 一月 or يناير

not after i just got done trying to avoid unicode issues...

d/

ps. barry is going to be busy, updating his links to 'nit'.
-- 

   Dave Crocker

---

From: Barry Leiba <[email-masked]>
Date: Wed, 13 Apr 2011 16:42:20 -0400

> not after i just got done trying to avoid unicode issues...

Damn.  And here I was going to suggest Czech, in honour of the last
DKIM IETF meeting place:

January -- leden
February -- únor
March -- březen
April -- duben
May -- květen

But those hačeks......
(I guess if we stick with January and April, we're OK.)

Barry

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 13 Apr 2011 13:53:27 -0700

> Sent: Wednesday, April 13, 2011 11:43 AM
> To: J.D. Falk
> Cc: DKIM Mailing List
> Subject: Re: [ietf-dkim] Working Group Last Call on 4871bis
> 

How about 2012, followed by "Some of the information in this RFC may contain projections or other forward-looking statements regarding future events or the future performance of DKIM.  We wish to caution you that these statements are only predictions and that actual events or results may differ materially."

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 13 Apr 2011 13:57:03 -0700

> Damn.  And here I was going to suggest Czech, in honour of the last

given how many of us caught the Prague Plague, let's not do anything extra to 
make the week memorable...

d/

-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Fri, 15 Apr 2011 16:21:22 -0700

> not after i just got done trying to avoid unicode issues...
DKIM has not properly considered the security ramifications related to 
IDN usage.

See http://tools.ietf.org/html/rfc6055#section-4
,---
Instead, conversion to A-label form, or any other special encoding
required by a particular name-lookup protocol, should be done only by
an entity that knows which protocol will be used (e.g., the DNS
resolver, or getaddrinfo() upon deciding to pass the name to DNS),
rather than by general applications that call protocol-independent
name resolution APIs. (Of course, applications that store strings
internally in a different format than that required by those APIs,
need to convert strings from their own internal format to the format
required by the API.) Similarly, even if an application can know
that DNS is to be used, the conversion to A-labels should be done
only by an entity that knows which part of the DNS namespace will be
used.
'---

See http://tools.ietf.org/html/rfc4952#section-4.2
,---
There are many places in MUAs or in a user presentation in which
email addresses or domain names appear. Examples include the
conventional From, To, or Cc header fields; Message-ID and
In-Reply-To header fields that normally contain domain names (but
that may be a special case); and in message bodies. Each of these
must be examined from an internationalization perspective. The user
will expect to see mailbox and domain names in local characters, and
to see them consistently. If non-obvious encodings, such as
protocol-specific ASCII-Compatible Encoding (ACE) variants, are used,
the user will inevitably, if only occasionally, see them rather than
"native" characters and will find that discomfiting or astonishing.
Similarly, if different codings are used for mail transport and
message bodies, the user is particularly likely to be surprised, if
only as a consequence of the long-established "things leak"
principle. The only practical way to avoid these sources of
discomfort, in both the medium and the longer term, is to have the
encodings used in transport be as similar to the encodings used in
message headers and message bodies as possible.
'---

The presumption of A-Label use within a domain name is likely wrong from 
a security or standardization perspective.  It would be incorrect to 
expect email applications using standard resolving APIs will only accept 
A-Labels.  Email should not depend upon an older view of a DNS 
limitation that does not exist.

Although the definition for a domain made in section 2.3.5 of RFC5321 
limits domains to ldh characters, this clearly represents an archaic 
definition in conflict with rfc6055 and rfc4952.  Users that see 
punycode versions for the signing domain, in conjunction with the UTF-8 
versions within email addresses are not afforded added comfort nor 
reliable assurances which resource had been selected when making the 
verification.

http://tools.ietf.org/html/rfc5321#section-2.3.5

Clearly, this issue requires at minimum a section added that reviews the 
issue and consensus established in how this information is to be 
encoded.  Clearly, the requirement to use A-labels binds DKIM to now an 
obsolete limitation.

Remove the requirement to use A-labels since SMTP and resolvers can not 
be expected to enforce this type of restriction.

-Doug

---

From: "John R. Levine" <[email-masked]>
Date: 15 Apr 2011 22:25:15 -0400

> name resolution APIs.

Wow.  This change would both be incompatible with 4871, and would put 
non-ASCII 8-bit characters into DKIM-Signature: headers, thereby making 
them invalid under RFC 5322 and getting them smashed by any 7bit MTA.

So, let's not do that.

Regards,

---

From: Douglas Otis <[email-masked]>
Date: Tue, 19 Apr 2011 14:43:57 -0700

On 4/15/11 7:25 PM, John R. Levine wrote:
> non-ASCII 8-bit characters into DKIM-Signature: headers, thereby 
> making them invalid under RFC 5322 and getting them smashed by any 
> 7bit MTA.
A and AAAA records serve as a discovery mechanism for SMTP rather than 
using MX records to ensure independence from DNS. For both OS X and 
Windows local name resolution services use UTF-8. Should email be 
expected to work between two hosts having non-ASCII host names resolved 
using UTF-8?

When SMTP allows the display of non-ASCII local-parts, the domain 
portion should also use UTF-8 as well. The DKIM verification process 
should therefore confirm the proper conversions. No one expects people 
to visually validate signatures, so why expect them to also validate 
puny-codes?

What does http://tools.ietf.org/html/rfc5321#section-2.3.5 say about 
FQDN. Would http://バスケ指導.meblog.biz/ qualify as a FQDN?

-Doug

---

From: "John R. Levine" <[email-masked]>
Date: 19 Apr 2011 18:35:27 -0400

Sorry, this message makes no sense.  The IETF has been working on 
non-ASCII domain names and e-mail for over a decade, and we are certainly 
not going to do random things that ignore that effort and the many RFCs 
that describe the use of IDNs in the DNS.

R's,
John

On Tue, 19 Apr 2011, Douglas Otis wrote:

> A and AAAA records serve as a discovery mechanism for SMTP rather than using 
> MX records to ensure independence from DNS. For both OS X and Windows local 
> name resolution services use UTF-8. Should email be expected to work between 
> two hosts having non-ASCII host names resolved using UTF-8?
>
> When SMTP allows the display of non-ASCII local-parts, the domain portion 
> should also use UTF-8 as well. The DKIM verification process should therefore 
> confirm the proper conversions. No one expects people to visually validate 
> signatures, so why expect them to also validate puny-codes?
>
> What does http://tools.ietf.org/html/rfc5321#section-2.3.5 say about FQDN. 
> Would http://バスケ指導.meblog.biz/ qualify as a FQDN?

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 19 Apr 2011 15:53:14 -0700

On Apr 19, 2011, at 3:35 PM, John R. Levine wrote:

> Sorry, this message makes no sense.  The IETF has been working on non-ASCII domain names and e-mail for over a decade, and we are certainly not going to do random things that ignore that effort and the many RFCs that describe the use of IDNs in the DNS.

Sounds like what we actually need is some way to point to the relevant work elsewhere in the IETF, even though it's apparently a moving target with many strong opinions continuing to shove it in multiple directions.  Is it permissible to simply reference the working group's tools page?

---

From: "John Levine" <[email-masked]>
Date: 19 Apr 2011 23:05:40 -0000

>> Sorry, this message makes no sense.  The IETF has been working on non-ASCII domain names and
>e-mail for over a decade, and we are certainly not going to do random things that ignore that
>effort and the many RFCs that describe the use of IDNs in the DNS.
>
>Sounds like what we actually need is some way to point to the relevant work elsewhere in the
>IETF, even though it's apparently a moving target with many strong opinions continuing to
>shove it in multiple directions.  Is it permissible to simply reference the working group's
>tools page?

The current language references RFC 3490, my proposed change
references RFC 5890, which supersedes 3490.  The title of 5890 is
"Internationalized Domain Names for Applications (IDNA): Definitions
and Document Framework."

How much more of a pointer does anyone need?

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Tue, 19 Apr 2011 16:33:13 -0700

On 4/19/11 3:35 PM, John R. Levine wrote:
> non-ASCII domain names and e-mail for over a decade, and we are 
> certainly not going to do random things that ignore that effort and 
> the many RFCs that describe the use of IDNs in the DNS.
The suggestion was to remove the MUST requirement to encode DKIM related 
domains within the header fields as A-labels.  This represents the wrong 
approach.

 From a security aspect, DKIM should also acknowledge there are no 
A-Label requirements for selectors and acknowledge the possibility that 
UTF-8 hostnames may resolve SMTP resources as well.

Lets review some of the RFCs then.

http://tools.ietf.org/html/rfc2277 section 2,
,---
Internationalization is for humans. This means that protocols are not
subject to internationalization; text strings are.
'---

http://tools.ietf.org/html/rfc5894#section-4.2
,---
The IDNA protocol does not
necessarily affect the interface between users and applications. An
IDNA-aware application can accept and display internationalized
domain names in two formats: as the internationalized character
set(s) supported by the application (i.e., an appropriate local
representation of a U-label) and as an A-label. Applications may
allow the display of A-labels, but are encouraged not to do so except
as an interface for special purposes, possibly for debugging, or to
cope with display limitations.
'---

http://tools.ietf.org/html/rfc2181#section-11
,---
The DNS itself places only one restriction on the particular
labels that can be used to identify resource records. That one
restriction relates to the length of the label and the full name.
The length of any one label is limited to between 1 and 63 octets.
A full domain name is limited to 255 octets (including the
separators). The zero length full name is defined as representing
the root of the DNS tree, and is typically written and displayed
as ".". Those restrictions aside, any binary string whatever can
be used as the label of any resource record. Similarly, any
binary string can serve as the value of any record that includes a
domain name as some or all of its value (SOA, NS, MX, PTR, CNAME,
and any others that may be added). Implementations of the DNS
protocols must not place any restrictions on the labels that can
be used.
'---

http://tols.ietf.org/html/rfc6055#section-3
,---
Shortly after the DNS Clarifications [RFC2181 
<http://tools.ietf.org/html/rfc2181>] and IETF character
sets and languages policy [RFC2277 <http://tools.ietf.org/html/rfc2277>] 
were published, the need for
internationalized names within private namespaces (i.e., within
enterprises) arose. The current (and past, predating IDNA and the
prefixed ACE conventions) practice within enterprises that support
other languages is to put UTF-8 names in their internal DNS servers
in a private namespace. For example, "Using the UTF-8 Character Set
in the Domain Name System" [UTF8-DNS 
<http://tools.ietf.org/html/rfc6055#ref-UTF8-DNS>] was first written in 
1997, and
was then widely deployed in Windows. The use of UTF-8 names in DNS
was similarly implemented and deployed in Mac OS, simply by virtue of
the fact that applications blindly passed UTF-8 strings to the name
resolution APIs, the name resolution APIs blindly passed those UTF-8
strings to the DNS servers, and the DNS servers correctly answered
those queries. From the user's point of view, everything worked
properly without any special new code being written, except that
ASCII is matched case-insensitively whereas UTF-8 is not (although
some enterprise DNS servers reportedly attempt to do case-insensitive
matching on UTF-8 within private namespaces, an action that causes
other problems and violates a subsequent prohibition [RFC4343 
<http://tools.ietf.org/html/rfc4343>]).
Within a private namespace, and especially in light of the IETF UTF-8
policy [RFC2277 <http://tools.ietf.org/html/rfc2277>], it was reasonable 
to assume that binary strings
were encoded in UTF-8.
'---

-Doug

---

From: "John R. Levine" <[email-masked]>
Date: 19 Apr 2011 20:55:28 -0400

> From a security aspect, DKIM should also acknowledge there are no A-Label 
> requirements for selectors and acknowledge the possibility that UTF-8 
> hostnames may resolve SMTP resources as well.

For reasons already discussed, no.  That's simply wrong.  Stop.

Regards,

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 20 Apr 2011 08:55:22 +0000

On 19 Apr 2011, at 22:43, Douglas Otis wrote:

> using MX records to ensure independence from DNS.

Not for this site, they don't. At least, not AAAA records. I suspect most sites don't use IPv6 for message transport, and therefore don't use AAAA records for discovery. 

When we do eventually get to IPv6 deployment, we won't accept mail from domains with neither A nor MX records, even if they do have an AAAA record. As long as there are significant numbers of sites without IPv6, you'll need an MX record or an A record to accept mail.

What we will do, of course, is accept authenticated submissions from clients with only AAAA records. Again, they won't be permitted to use return-path domains with neither A nor MX records.

> For both OS X and 

-- 
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148