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

[Stephen Farrell]

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.