J D Falk wrote: > Jeff Macdonald wrote: > > >> I'm a bit behind on this but: >> >> On Thu, Nov 29, 2007 at 03:43:55PM -0500, J D Falk wrote: >> >>> I agree, that would be extremely helpful -- but DKIM's i= won't give >>> > it > >>> to us. (Unless you're assuming that these same botnet operators will >>> allow themselves to be corralled into a single identifer, which >>> > clearly > >>> isn't the case.) >>> >> this thinking needs to be applied to d= too. And once you do that, >> then the logical conclusion (well, to me :)) is that d= isn't any >> better as an identifier. >> > > A bad guy buying another domain name is a threat we already have to deal > with today. It's not a high barrier, but it is a barrier. > > The same bad guy having an infinite number of entirely distinct i= > identities at each of those domains would be a new threat, equal to > forging the From: header -- and the obvious conclusion will be to ignore > i= and instead concentrate on d= (along with other reputation inputs.) >
The bad guy can still create subdomains and publish keys there: Create a key under foo._domainkey.sub.example.com and they can sign with s=foo; d=sub.example.com. In other words, using d= doesn't get away from being able to create a whole bunch of entirely different identifiers. Creating key records is really cheap. This is part of the reason that I consider d= to be just the location where the key is stored, and nothing more than that. > But since this is about reputation, it's out of scope. > Sure enough. -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
