ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] New Issue: 512 too short?

2006-03-19 09:34:18
On Sat, 2006-03-18 at 21:29 -0600, Paul Hoffman wrote:
At 4:20 PM -0800 3/17/06, Douglas Otis wrote:
With respect to 2048 bit keys, there is already a placeholder in the 
base draft for developing a much needed binary DKIM key.

Why is a binary representation "much needed"? A 2048-bit key will 
only take up 320 of the 512 bytes allowed. Or am I missing something?

The DNS Message is constrained to 512 bytes. 12 bytes are part of the
DNS message header, the query has 5 bytes plus the name size plus one
byte per label overhead, the answer has 9 bytes + 1 byte per label
followed by the RR data.  Not including the name space, there are only
486 bytes available for data.

As defined using base64 (6 bits per byte) and ASCII parsing syntax,
using TXT character-strings to store this 2048 bit key consumes 345
bytes (plus two bytes for defining the two character-string lengths) and
leaves 139 remaining bytes.

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.

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.

The RFC2538 Cert RR can store binary keys needed for DKIM.  The 5 byte
CERT header overhead specifying the type of key, key-tag, and algorithm
is already less than the Version tag used for the TXT record.  The CERT
header clearly assures the algorithm has been defined without resorting
to default or mandated parameters, which may cause a potential security
problem for future upgrades or introduce problematic size constraint
issues confounding an upgrade.

Using binary to store the key should only require 258 bytes which saves
87 bytes from that used by the TXT RR approach.  This savings, together
with binary algorithm definitions, ensures future algorithm upgrades or
features or even utilizing some of the current features are not be in
jeopardy.

-Doug



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