Subject: [ietf-dkim] small question in draft-ietf-dkim-base-00.txt on TXT record

From: Tony Hansen <[email-masked]>
Date: Mon, 20 Feb 2006 15:49:58 -0500

We allow extra options to be specified in a DKIM-Signature header, but
do not allow extra options to be specified in a DKIM TXT record. (I
don't recall this being discussed before, but just may not remember it.)
Should we? If not, how would we do upwardly-compatible changes without
requiring multiple DNS entries for both an old and new entry.

	Tony Hansen
	[email-masked]
_______________________________________________
NOTE WELL: This list operates according to 
http://dkim.org/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Mon, 20 Feb 2006 13:13:50 -0800

On Feb 20, 2006, at 12:49 PM, Tony Hansen wrote:

> We allow extra options to be specified in a DKIM-Signature header,  
> but do not allow extra options to be specified in a DKIM TXT  
> record. (I don't recall this being discussed before, but just may  
> not remember it.) Should we? If not, how would we do upwardly- 
> compatible changes without requiring multiple DNS entries for both  
> an old and new entry.

DKIM should specify a binary structure used with the CERT RR.  This  
RR already offers fields defining the critical hash algorithm, for  
example.  By just specifying the hash used in signature header, once  
a hash algorithm is later discovered compromised, there is no means  
to keep bad actors from using this compromised hash algorithm for  
spoofing messages.  It would appear the DKIM draft is not ready.

-Doug

---

From: Arvel Hathcock <[email-masked]>
Date: Mon, 20 Feb 2006 16:18:28 -0600

> don't recall this being discussed before, but just may not remember
 > it.) Should we?

Yes we should.  I was under the impression that unknown options would 
simply be ignored.  That's the only way to make upwardly compatible 
change easily right?

-- 
Arvel

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Feb 2006 07:11:59 -0800

Douglas Otis wrote:
> By just specifying the hash used in signature header, once  a
> hash algorithm is later discovered compromised, there is no means  to 
> keep bad actors from using this compromised hash algorithm for  spoofing 
> messages.  It would appear the DKIM draft is not ready.

[page 21 allman-01:]

h=   Acceptable hash algorithms (plain-text; OPTIONAL, defaults to
       allowing all algorithms).  A colon-separated list of hash
       algorithms that might be used.  Signers and Verifiers MUST support
       the "sha1" hash algorithm.

What exactly is the problem?

		Mike

---

From: Douglas Otis <[email-masked]>
Date: Tue, 21 Feb 2006 12:34:46 -0800

On Feb 21, 2006, at 7:11 AM, Michael Thomas wrote:

>> hash algorithm is later discovered compromised, there is no means   

If using an improved hash algorithm of the same size, when it has  
been determined that SHA-1 no longer provides adequate protection,  
then this statement of MUST support SHA-1 _is_ the problem.  Also  
this is an optional text based parameter wasting a fair amount of  
_critical_ space.  There is no reason to start off using TXT RRs when  
a CERT RR offers a better immediate solution.  A 2048 bit key will  
soon become a required minimum.

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.

Using TXT to store this key consumes 345 bytes of information leaving  
only 141 bytes remaining.  Of those bytes, 8 bytes are used to  
indicate the version of the TXT record, leaving 133 bytes.  The  
"_domainkeys" label consumes another 14 bytes (assuming pointer  
compression in the answer section) and that leaves 119 bytes for name  
space.  Add in the overhead for wasteful text methods expressing  
allowed hash values and other parameters, there is then a high  
probability there will not be enough space left for the query and  
answer names. : (

There should be no problem using RFC2538 Cert RR for storing binary  
key needed for DKIM from the outset.  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 causing a potential security problem  
for future upgrades.

-Doug