Wietse, Wietse Venema wrote: > Jim Fenton: > >> The aspect of user-level SSP that concerns me equally is the transaction >> load. When user-level SSP is "turned on", the verifier MUST query for a >> user-level record in addition to the domain-level record. User-level >> queries are not as effectively cached, since these are queries for >> individual addresses, not domains. >> > > Could someone please explain the nature of the problem that would > exist when these (financial) institutions can't selectively add > DKIM signatures to outbound email? Engineering is about balance, > but I haven't heard enough to make the trade off yet. > If a domain wants to selectively add signatures, it needs to publish SSP that says "unknown: we may sign some or all email" (or not publish SSP at all, since this is the default). The interesting case here is when there are particular addresses for which they can state that all messages are signed, and want to publish a different SSP for those addresses. Another case is when a particular address, say [EMAIL PROTECTED], is used only for transactional mail and they want to publish SSP that tells the verifier to tell the verifier to expect a valid first-party signature from that address. > With per-user records in the DNS, should we not be worried about > brute-force attacks to guess email addresses? > Yes, although the use of hashing on the local-part as suggested by Doug Otis would tend to make this a dictionary attack, rather than capture of a username from a DNS cache, etc. In some use cases, I think, the local-part for addresses that have user-level SSP records will tend to be well-known, e.g. 'statements' in the example above. It's not necessary to publish user-level SSP records for every address in the domain. > I'm also worried about the implied requirement that a DKIM verifier > would have to do SSP lookups even when a valid first-hand DKIM > signature exists. > I don't see that implied requirement, any more than it is a requirement for domain-level SSP. Can you elaborate?
-Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
