No new PKIs! (was: Re: [ietf-dkim] agenda item on upgrading hash algorithms?)

[Douglas Otis]

On Feb 22, 2006, at 5:30 PM, Mark Delany wrote:

> On Wed, Feb 22, 2006 at 05:11:37PM -0800, Douglas Otis allegedly  
> wrote:
>
>> Using this #37 RR was not a suggestion for developing yet another  
>> PKI.  This was suggesting the use of a DNS resource record defined  
>> by RFC2538.
>>
>> This RR imposes this header:
>>
>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>   |             type              |             key tag           |
>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>   |   algorithm   |                                               /
>>   +---------------+
>
> Right. A blob container. I see no functional difference from TXT.

The difference would be an assurance the information is not  
considered limited to 7 bit text, and that there is an IANA tag  
ensuring no collisions with other uses of the RR.  In addition, the  
#37 RR header will add significant value to a DKIM Key RR.   
Sourceforge links to applications using this RR was to offer  
illustrative examples of routines and utilities available.  If  
interested, a draft and example code for this DKIM Key RR could be  
provided.


> Do you propose extending RFC2538 to support the plethora of tags  
> currently defined in Selectors or do you want to hide those in the  
> blob?

The RFC2538 draft would not describe the DKIM key structure, as it  
does not describe any other structures for other protocols using this  
RR.  Only general overviews are provided.  There is no structural  
information provided beyond the #37 RR header.  A draft for the DKIM  
key structure, ideally in a binary TLV form, would define the tags  
below the #37 RR header.


> If you plan extension, do you have the support of the 2538 authors?

No changes to this draft appear needed.  IANA could reference the  
assigned Type to the draft defined by the DKIM wg.  The DKIM key and  
signature header amalgam could be considered an identity  
certification.  It should not be surprising to find the algorithm  
parameter already supports the current DKIM key.  Whatever algorithm  
the DKIM wg selects, this will likely cover similar work in this  
area.  There should be no conflicts created.


> If you plan blobs, are you certain that matches the intent of the  
> 2538 authors or have you not consulted them?

This was brought several up months ago.  At the time, concerns raised  
regarding DKIM's uses of this RR were related to the mention of DNS  
wildcard use.  In conjunction with DKIM or OpenPGP, such a wildcard  
record could be exploited as an attack vector to flood DNS caches.   
Some DNS servers do not fair very well in these scenarios.  This was  
not discussed in great detail, as there was greater focus upon other  
minutia.  As there is a vital need to support future upgrades of the  
DKIM Key RR that might not be accommodated by the TXT RR. Use of this  
RR for public keys should not set a precedent where this RR is  
considered nothing more than a blob container.

-Doug