On Mon, 2005-04-04 at 19:20 -0700, Jim Fenton wrote:
Sam Hartman wrote:
I was thinking that for a per-domain key--a key allowed to sign any
local part--the signature itself could indicate whether the local part
was in fact checked.
I tend to be suspicious of any positive assertion by the signer on their
own behalf, regardless of whether it is part of the key or part of the
signature.
Why would you be less trusting of an assertion made in the key header
within DNS? Any assertions within the message that attempts to increase
assurances would be suspect of course, which I think Sam was suggesting.
I'm also not sure how this indication would be used. Would the
verifier or recipient do anything different depending on whether or
not the local part was said to have been checked?
This issue can be avoided by not distributing private keys to untrusted
entities. The concept that binding the local-part to a key, provides
sufficient protection (for permitting the distribution of private keys
to untrusted entities), is wrong.
On the other hand, would it dilute the accountability of the signer to
allow it not to say it checked the local part? I would rather that the
signer do whatever diligence it needs to do to sign the message without
such a caveat.
From a reputation standpoint, the local-part is of no concern. The
mailbox address seen by the user may be independent of the signature
domain as well. When the signing domain becomes lax about private keys,
or wants to publish millions of keys for a domain, there should be some
type of negative warning. This negative warning would be intended to
discourage such practice. Binding a key to the local-part provides an
increased assurance, which is in the positive (and wrong) direction.
This issue can be resolved by removing the 'g=' mechanism within the
key. Of course many assertions can be added in an attempt to defend
this lax and expensive practice. Ultimately, DomainKeys would be better
without this added baggage. S/MIME provides for per-user keys and is
already accommodated. This enters into key dispersal issues that still
have not been fully resolved. Why have DomainKeys tackle this issue and
add complexity to the MUA? I would rather see efforts directed toward
ensuring port 587 SMTP authentication is used instead, see RFC2476.
With current law within the US, this is really the only choice for
corporations anyway.
http://weblog.infoworld.com/udell/2004/03/23.html
There are some suggestions for phishing within the draft:
http://www.kelkea.com/ietf/draft-otis-mass-reputation-01.html
http://www.ietf.org/internet-drafts/draft-otis-mass-reputation-01.txt
10. Domain Assertions for Signatures
[ID-CSV] provides a means to make domain-wide assertions. Currently,
only the use of CSV itself is defined. The Port field of the CSV-CSA
record defined in [ID-CSVCSA] can be extended to make signature
related assertions. These assertions could be used to prevent
[RFC2822] FROM from being spoofed.
+--------------+----------------------------------------------------+
| Bit Value | Meaning |
+--------------+----------------------------------------------------+
| 1 | Explicit: All authorized names have specific |
| | CSV-CSA records. |
| 2 | All Messages Signed. |
| 4 | All Messages Signed by HELO domain. |
| 8 | FROM Signed by HELO domain. |
| - | Other bit values are reserved for expansion and |
| | must be set to zero. This range of values should |
| | be ignored by the recipient when their function is |
| | unknown. |
+--------------+----------------------------------------------------+
Asserting that "all messages signed" allows other domain signatures
to be used, but makes an assurance that all messages sent by the MTA
will be signed. Asserting all "messages signed by HELO domain" makes
an assurance all messages sent by this MTA can be identified by a
parent domain signature. The "FROM Signed by HELO domain" assertion
indicates that [RFC2822] FROM headers with a mailbox-domain being a
parent of the HELO domain must be signed by the parent domain or
should be refused. This mechanism provides a means to prevent
phishing and should be selectively used by only those experiencing
the phishing problem. This assertion may cause messages that have
been been altered, or re-signed by other domains, to be refused.
-Doug