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

[Ólafur Guðmundsson]

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