[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Charles
Lindsey
But DKIM-base is not 100% suitable. You wouldn't want a
header called "DKIM-Signed" for an application totally
unconnected with DKIM,
Why not? The M stands for Messaging.
NNTP is simply an alternative transport for email.
and you would not want the signing key
to be based on a domain-name (a newsgroup-name such as
news.announce.newgroups is traditional) and so you wouldn't
be using DNS to publicize your keys.
I disagree. I think that you want to authenticate the signer. In fact that is
all you can do with any signature technology.
The question of the relationship of the signer to the newsgroup is separate.
You seem to be considering the case where the signer is the newsgroup
moderator. I was considering a situation where the news server signs every post
that originates from one of its own users. In the second case the natural way
to deal with the situation would be to use the DNS name of the news server.
For the newsgroup moderator case I would again use DNS for actual key
distribution since it allows a separation of the NNTP control channel and the
maintenance of the public keys.
The other reason I am here is because of concerns over EAI.
The MUST sign From is problematical there, as is the
expectation that the CTE on the wire will have to be Base64
or Q-P for DKIM-base to work, which is exactly what EAI is
trying to put behind us.
I am familiar with six acronyms for EAI. I presume you mean
internationalization.
My understanding of DKIM is that we are running with the expectation that the
channel is clean rather than assuming that it is not. NNTP is a much closer
approximation to this than SMTP.
Sure they won't. But that makes their addresses highly
visible spam magnets (you should see the 100:1 spam:signal
ratio that control(_at_)usenet(_dot_)org(_dot_)uk gets). But ordinary Usenet
users, who are the ones Phil thought might use DKIM, find
life much quieter if they don't use their genuine email
addresses in From:.
That is true but I would expect the signature to be of the server, not the
sender. What is being attested to here is the ability of the server to kick out
crap and take responsibility for doing that to the rest of USENET.
So for example, imagine that Manchester, UMIST and Salford Poly all decide to
set up a local hierarchy MANCH for collaboration between just the three
institutes. A condition of posting to these groups being that they must be
signed by the server responsible for them.
Now imagine that the UMIST classical studies department makes a mistake, their
news server config is left open. Spam floods into the private MANCH groups.
This is easy to deal with, simply drop messages from them until they get their
act together. Authentication enables accountability.
Now imagine that news of these spam free newsgroups spreads to Liverpool,
Newcastle, etc. etc. Pretty soon your perimeter security strategy is toast. You
have so many servers authorized to post to the MANCH hierarchy that it is easy
for a malefactor to bribe an admin into gating spam into the system. But this
does not do them much good because the location of the breach is quickly
identified and the breach closed.
You will of course need to establish a channel to exchange the reputation data
and there is quite a bit of engineering required there but you can reclaim a
portion of USENET in a very short time.
If you call the hierarchy dkim the entry qualification will be clear.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html