On Sun, 2006-03-19 at 11:37 -0600, Paul Hoffman wrote:
At 8:27 AM -0800 3/19/06, Douglas Otis wrote:
Of those bytes, 8 bytes are used to the version of the TXT record,
leaving 131 bytes. The "_domainkeys" label consumes another 14 bytes
(assuming pointer compression in the answer section) and that leaves 117
bytes for name space. From this space, one or more selector labels with
together with the labels for the parent domain must be accommodated
which consumes an additional one byte per label plus the label sizes.
That sounds correct. And thanks for correcting my miscalcuation of
base64ing the key.
This might seem okay until subtracting from this remainder the overhead
of comparatively wasteful text methods for expressing allowed hash
values and other parameters, and then there is then a much higher
probability this will exceed the DNS UDP message constraint.
...and here is where I get confused. I don't see anything in the base
spec that uses any other hashed values, and the other parameters take
up small tens of bytes.
I'm not saying that a binary representation is not good, just
questioning the "need" for it. It doesn't seem needed by the current
spec, and the current implementations seem just fine (although that
is probably due to using 1024-bit keys, freeing up 170 bytes).
About 1 byte per label overhead in the question and answer, with pointer
compression, this could be viewed as 3 bytes per label. The remaining
117 bytes is quickly consumed with the ASCII options being expressed.
As these become needed in the future, increasing the size of these
parameters will likely also occur and perhaps become problematic.
For example just the g= parameter might contain a 64 byte local-part
with three bytes of syntax. The remaining space is now only 50 bytes.
With 5 labels, a selector and a four label domain, this now leaves 35
bytes. The other parameters must still be defined. When a dozen bytes
are used for expressing the permitted hash algorithms, and another half
dozen to express the type of key, the average label size is going to
become rather small when taken from the remaining dozen bytes. Of
course there is also a list of applications that might be needed for the
s= parameter as well. : (
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html