Subject: [ietf-dkim] New Issue: various overview editorial suggestions

From: Stephen Farrell <[email-masked]>
Date: Wed, 26 Mar 2008 17:43:21 +0000

I'm still not done with this, but since I'm already late
its probably worth sending these suggested changes out
now. Feel free to ignore or take 'em & sorry if they
overlap with recent list discussions.

And of course, these are just my comments as a vanilla
participant, not as chair or shepherd (that's Barry this
time btw).

I'll try get the rest of this reviewed in the next day
or two, so more apologies (this time in advance:-) for
those even later comments.

Stephen.

#1 Abstract

Suggest deleting "...and key server technology." DKIM doesn't really define
any new key server technology, so that's a bit misleading.

#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."

#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."

#4 Section 1, 2nd para: see #1 & #3 above.

#5 Section 1, 3rd para: While its correct that this doesn't try describe
much about how DKIM fits into more general anti-spam efforts, it'd be good
to provide a reference here to some such description. (I don't have one
to hand sorry.)

#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? 
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.

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."

#7 Section 1.1, 3rd para:

Suggest chaning:

"DKIM's capabilities have a narrow scope." 

to:

"DKIM has a narrow scope."

#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."

#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.)

#10 Section 1.2, 1st para: 

s/an identity that used the//
s/the message content/existing message content/
s/via underlying Internet information mechanisms/via the network/
s/therefore/often/
s/viewed as often/often viewed as/

#11 Section 1.2, 2nd para:

s/four previous IETF efforts at standardizing/four previous IETF efforts 
that standaradized/

#12 Section 1.2, bullet list. Isn't PGP a trademark? Suggest deleting
or acking (or whatever's right, I dunno).

#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."

#13 Section 1.2, 2nd last para:

s/Public Key Infrastructure (PKI)/public key management scheme/

s/relying on the key having a broader semantic implication
of the assertion, such as a quality assessment of the key's owner/
having the validity of the key attested to by a trusted third party/

#14 Secction 1.2, last para

s/DKIM's PKI/DKIM public key distribution/
s/the technical aspect of the//

#15 Section 2, 1st para:

2nd sentence reads oddly, maybe:

s/ Such misrepresentations may (but not necessarily) be employed in order to
perpetrate abuse/Such misrepresentations may be employed for legitimate reasons
or for nefarious reasons./

#16 Section 2, bullets:

s/Determine a verified identity, if possible/ Determine a verified identity as
taking responsibility for the message, if possible/
s/Determine whether a known identity is trusted/ Determine whether, and if so,
for what,  a known identity is trusted/

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Siegel, Ellen" <[email-masked]>
Date: Wed, 26 Mar 2008 15:08:21 -0400

The list of editorial comments is getting really long, and it's hard to
track which ones are getting accepted into the document. I hope there
will be a chance to review the document once all the various suggestions
are incorporated before it is considered final. 

One particular instance, in reference to Stephen's comment #6 on Section
1.1, 1st paragraph, I disagree with the proposed amendment (see below). 

I could go along with removing the single sentence "It can also be
created by an independent service that is providing assistance to a
handler of the message.", but I do not agree with the additional
editing. 

Signing by the author domain is certainly one example of signature, but
far from the only one and even "typical" may be a stretch. And I think
it's important to call out the fact that the domain used for signing may
be independent from that of the author or even that of the signer, since
it may be delegated. The whole point of DKIM is that it allows any
entity to take responsibility for the message, and I think it's
important to retain the text that makes that clear. 

In reference to Stephen's comment #2 on the Abstract, I'm not clear why
making an intermediary or agent parenthetical is beneficial. The point
is that it enables stronger authentication of the signer, and the text
in question is just enumerating the possible signing entities.  

Ellen

		The first part of the 1st sentence seems like a
tautology - who else could
		create signatures other then someone who handles the
message? 
		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.

		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."

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Stephen Farrell
> Sent: Wednesday, March 26, 2008 1:43 PM
> To: ietf-dkim
> Subject: [ietf-dkim] New Issue: various overview editorial suggestions
> 
>

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Mar 2008 13:36:19 -0700

> 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'?

> for message headers and content."

Stronger than what?  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?

> 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?

> to provide a reference here to some such description. (I don't have one

In theory it would certainly be helpful.  In practice, I suspect our challenge 
is to find a citation that is not, itself, controversial.  I don't have one either.

> 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.

> understand the sentence basically.  I'd also suggest deleting the following two

The reference is to the signature.  And does my citing Goodmail explain the 
nature of what the text is trying to refer to?

> 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.

> "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.

> anyway since the message bytes don't change at all.)

Not sure I understand how that would protect against replay.

> or acking (or whatever's right, I dunno).

oops.  Good catch.  Callas is careful to remind us to use OpenPGP, precisely for 
that reason.

>    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?

> 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.)

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 27 Mar 2008 17:28:01 +0000

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:
> 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.

> 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.

> 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.

> Having an association with Goodmail has been education, since it has 
> taught me that the world of 'third party' signatures can get pretty 
> interesting.
> 

Good point. (Now that you mention it, I do recall some EDI
signing schemes where the signer only ever saw a digest).

> 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.

> I hope that the Goodmail example explains why your suggested text is 
> overly restrictive.

Sure.

> 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.
> 

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)." ?

> 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.

> 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.

> 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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 27 Mar 2008 18:46:16 +0000

Hi Ellen,

> are incorporated before it is considered final.

Yes, I guess there'll be a -10 before we can ship it to the AD and
I'm sure the authors will want folks to take a look at that before
we do the write-up (which doesn't tend to happen in nanoseconds
anyway;-). After that there's the time until the draft gets on top
of the AD's in-tray and then more, so I wouldn't worry overmuch about
not having time to check changes.

> 1.1, 1st paragraph, I disagree with the proposed amendment (see below).

The exchange I had with Dave showed that my suggested text wasn't
as good anyway, so I'd guess this will end up ok from your p-o-v.

> handler of the message.", but I do not agree with the additional editing.
> 

I tried to answer Dave on that too. Let me know if I didn't cover
this in that response.

Cheers,
S.