Subject: [ietf-dkim] dkim-base: _domainkey vs _dkim

From: "Hector Santos" <[email-masked]>
Date: Wed, 26 Apr 2006 07:36:12 -0400

The document refers to both _domainkey vs. _dkim subdomains to DNS DKIM
records:

| 3.6.2.1  Name Space
|
|    All DKIM keys are stored in a subdomain named ""_domainkey"".  Given
|    a DKIM-Signature field with a "d=" tag of ""example.com"" and an "s="
|    tag of ""sample"", the DNS query will be for
|    ""sample._domainkey.example.com"".

and

| A.3  The email signature is verified
|
|    The signature is normally verified by an inbound SMTP server or
|    possibly the final delivery agent.  However, intervening MTAs can
|    also perform this verification if they choose to do so.  The
|    verification process uses the domain "example.com" extracted from the
|    "d=" tag and the selector "brisbane" from the "s=" tag in the "DKIM-
|    Signature" header field to form the DNS DKIM query for:
|
|    brisbane._dkim.example.com

How is this going to be handled?  Most testing domains are using _domainkey
or is _dkim targeted for a binary RR?

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

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

---

From: Michael Thomas <[email-masked]>
Date: Wed, 26 Apr 2006 06:24:09 -0700

>or is _dkim targeted for a binary RR?
This is just a typo. A.3 should be _domainkey as well.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Wed, 26 Apr 2006 08:33:37 -0700

> This is just a typo. A.3 should be _domainkey as well.

I know many don't like being so 1970ish, but to conserve DNS payload  
space, here is one example.  Introducing this change when going to  
the binary key seems like a good choice.

-Doug

---

From: Eliot Lear <[email-masked]>
Date: Wed, 26 Apr 2006 18:25:18 +0200

Doug,
> space, here is one example.  Introducing this change when going to the
> binary key seems like a good choice.

While in principle I agree with you - in fact I was looking at ways to
compress other components of the record, I think we have to be careful
not to go too far down the line - the real boundary is 512 bytes.  That
gets us easily to key sizes of 2048 and probably 3072 if desired.  4096
is just not an option without either going to TCP or EDNS0, no matter
the key size.  My point is I think this might be a bit of
over-optimizing.  I would be more interested in making the record easier
to parse, but even here I'm not too concerned.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Wed, 26 Apr 2006 18:50:56 +0200

Hector,
> For humans, computers or both?
>   

I was thinking computers, but really this is small potatos.  For one,
you have to do the signature verification and this is going to be the
CPU intensive component of the operation.  And as we've heard from
implementors, most people are disk or network bound anyway.

Eliot

---

From: Douglas Otis <[email-masked]>
Date: Wed, 26 Apr 2006 10:18:46 -0700

On Apr 26, 2006, at 9:25 AM, Eliot Lear wrote:

> Doug,
>> I know many don't like being so 1970ish, but to conserve DNS  
>> payload space, here is one example.  Introducing this change when  
>> going to the binary key seems like a good choice.
>
> While in principle I agree with you - in fact I was looking at ways  
> to compress other components of the record, I think we have to be  
> careful not to go too far down the line - the real boundary is 512  
> bytes.  That gets us easily to key sizes of 2048 and probably 3072  
> if desired.  4096 is just not an option without either going to TCP  
> or EDNS0, no matter the key size.  My point is I think this might  
> be a bit of over-optimizing.  I would be more interested in making  
> the record easier to parse, but even here I'm not too concerned.

It seems a shame to waste 5 bytes that offer no information.  The  
down side is such a change in the label may mean delegating two zones  
when transitioning to the binary key.  The immediate concern is key  
sizes of 2048 bits where every byte still matters.  It will be hard  
to predict how quickly the 576 byte MTU with the 512 byte DNS message  
constraint is overcome, as this constraint is assumed in many network  
products.  A desire to permit a diversity of applications access to  
this information will likely make these RRs perhaps the last able to  
overcome message size constraints.

Another area to conserve space is use of a binary algorithm number as  
normally used, rather than expressing algorithms as a text string.   
The use of text strings will be problematic when also expressed as a  
binary value in a key.  Without an ability to verify the algorithm  
the sender supports, a spoofed algorithm exploit becomes possible at  
each algorithm transition.  While a few bytes may not seem like much,  
there is little to spare.  Text strings for the algorithm are wasted  
bytes in every message, where it also becomes cumulative with respect  
to storage.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 26 Apr 2006 14:34:14 -0400

----- Original Message -----
From: "Eliot Lear" <[email-masked]>
To: "Hector Santos" <[email-masked]>

> implementors, most people are disk or network bound anyway.

I asked because flexibility, including human readability, even at the
expense of extra bytes seems to be a popular desire.  I'm going thru this
issue right now for a proposal I'm writing. A few offlist reviewers
preferred an expanded human literal form which, although very readable, it
also tripled its size.  :-)

---
Hector

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 26 Apr 2006 12:43:26 -0400

----- Original Message ----- 

>> payload space, here is one example.  Introducing this change 
>> when going to the binary key seems like a good choice.

> I would be more interested in making the record easier

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 26 Apr 2006 15:28:21 -0400

----- Original Message -----
From: "Michael Thomas" <[email-masked]>
To: "Hector Santos" <[email-masked]>

> Hector Santos wrote:
>
>> The document refers to both _domainkey vs. _dkim subdomains to
>> DNS DKIM records:
>>
>> How is this going to be handled?  Most testing domains are
>> using _domainkey or is _dkim targeted for a binary RR?

> This is just a typo. A.3 should be _domainkey as well.

I figured as much and this is probably a good idea to clean that up.

Does this related any way  to section 3.6.2.2 and a normative reference to a
future document?

| 3.6.2.2  Resource Record Types for Key Storage
|
|    [[This section needs to be fleshed out.  ACTUALLY:  will be addressed
|    in another document.]]
|
|    Two RR types are used:  DKK and TXT.
|
|    The DKK RR is expected to be a non-text, binary representation
|    intended to allow the largest possible keys to be represented and
|    transmitted in a UDP DNS packet.  Details of this RR are described in
|    [ID-DKIM-RR].
|
|   TXT records are encoded as described in Section 3.6.1.
|
|  Verifiers SHOULD search for a DKK RR first, if possible, followed by
|  a TXT RR.  If the verifier is unable to search for a DKK RR or a DKK
|  RR is not found, the verifier MUST search for a TXT RR.

| 9.1  Normative References
|
|    [ID-DKIM-RR]
|               "DKIM Key Resource Records (To be written)",
|               draft-dkim-dkk-rr-xx (work in progress), 2005.

I could be wrong, but I thought the "plan" was to use _domainkey to offer
some level of backward capability with Yahoo's Domainkey TXT lookup, and
when an official RR type number for DKIM is assigned called DKK and we can
then switch to subdomain _dkim for DKIM binary RR lookups. At which point,
the semantics of section 3.6.2.2 kicks in.

   DKK RR Lookup  <selector>._dkim.<domain>
   if fail:
      TXT RR Lookup  <selector>._domainkey.<domain>

I'm fine either way.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 26 Apr 2006 13:18:53 -0700

>to parse, but even here I'm not too concerned.
There's a couple of downsides here. First is if you are delegating the 
_domainkey
subdomain, you'd now need to delegate another subdomain as well. Ie, an
administrative hassle. Second is just remembering: do we really want to have
to remember this prefix vs. that prefix vs. another when we're doing 
host -t's?
I'd rather not.

       Mike

---

From: Mark Delany <[email-masked]>
Date: Wed, 26 Apr 2006 20:49:34 +0000

[ re _dkim vs _domainkey ]

Also worth considering is the s= option. If s=voip, would the address space be _dkvoip, etc?

Mark.

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 26 Apr 2006 12:52:52 -0700 (PDT)

On Wed, 26 Apr 2006, Hector Santos wrote:

> I could be wrong, but I thought the "plan" was to use _domainkey to 
> offer some level of backward capability with Yahoo's Domainkey TXT 
> lookup, and when an official RR type number for DKIM is assigned called 
> DKK and we can then switch to subdomain _dkim for DKIM binary RR 
> lookups. At which point, the semantics of section 3.6.2.2 kicks in.
>

That would be a better way for the future.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Jim Fenton <[email-masked]>
Date: Wed, 26 Apr 2006 16:41:05 -0700

> Also worth considering is the s= option. If s=voip, would the address space be _dkvoip, etc?
Why, because the voip group might want to administer their keys
separately from the mail group?  I suppose they might.
They could achieve this by using a dotted selector (e.g., delegate
voip._domainkey.example.com to the voice group, and then use selectors
like apr2006.voip).  That seems preferable to defining a new prefix for
each new service.  Of course, the voice and mail folks need to trust
each other since the voip folks could publish an email signing key and
vice versa.  Let's hope there isn't that degree of infighting within a
domain!

-Jim

---

From: Mark Delany <[email-masked]>
Date: Thu, 27 Apr 2006 02:51:19 +0000

> Why, because the voip group might want to administer their keys

I was obviously being too obtuse. My point was that _domainkey is
generic whereas _dkim is not. If people want to go down the
non-generic path then it follows that for each service there should be
a separate namespace (which would obviate the need for s= btw).

My point being that a separate namespace for each service is likely to
not scale well or admin well. Additionally it precludes the (easy) use
of the same key across services.

In short, I think _dkim is a bad idea even if it does save a whopping
5 bytes of query space.

Mark.