On Apr 26, 2006, at 9:25 AM, Eliot Lear wrote:
Doug,
I know many don't like being so 1970ish, but to conserve DNS
payload space, here is one example. Introducing this change when
going to the binary key seems like a good choice.
While in principle I agree with you - in fact I was looking at ways
to compress other components of the record, I think we have to be
careful not to go too far down the line - the real boundary is 512
bytes. That gets us easily to key sizes of 2048 and probably 3072
if desired. 4096 is just not an option without either going to TCP
or EDNS0, no matter the key size. My point is I think this might
be a bit of over-optimizing. I would be more interested in making
the record easier to parse, but even here I'm not too concerned.
It seems a shame to waste 5 bytes that offer no information. The
down side is such a change in the label may mean delegating two zones
when transitioning to the binary key. The immediate concern is key
sizes of 2048 bits where every byte still matters. It will be hard
to predict how quickly the 576 byte MTU with the 512 byte DNS message
constraint is overcome, as this constraint is assumed in many network
products. A desire to permit a diversity of applications access to
this information will likely make these RRs perhaps the last able to
overcome message size constraints.
Another area to conserve space is use of a binary algorithm number as
normally used, rather than expressing algorithms as a text string.
The use of text strings will be problematic when also expressed as a
binary value in a key. Without an ability to verify the algorithm
the sender supports, a spoofed algorithm exploit becomes possible at
each algorithm transition. While a few bytes may not seem like much,
there is little to spare. Text strings for the algorithm are wasted
bytes in every message, where it also becomes cumulative with respect
to storage.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html