Hi Dave,
Responses inline. Generally you should assume I'm ok with not
making the suggested changes, so if something is a potential
rathole we can just drop it and I'll be fine with that.
Dave Crocker wrote:
#1 Abstract
Suggest deleting "...and key server technology." DKIM doesn't really
define
any new key server technology, so that's a bit misleading.
What is the previous example of serving keys via the DNS? If none, then
what makes using DNS not 'new'?
Its a new use of DNS (I guess DNSSEC certs would be a similar
existing use), but the reason I suggested changing is that the
text gave me the impression that to use DKIM you need to deploy
some new key store thing, and I can imagine some people only
reading the abstract might also get that impression.
#2 Abstract
Suggest changing:
"This permits verification of a message source, an intermediary, or
one of
their agents, as well as the integrity of its contents. "
to:
"This permits stonger authentication of a message's source, (or
intermediary or
other signing agent), as well as providing the ability to check data
integrity
for message headers and content."
Stronger than what?
I guess stronger than is provided today, based on e.g. the connection
information, but you're right that the word "stronger" could be dropped
from the suggested change.
Where are the weaker ones cited? And why is it
necessary or helpful to cast this as a comparative rather than a
description of a standalone capability?
The main reason for the suggestion is that I thought that "verification
of the message source" wasn't quite accurate.
#3 Abstract
Suggest changing:
"Such protection of email identity can assist in the global control of
"spam"
and "phishing".
to:
"DKIM's authentication of email identity can assist in the global control
of "spam" and "phishing."
So the important change is from 'protection' to 'authentication'? While
I think I can see some meaningful distinction here, can you elaborate on
what problem you see with the exising wording?
I guess protection implies more to me, e.g. related to reputation, or
stopping someone from grabbing a domain when a registration expires,
so I thought authentication was more accurate.
#6 Section 1.1, 1st para:
The first part of the 1st sentence seems like a tautology - who else
could
create signatures other then someone who handles the message?
Having an association with Goodmail has been education, since it has
taught me that the world of 'third party' signatures can get pretty
interesting.
They don't handle the message, yet they sign it.
Good point. (Now that you mention it, I do recall some EDI
signing schemes where the signer only ever saw a digest).
What does the "it" refer to in: "It can also be created by an
independent
service that is providing assistance to a handler of the message." I
don't
understand the sentence basically. I'd also suggest deleting the
following two
sentences.
The reference is to the signature.
Ok. Maybe worth s/It/The signature/
And does my citing Goodmail explain
the nature of what the text is trying to refer to?
Yep.
That'd mean changing:
" DKIM signatures can be created by a direct handler of a message,
either as
its author or as an intermediary. It can also be created by an
independent
service that is providing assistance to a handler of the message.
Whoever does
the signing chooses the domain name to be used as the basis for later
assessments. Hence, the reputation associated with that domain name
is an
additional basis for evaluating whether to trust the message for
delivery. The
owner of the domain name being used for a DKIM signature is declaring
that they
accept responsibility for the message and may thus be held accountable
for it."
to:
" DKIM signatures can be created by any handler of a message, either its
author or an intermediary. In a typical use of DKIM, the owner of the
domain
name being used for a DKIM signature is declaring that they accept
responsibility for the message and may thus be held accountable for it."
I hope that the Goodmail example explains why your suggested text is
overly restrictive.
Sure.
#8 Section 1.1, bullet list, 1st bullet:
Suggest changing:
"Does not offer any assertions about the behaviors of the identity
doing the signing."
to:
"Does not offer any assertions about the behaviors of the signer."
That's a very attractive simplification, but as I think about it, I
think that, again, it is overly restrictive. To wit: An oursourced
sending service signs with the domain name of the content authoring
organization. The signer is not the one whose reputation is used for
making assessments.
In this scenario, I believe your proposed text would be inaccurate.
Fair enough. How about "Does not offer any assertions about the
behaviours of identity on whose behalf the message was signed, nor
of the signer (if they differ)." ?
#9 Section 1.1, bullet list, last bullet
If the "To:" field (and others) were included in the signature
then some forms of replay could be detected. Maybe too hard to
explain here, so change the example to say that the same message
could be resent to the same recipients? (That's a "purer" replay
anyway since the message bytes don't change at all.)
Not sure I understand how that would protect against replay.
I didn't mean to propose anything about replay protection. I just
thought the example given (with a modification, i.e. new
recipients) was a bit more complex than needed - simply resending
the message unmodified to the original recipients is a replay
against which DKIM alone provides nothing. But the current text
is ok as well (maybe even better than mine now that I look at
it again), so scratch this comment.
#12 Section 1.2, 3rd last para:
Change:
"That said, DKIM uses security algorithm
components that have a long history, including use within some of
those other messaging security services."
to:
"That said, DKIM only uses cryptographic mechanisms
that have a long history, including use within some of
those other messaging security services."
Ok. And while I suspect that I see how the change improves the meaning,
I'd like to be a bit more educated about it. Would you explain what is
the important difference in the language?
Its not very important, but the place that things often go wrong
when people are designing protocols that use crypto is when they
invent new crypto mechanisms (e.g. a new key exchange scheme or
some such) and I thought the suggested change made it clearer that
we didn't do that.
#13 Section 1.2, 2nd last para:
s/Public Key Infrastructure (PKI)/public key management scheme/
When PKI got introduced into the text, it also gave me pause. By I
thought the use of it was valid. Can you clarify your concern,
preference, etc.?
(I see that Wikipedia says that a Cert Authority is required, for use of
the term PKI, and DKIM most certainly does not have one of those.)
Right. Some people would read "PKI" as meaning that a CA (or TTP that
does some crypto stuff) is needed. For me, the "I" in PKI does imply
that there's something in the infrastructure that knows its doing
public key stuff.
Let me know if I missed any I should have responded to,
Cheers,
Stephen.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html