Would it make sense to break these up into separate threads? Anyway, here
is my comments on some of these issues.
----- Original Message -----
From: "DKIM Chair" <leiba(_at_)watson(_dot_)ibm(_dot_)com>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
* Issue: "r=" tag, specifying a "report-to" entity. Defer consideration
to SSP document, but then we considered whether to also have it in the
key record (or something reachable through the selector). Further
discussion to go to the mailing list.
Personally, I like the idea of having a possible (by default) fixed
notification common name (user part), such as one of following names:
DKIM-ABUSE (My preference, since ABUSE is already required)
DKIM-POSTMASTER
DKIM-ADMIN
DKIM-SYSOP
etc.
Dave Crocker's RFC 2142 can serve as a guide.
Just a small note about operation consideration: The r= report address must
be legitimate and acceptable. If a DKIM verifier attempts to send a report,
it can learn very quickly if it is just a fraudulent address. So if not
acceptable, it can become a source for putting more weight on a bad message.
Some guidance should be provided for possible actions to take, i.e, stop
sending future reports.
* Issue: transition plan for new crypto algorithms, and specifically,
transition from SHA-1 to SHA-256 hashes. Some discussion here, but
discussion ultimately deferred to the general issue of multiple
signatures. Consensus among the security folks is to let the verifier
decide which crypto is "best".
I like the idea or the potential to offer high-value domains the ability to
secure their operations by doing one or more of the following:
1) Assign domain owned user addresses for communications,
2) Joint venture, collaborate, outsource with a ESP that
has the DKIM security we are looking for, and assign the
user a special ESP domain controlled address.
3) During the user account sign-up we will automatically find
out if the target domain offers the security we are looking
for.
In my view, the idea that high-value domains will place their faith on
signing messages and then "cross their fingers" that it will be correctly be
supported seems me to be a little unrealistic. This touches base with the
following:
Jim Fenton introduced the signing policy/practices proposal and issues;
after the base document, we'll be attacking this in earnest. The name
is still in flux, with some thinking that "policy" is not the right
term, others thinking that "practices" isn't either. We were pointed to
some work called DDDS that's been introduced in the speermint working
group, which might help us with the work (not with the naming), so
we'll have a look at that.
Practice?
I would hope that everyone practices a safe DKIM Sender Signing Policy! :-)
Labeling it as a "Sender Signing Practice" doesn't sound right.
hmmmm, maybe it is obvious by now, but it should be highlighted that there
seems to be two camps here in regards to SSP:
- Those who think SSP is not necessary
- Those who think SSP is vital to DKIM
I think it is required. The specs has a natural presumption of a SSP
Neutral policy (Missing SSP key defaults to NEUTRAL, o=~, policy). This is
very important. Even if a domain doesn't define a SSP key, he is telling the
world he is NEUTRAL. He doesn't care what happens to the message.
What I seek operationally, is that everyone follows SSP
verification/authorization whether one defines SSP record or not. The
protection in DKIM comes when every piece of software is expected to
practice SAFE SSP. So that if a DOMAIN says:
"We don't send mail"
"We never sign mail"
"No 3rd party SHOULD ever sign our messages"
etc, etc, it is vitally important that the domain policy, definition,
"practice" or requirement, whatever we wish to call it, that we honor that
security. I don't understand why we would want to ignore this fundamental
domain security?
So whatever we want to call it, to me, it a small moot point over what how
we expect to use it. If it isn't require to be honored than what's the
point?
That said, I think ideas like DDDS and similar concepts is a step in the
right direction. SSP will offer ways to resolve so many issues of
"expectation" in a highly chaotic world of mail transactions. So whether
its DDDS, SSP or what I call TMS (Transaction Management System), domains
can learn more about who they are sending data to, as well as domains can
learn about those they are receiving mail from.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html