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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 20 Feb 2006 13:43:01 -0800

The CERT RR is utterly useless for our purposes unless you are confident
in the ability of DNS to move DNS messages of at least 2Kb reliably. My
expectation is that you end up in TCP/IP fallback as mandated in the
original DNS spec at 500 bytes.

If you can move packets of that size the need for binary encoding
vanishes.

All the other claims and conclusions reached by Doug are hereby rejected
and refuted as if set out here seriatim.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Douglas Otis
> Sent: Monday, February 20, 2006 4:14 PM
> To: Tony Hansen
> Cc: IETF DKIM WG
> Subject: Re: [ietf-dkim] small question in 
> draft-ietf-dkim-base-00.txt on TXTrecord
> 
> 
> 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
> 
> 
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://dkim.org/ietf-list-rules.html
> 
> 

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

---

From: Douglas Otis <[email-masked]>
Date: Mon, 20 Feb 2006 15:02:41 -0800

On Feb 20, 2006, at 1:43 PM, Hallam-Baker, Phillip wrote:
>>  Douglas Otis wrote:
>> 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.
>
> The CERT RR is utterly useless for our purposes unless you are  
> confident in the ability of DNS to move DNS messages of at least  
> 2Kb reliably.

2048 bits represents 256 bytes of binary data easily and reliably  
stored using the #37 RR.  In addition, the #37 Cert RR also provides  
a method to reference other key acquisition options in the event  
something is needed that DNS can not provide.

http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2538bis-09.txt

      Value  Mnemonic  Certificate Type
      -----  --------  ----------------
          0            reserved
          1  PKIX      X.509 as per PKIX
          2  SPKI      SPKI certificate
          3  PGP       OpenPGP packet
          4  IPKIX     The URL of an X.509 data object
          5  ISPKI     The URL of an SPKI certificate
          6  IPGP      The URL of an OpenPGP packet
          7  ACPKIX    Attribute Certificate
          8  IACPKIX   The URL of an Attribute Certificate
      9-252            available for IANA assignment
        253  URI       URI private
        254  OID       OID private
  255-65023            available for IANA assignment
  65024-65534          experimental
      65535            reserved

With a draft describing the data structure, this could be expanded to:
      Value  Mnemonic  Certificate Type
      -----  --------  ----------------
          9   DKIM      DKIM Binary Key
         10   IDKIM     The URL of a DKIM Key Server

> My expectation is that you end up in TCP/IP fallback as mandated in  
> the original DNS spec at 500 bytes.

The minimum MTU of 576 bytes constrains DNS messages to 512 bytes.

> If you can move packets of that size the need for binary encoding  

If the goal is to handle 2k bit keys, the need for binary encoding is  
paramount.  Otherwise, something other than DNS is required, like a  
key server or perhaps DNSsec. : (

-Doug