Barry,
At first I thought your backward compatibility (BC) proposal would be a
compromise but I changed my mind based on proven history where BC
considerations caused more harm and got us to the point we are today.
If DKIM was a standard today and widely adopted, I can understand the BC
concern. The fact is, it is not a standard, a protocol still in flux and it
is not, by far, widely adopted. Not even close. It is still extremely
isolated and today, I can not in good conscious, help promote or support a
new protocol for implementation that is,.... well.... half-baked!"
In any case, if BC is to be considered, here is my input:
1) Signing requirement, and
2) Migration.
1) Signing requirement.
I don't see the tie-in between the ALG and the BodyHash proposal. I see
this as an independent issue. Even though I think we need to encourage
SHA256, I still see it as an viable option to use a lower footprint SHA1.
There are many possibilities where we don't need the higher strength.
2) Migration
This isn't like SMTP where we had nearly 10-12 years (1982 to 1994) of HELO
only transactions before EHLO was invented and we had no choice and it made
sense to support both HELO and EHLO.
Once the standard is official and DKIM is shown to be a feasible
consideration, I find it hard to believe that early adopters, who indeed
took it upon themselves to adopt DKIM early for whatever reasons, marketing
or experimentation, and in fact were a major participants of its
development, if not the key cogs and inventors, will not bother to
support/upgrade to official standard adaptation.
I believe most systems will follow the official standard first and raise
eyebrows about supporting those early adoptions that might be weaker than
the official standard.
In fact, if this is proven to be the case, as history has proven already
with SMTP, we open up a threat entry point where bad actors will not bother
to support the "official standard" because there would be a "early version
loophole." That's the problem with have today with SMTP compliance -
atleast 80% are not compliant forcing us to add new layers of security.
Unlike the 821 to 2821 transition era, would it be possible to have a
"Migration" concept this time around?
Suggestions only:
A section specific to Early Adopters:
Section x.y:
Early adopters are HIGHLY encouraged to migrate to the official
standard as soon as possible. See section x.y+1
A section specific for Verifiers supporting Early Adopters:
Section x.y+1
Verifiers ARE NOT required to support early adopters over a extended
period,
especially if it is deemed harmful to support early adopters. A
migration period
of XYZ months may be considered. SMTP-level DKIM implementations
MAY issue a 55x "DKIM Version Not Supported" response..... etc.
In any case, maybe none of the above would be necessary because I just find
it hard to comprehend that the early DKIM adopters investing in DKIM today
are just going to STOP and not use the official standard. I find that a
very strange though that vendors will invest R&D time and resources for
something "experimental" in nature today and don't plan to further change it
when the official specs are released. Why should the majority of the world
be compromise because of the premature early adoption decision to add a
non-standard DKIM unfinished protocol into production products? If it is
shown that non-standard DKIM is weaker than standard-DKIM, can anyone
explain to me why BAD actors will avoid the non-standard version?
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Barry Leiba" <leiba(_at_)watson(_dot_)ibm(_dot_)com>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Friday, March 24, 2006 6:54 PM
Subject: Re: [ietf-dkim] 1193 considered harmful
I have a suggestion that I think might (ha!) satisfy everyone. That is,
I THINK it will satisfy those who want the separate body hash, it will
address Mike's compatibility concern, and it will not give Mark hives
because of overloaded tags and burgeoning combinatorics.
Suppose the base doc said this sort of thing:
---------------------------------------------------------
... signers MUST use a=rsa-sha256 ...
... hash the body and put the hash value in bh= ...
... hash the headers, sign that hash, put the signature into b= ...
... etc, etc, etc ...
Section x.y: Backward compatibility with the pre-standard version
Earlier, pre-standard implementations of DKIM used a different hash
mechanism. Owing to significant deployment of that mechanism for early
adoption and experimentation/refinement leading to this specification,
current implementations SHOULD maintain signature-verification
compatibility with the earlier version as follows:
1. Support the SHA-1 hash algorithm, and recognize and respect the
a=rsa-sha1 tag.
2. Support the earlier mechanism of using a single hash, as indicated by
the absence of bh=, by computing the message hash thus: <describe how
to put the headers and body together for the hash here, noting that the
canonicalization is identical>
Verifiers MUST NOT accept a=rsa-sha1 in the presence of bh=, and MUST
NOT accept the absence of bh= in the presence of a=rsa-SHA256; those
combinations are contrary to this specification, and their use is
NON-COMPLIANT.
---------------------------------------------------------
What do y'all think (I picked that up in Dallas)?
Barry
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html