On Mar 28, 2006, at 5:38 AM, DKIM Chair wrote:
Doug Otis presented his proposal about opaque IDs and signing
roles. There was only a little discussion because time was tight.
There were comments that this would require a lot of DNS querying,
and that it might be more interesting theoretically than practically.
There was also a method to group keys. Not every source within a
domain is equally vetted. A method to group keys using some
convention to indicate properly vetted sources would allow safer
third-party annotations, and reduce costs related to establishing
reputations when focused upon the vetted subset. This approach does
not expect the recipient to be able to recognize the email-address
and yet allows trustworthy annotations.
There was also a method to associate domains. This could be the EHLO
with the signing-domain, or the From email-address with the signing-
domain. Conventions using PTR RRsets offer a strategy to
differentiate handling of potentially replayed messages, or messages
signed by invalid domains. This listing strategy would allow phished
domains to indicate only their domain should sign their messages.
When a domain wishes to allow a dozen of specific third-party
signatures, annotations of trust can still indicate whether the From
domain was within the signing-domain, and should also be affected by
key grouping tags. This provides far greater security than simply
indicating third-party signatures are allowed and then expecting
recipients to have their own white-lists.
I don't recall hearing a comment about this scheme creating excessive
DNS queries, but as you suggested, there was no time. The opaque-
identifier is an option that could be used _instead_ of per-user
keys. The impact upon the DNS infrastructure when per-user keys are
needed would be far greater. As opaque-identifiers ease reporting
and provide for opportunistic security, a means to indicate whether
revocation is published could be possible. If replay abuse becomes
problematic, there must be another option available instead of per-
user keys. Key revocation is slowed by TTL values, and when used for
many different users, disrupts valid emails. Short TTLs and per-user
keys would be highly detrimental to DNS.
Opaque-identifier revocation can be mitigated by an association of
the EHLO domain with the signing-domain. Even without EHLO
mitigation, negative caching and small record size of a opaque-
identifier compares extremely favorably to per-user keys. This
option could be added as a separate draft to that of the base
document. It would be highly beneficial to consider how a key
grouping convention could be included in the base draft however. A
tag within the key, the right-most label of the key selector are
possible solutions. There are other schemes possible as well that
would not disrupt backward compatibility.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html