Subject: [ietf-dkim] Jamming stuff in the selector record

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 20 Mar 2006 14:33:05 -0800 (PST)

I'm a little concerned about the trend of sticking more and more stuff in 
the selector (key) record.  Today at the IETF we talked about both "r=" 
and the "we sign with these hashes" stuff in selector records.

The argument in favour of this is that the "r=" in there shields a spam 
target via obscurity, and the "hashes" stuff there keeps us from having to 
do two queries to get that information.

It seems to me though that this creates a problem of keeping that data 
up-to-date at sites where there are large numbers of selectors in use. 
Perhaps in the "r=" case and probably in the "hashes" case, these are 
really originator/signer policy issues, and not things that are specific 
to a particular key or selector.

This could just be my software developer side talking, under which I 
generally think copying a value into "n" (for large "n") places in code is 
simply a no-no, but it also seems that domain policy issues are out of 
scope for selector records.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Mon, 20 Mar 2006 19:13:05 -0600

On Mar 20, 2006, at 4:33 PM, Murray S. Kucherawy wrote:

> I'm a little concerned about the trend of sticking more and more  
> stuff in the selector (key) record.  Today at the IETF we talked  
> about both "r=" and the "we sign with these hashes" stuff in  
> selector records.
>
> The argument in favour of this is that the "r=" in there shields a  
> spam target via obscurity, and the "hashes" stuff there keeps us  
> from having to do two queries to get that information.
>
> It seems to me though that this creates a problem of keeping that  
> data up-to-date at sites where there are large numbers of selectors  
> in use. Perhaps in the "r=" case and probably in the "hashes" case,  
> these are really originator/signer policy issues, and not things  
> that are specific to a particular key or selector.
>
> This could just be my software developer side talking, under which  
> I generally think copying a value into "n" (for large "n") places  
> in code is simply a no-no, but it also seems that domain policy  
> issues are out of scope for selector records.

In the dkim-options draft, there are two other issues associated with  
the key.  Creating a key tag holding a domain for locating a means to  
confirm the continued validity of a signature conveyed policy, for  
example, could also locate a reporting vector as well.  This could  
allow aggregation of multiple keys under a common set of parameters.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Mon, 20 Mar 2006 20:50:21 -0800

Murray S. Kucherawy wrote:
> I'm a little concerned about the trend of sticking more and more stuff
> in the selector (key) record.  Today at the IETF we talked about both
> "r=" and the "we sign with these hashes" stuff in selector records.
>
> spam target via obscurity, and the "hashes" stuff there keeps us from
> having to do two queries to get that information.
>
> really originator/signer policy issues, and not things that are
> specific to a particular key or selector.
>
> generally think copying a value into "n" (for large "n") places in
> code is simply a no-no, but it also seems that domain policy issues
> are out of scope for selector records.
I agree with you regarding the obscurity of the "r=" value.  Typically
there will be a lot of messages floating around from which selector
names can be harvested (from certain mailing list archives, for
example); depending on confidentiality of selector names is a losing battle.

However, the key record has the useful property that it is under the
control of the domain administrator, and not the signer (since they can
be different when keys are delegated).  Things that affect the validity
of the signature like the hash algorithm(s) that are used in connection
with a given key are appropriate for the key record.  This prevents a
delegate from using a weaker algorithm than is intended by the domain.

-Jim

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 21 Mar 2006 09:38:27 -0800 (PST)

> example); depending on confidentiality of selector names is a losing 

For comparison: Do people actually get spam based on, for example, the 
contact address published in SOA records at the top of a DNS zone?  I've 
never heard of such a thing.

> delegate from using a weaker algorithm than is intended by the domain.

For a domain that has only a few selectors in use, sure.  But suppose 
someone starts using keys on a per-user basis (or any other method that 
requires a huge number of signing keys), then changes the hash 
requirements.  Any large organization could then have an enormous number 
of records to update.  It sure would be nice to be able to change it in 
just one place, like a signing policy.

It might well be the case that we just need to include this in the 
specification to indicate we've thought about it, and explain why we 
chose whatever location ends up holding it.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John Levine" <[email-masked]>
Date: 22 Mar 2006 04:47:06 -0000

>never heard of such a thing.

No, but they definitely get spam at anything that looks like an address
that can be scraped out of a web archive.

>just one place, like a signing policy.

Any organization that creates an enormous number of records and doesn't
have automated ways to manage and update them has worse problems than
we can solve.

Key management strikes me as another item that would be appropriate
for a BCP rather than in the DKIM spec.

R's,
John