On Feb 22, 2006, at 11:11 AM, Jon Callas wrote:
The only question facing us is whether we jump straight to SHA-256
now, or allow both. Jumping is cryptographically wiser as it gets
us off the weak hash. Allowing both is engineeringly wiser as it
forces us to be agile now. Neither is a bad choice, sadly. If one
were a bad choice, then it would be easy. As things sit, we have a
hard choice, and no matter what we do, people will look back with
the wisdom of hindsight and cluck their tongues sadly about how
stupid we were and how *clearly* it would have been better to do
the other thing.
There is an equally important question related to this question.
Adopting an IANA index of the signature/hash algorithms as found with
RFC2538 rather than expressing this as a textual representation,
suggests one area not well covered. This does not require hindsight
as OpenPGP has already has made an appropriate choice for a binary
resource record and binary representation of algorithms. Following
their example, it is already apparent what should be done. When
considering the servers and clients must be modified anyway,
switching to this resource record type to afford a binary format puts
DKIM in step with the rest of the industry.
Do not declare there is a way to upgrade, when it relies heavily upon
defaults that are sure to change. When these defaults change, the
information does not fit within the existing TXT resource record.
DNS 512 -12(dns header) -5(question) -9(answer) = 486
Assuming pointer compression, add 3 bytes per label of additional
overhead.
Now look at the DKIM TXT record:
8 "v=DKIM1;" 8 bytes,
66 "g=some-local-part"; 0-66 bytes,
8 "h=SHA1:SomeNewHash"; 8+N bytes,
3 "k=SomeNewKeyType;" 3+N bytes,
0 "n=Notes;" 0-N bytes,
345 "p=base64key;" 345 bytes (2048 bit key)
9 "s=email:SomeOtherApp;" 9+N bytes,
0 "t=y; 0-3 bytes,
----
439 --> 47
The "_domainkeys" label needs 14 bytes --> 33.
Assume the domain uses a selector and 4 other labels within their
domain, (in addition to the "_domainkeys" label) then another 15
bytes are needed.
33 - 15 = 18 bytes
Discard support for "g="?
Switching to the binary #37 RR saves 100 bytes without requiring
additional space to define future algorithms.
Out of these 18 bytes, new hash, key, and apps must be defined, in
addition to forming the 5 remaining labels. This represents less
than 3 characters remains for each instance. Is there a simple means
to upgrade the DKIM key? No, not when using a TXT RR.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html