On Fri, 2005-11-04 at 10:20 +0000, Stephen Farrell wrote: > Doug, > > Douglas Otis wrote: > > Once DKIM considers how to handle cases where the signing-domain and > > email-address domains are frequently different, then opportunistic > > techniques like those found in SSH look better than some complex array > > of DNS records. In the odd case where a domain is being phished, an > > assertion carried within the signed message can indicate the required > > bindings based upon a class of keys. These captured requirements would > > then block all cases where the requisite bindings where not found. > > So you want us to define a "deny service to everyone > else from this domain who doesn't have this key" field > which is included in a header, and then also have an > ssh like mode of operation where anyone (who can mess > with the headers) can introduce new keys? No thanks. > Not without it being a lot more worked out and > demonstrated-safe. > > It is a wonderfully dangerous idea though but I think > I'd prefer doing it at a lower layer, maybe using > RFC 3514? :-) > > SSH works in part because there's a human in the loop > when it matters. Such a situation doesn't arise here.
The reference to SSH was to indicate that an opportunistic approach could be used in a similar fashion. Where the signing-domain and email- address domain are different, then spoofing related protections would require the recipient to review and approve the details of the disparate identifiers. The inference to a class of keys was considering the problem that not all keys are equally trusted, where the scope of a binding would not be applicable across all key classes. For example, a key may be classed as "delegated" when beyond the intimate control of the domain. This could affect (narrow) the binding scope of identifiers that would apply for this domain's class of delegated keys. A concept lacking in SSP and DKIM. See: 9. Binding Identifiers http://www.sonic.net/~dougotis/id/draft-otis-mass-03.html#anchor9 The effect of a binding assertion could be the same as a policy statement that the signing-domain and the email-address domain must match (broad binding). It would not be a specific-key, but a class of key where there may be separate "policies" established. As shown, for delegated keys, the binding scope would be asserted within the key itself. SSP is worthless at providing spoofing protection in the majority of cases. However, the opportunistic approach could extend spoofing protection universally. Only in those cases where an institution stipulates that they constrain the email-address to the individual, and that they sign all of their messages with the same domain, would an automated assertion be possible. There would be no risk of tampering. These broad binding assertions within matching signing-domain and email- address domain could be gleaned on-the-fly. This would entail far far less overhead when compared to the SSP discovery process of walking up label-trees for each and every email-address. :-P -Doug _______________________________________________ ietf-dkim mailing list http://dkim.org
