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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 21 Feb 2006 09:10:00 -0800

I do not see the value in having a pointer to a CERT record with a
pointer to a cert over a pointer to the cert.

If the idea is to replace the existing key format with self signed
X.509v3 certificates it ignores the long (and justified) history of
ASN.1 hatred in the IETF. 

> -----Original Message-----
> From: Douglas Otis [mailto:[email-masked]] 
> Sent: Monday, February 20, 2006 6:03 PM
> To: Hallam-Baker, Phillip
> Cc: IETF DKIM WG
> Subject: Re: [ietf-dkim] small question in 
> draft-ietf-dkim-base-00.txt on TXTrecord
> 
> 
> On Feb 20, 2006, at 1:43 PM, Hallam-Baker, Phillip wrote:
> >>  Douglas Otis wrote:
> >>
> >> 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.
> >
> > 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-rfc2538b
> is-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 
> > vanishes.
> 
> 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
> 
> 
> 
> 
> 

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

---

From: Douglas Otis <[email-masked]>
Date: Tue, 21 Feb 2006 16:39:23 -0800

On Feb 21, 2006, at 9:10 AM, Hallam-Baker, Phillip wrote:
> Douglas Otis wrote:
>>
>> 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
>>
>> If the goal is to handle 2k bit keys, the need for binary encoding  
>> is paramount.
>

The suggestion for using #37 RR for offering a URL vector to the  
"Next means of obtaining the DKIM information" was to circumvent  
future hunting.

> ASN.1 hatred in the IETF.

A data structure defined by the #37 RR type is not limited to X.509  
certificates.  There are many experimental values for use, pending a  
draft being accepted that defines a suitable DKIM public key binary  
structure.  The DKIM test server would need to transition from  
accepting an experimental type value to the assigned value.  To  
further reduce DNS payloads, a signature conventions could  
differentiate DKIM from that of DomainKeys, where then a label  
"_dkim" could also replace the "_domainkeys" label where just #37 RR  
would be obtained.  The use of a binary key format from the outset  
prevents the need for multiple lookups and better ensures use of 2048  
bit keys will not become a problem.  #37 RR more than doubles the  
otherwise limited name space.

-Doug