ietf-dkim
[Top] [All Lists]

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

2006-03-20 13:36:49

Defining a new DKIM specific RR type for DNS will take about the same time
as defining a new CERT type! Furthermore adding a unsigned keying information
into the CERT record will run into resistance as this is not a
properly formatted certificate.

As for the 512 size restriction that was addressed by EDNS0 (RFC2671)
RFC2671 was issued in 1999. Most DNS software in serious use should
support it by now.
DKIM DNS usage requires DNSSEC in which case not having EDNS0
support is fatal.

I would say that the issue is twofold:
Mail servers that intent to do DKIM verifications, MUST have
local DNS stub resolver that support ENDS0 and MUST talk to recursive
nameservers that support EDNS0. (may want to add text that defines
lower limit of buffer size (see RFC3226)).

Sites that sign outgoing messages with DKIM MUST use authorative
nameservers that support ENDS0.

        Olafur
PS: Is the DKK record specification available anywhere ?

At 11:27 19/03/2006, Douglas Otis wrote:
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