ietf-dkim
[Top] [All Lists]

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

2006-03-20 21:59:14
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.
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
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>