On Sun, 2005-04-03 at 21:07 -0400, Sam Hartman wrote:
"Douglas" == Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> writes:
Brief summary: we disagree a lot.
Douglas> This mechanism is the only means to make the validation
Douglas> of the local-part explicit. It may not be reasonable, if
Douglas> this causes a proliferation of user-keys beyond normal
Douglas> capacity.
That's unclear to me. I'm not sure whether current domainkey
semantics say that the local part is validated. If they do not,
allowing a policy attribute to be attached to a signature saying that
the local part is validated seems sufficient to address your concern.
To establish local-part assurances, a local-part validated assertion
within the key would provide an alternative to binding the local-part
with the key. This would address one aspect of my concerns.
I disagree that it is desirable to discourage the use of per-keys. I
disagree that it is acceptable for per-user keys not to validate a
local part and will block any IETF document that attempts to do so.
The 'g=<local-part>' key mechanism is simply poor practice, from the
perspective of publishing local-part addresses, and inappropriate DNS
use. Distributing private-keys to a population of untrusted users, with
often questionable security, represents a sizeable deployment barrier
that DomainKeys can overcome by NOT allowing.
DNS concerns are not just a matter of RR-record counts. These key
records are also large and, to allow a means to revoke these records
within a short period, will also require short TTLs, and may increase by
the number of users per domain when allowing this local-part binding
mode. DomainKeys does not prevent the use of a mailbox-domain,
especially when delegated keys. The SENDER header is typically not seen
by the user, and this header allows any mailbox address to be used in
the FROM header.
DomainKeys still has great value. With respect to abating abuse,
DomainKeys offers significant relief by accurately identifying the
accountable domain. This removes the need for white-listing, for one
example. From an acceptance or abuse abatement perspective, the
local-part offers much less utility. A key that indicates the
local-part has been validated may invite greater reliance upon this
portion of the mailbox address, when communicated to the recipient.
However, this assurance should not be done by binding the local-part to
a key.
Financial institutions will log all outbound emails to meet
Sarbanes-Oxley requirements, especially for signed email. Current MUA
programs offer a means to securely send email over specialized ports,
and many corporations require VPNs for remote employees. Such currently
available alternatives mitigate the need for the distribution of
specialized signing MUA programs and private keys, that per-user keys
will require. This mode should NOT be part of the DomainKeys solution.
Examples for 'g=<local-part>' has been for role addresses. A recipient
would not be alarmed by a SENDER mailbox-domain being within a
sub-domain, nor would this be noticed by typical users. Utilization of
this 'g=' local-part mechanism does not provide protections for the FROM
mailbox-domain either. By indicating within the key there is no
local-part validation, this could further warn recipients, as will use
of a sub-domain and/or SENDER header. Promotional material sent by
untrusted entities would then obtain a separate reputation, when
relegated to a sub-domain. This would be especially true for a key that
warns of a lack of local-part validation.
When it becomes the norm to use this 'g=' mechanism to send mail from
untrusted entities, will it take long for this to become a reason for
refusing these messages? Will end-users really want the local-part of
their mail-box address published? While scaling is improved by dropping
this mode, little is really lost.
I disagree that it is acceptable to force sites to move addresses into
subdomains to make a signature scheme work or to support a site's
policy.
Signatures are already within different sub-domains, referenced by a
selector. The SENDER header isolates users from any domain requirement,
in that user mailbox addresses need not be affected. There are existing
solutions for users to sign their own email. Creating an expansive
reliance upon DNS, by expecting DomainKeys to offer per-user keys, may
have a dangerous impact upon DNS. May I encourage a study in this
regard?
-Doug