Subject: [ietf-dkim] draft-ietf-dkim-threats-02 nit//Permitted and preferred algorithms.

From: Douglas Otis <[email-masked]>
Date: Thu, 6 Apr 2006 12:03:00 -0700

,---
| 4.1.14.  Cryptographic Weaknesses in Signature Generation
|
| The message signature system must be designed to support multiple
| signature and hash algorithms, and the signing domain must be able to
| specify which algorithms it uses to sign messages.  The choice of
| algorithms must be published in key records, rather than in the
| signature itself, to ensure that an attacker is not able to create
| signatures using algorithms weaker than the domain wishes to permit.
'___

This leaves out the "bid-down" concern.

Change to:

: The message signature system must be designed to support multiple
: signature and hash algorithms, and the signing domain must be able to
: specify which algorithms it uses to sign messages.  The choice of
: algorithms as well as the preferred algorithm offered when multiple
: signatures are added to a message must be published in key records,
: rather than in the just the signature itself, to ensure that an
: attacker is not able to create signatures using algorithms weaker than
: the domain prefers or wishes to permit.

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 06 Apr 2006 20:13:52 +0100

Doug,

We're done with that document. We had the WG last call.
Its finished. Unless something REALLY BIG turns up, but
that's always true.

*If* the document editor wants to make innocuous changes
during AUTH-48, that'd be ok. I'll leave it to Jim to
figure if this is one such or not. These are not IMO
REALLY BIG issues.

For the rest of us - let's get on to discussing the base
draft (unless someone wants to be left behind haggling
over threats wordsmithing:-)

Regards,
Stephen.

PS: Same response to the mails sent to ietf-discuss!

---

From: Douglas Otis <[email-masked]>
Date: Mon, 10 Apr 2006 12:39:21 -0700

The results of the Dallas meeting and sections of the threat draft  
with new material where not reviewed on the list.  Some edits were  
not expected, and the draft publication as an I-D was not available  
prior to the close of the last call.  This precluded review by the  
list.  Nevertheless, here are some comments.

Section 4.3.1 suggests that DKIM will _only_ contribute indirectly to  
packet amplification and that other strategies specific to DNS must  
be employed instead.  When advocating an unlimited number of  
signatures, DKIM's contribution to this problem is not indirect.  Had  
this section been open for review, it would have been prudent to list  
direct contributions created by DKIM, such as use of wildcard key  
records, walking label trees for policies, or provisions for  
unlimited signatures.  While a brief conversation occurred on the  
list, it would be difficult to deduce this section was the outcome.

With respect to some of these nits, the desire is not to change the  
meaning of the draft.  The phrase "Affects the verification of  
messages" for rating a threat impact is not well defined.  There  
should be a clearer term, if not classification.  Signature  
verification is not affected by a private key being compromised.   
Signature verification offers no indications related to the message  
being part of a replay abuse campaign or being signed by a stolen  
private key.  What metric is being measured to assess the threat  
impact?  "Verification" does not elucidate what is being affected and  
measured.

At the meeting, I acknowledged acceptance of the term responsible  
instead of accountable, but asked if this was a reference to the  
message and heard yes.  The first statement in the DKIM threat draft  
indicates DKIM is for the signer to claim responsibility for the use  
of some email-address.  While DKIM may provide a mechanism to claim  
some verification was made in the use of an email-address, the  
signature provides a far more basic function of indicating the domain  
handling the message.  There is no reason people must forgo use of  
their email-addresses when it is not directly associated with their  
provider who adopts DKIM.

,---
|1.1.  Terminology and Model
|...
| The origin address is the address on an email message, typically the
| RFC 2822 From:  address, which is associated with the alleged author
| of the message and is displayed by the recipient's MUA as the source
| of the message.
'---

This definition appears to be a statement of desire and not a  
definition.  The MUA is likely to exclude the display of the email- 
address and favor the display-name.  More than one email-address  
could be associated with the From header field.  There are no  
conventions how the source of a message is communicated.  This  
terminology, in conjunction with the first sentence of the  
introduction, expresses desire rather than definitions useful for  
assessing threats or ascribing basic roles.  DKIM should not require  
a provider add some email-address in a header to claim control of the  
email-address.  The DKIM signature indicates who handled the message  
which provides value in and of itself.  How that information is used  
is independent of the appearance of an email-address in some header.   
Few provider's who employ DKIM would be wanting to claim they are  
responsible for the email-address appearing in the From header, nor  
would they wish to add an inappropriate Sender or Resent-From header.

Change to:

: The origin address is the address on an email message, typically one
: of the RFC 2822 From:  address, which is associated with an alleged
: author of the message.  This address may be displayed by the
: recipient's MUA.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Apr 2006 22:40:13 +0100

Doug,

I'm not clear if you're saying that these comments are on parts of
the document that changed between -01 and -02, or on parts that
remained the same.

If the former, then it is fair to bring them up, *iff* your comment
is to the effect that the change doesn't match the resolution of
some specific (i.e. referenced) last call issue(s).

If the latter, then sorry, we've had last call. Everyone got their
chance to raise issues. Other cases are treated the same, unless
compelling.

Its too late here for me to check tonight, but I will tomorrow,
unless someone else on the list does that for me in the meantime
(he hinted:-)

Goodnight,
Stephen.

Douglas Otis wrote:
> 
> 
> The results of the Dallas meeting and sections of the threat draft with 
> new material where not reviewed on the list.  Some edits were not 
> expected, and the draft publication as an I-D was not available prior to 
> the close of the last call.  This precluded review by the list.  
> Nevertheless, here are some comments.
> 
> packet amplification and that other strategies specific to DNS must be 
> employed instead.  When advocating an unlimited number of signatures, 
> DKIM's contribution to this problem is not indirect.  Had this section 
> been open for review, it would have been prudent to list direct 
> contributions created by DKIM, such as use of wildcard key records, 
> walking label trees for policies, or provisions for unlimited 
> signatures.  While a brief conversation occurred on the list, it would 
> be difficult to deduce this section was the outcome.
> 
> meaning of the draft.  The phrase "Affects the verification of messages" 
> for rating a threat impact is not well defined.  There should be a 
> clearer term, if not classification.  Signature verification is not 
> affected by a private key being compromised.  Signature verification 
> offers no indications related to the message being part of a replay 
> abuse campaign or being signed by a stolen private key.  What metric is 
> being measured to assess the threat impact?  "Verification" does not 
> elucidate what is being affected and measured.
> 
> instead of accountable, but asked if this was a reference to the message 
> and heard yes.  The first statement in the DKIM threat draft indicates 
> DKIM is for the signer to claim responsibility for the use of some 
> email-address.  While DKIM may provide a mechanism to claim some 
> verification was made in the use of an email-address, the signature 
> provides a far more basic function of indicating the domain handling the 
> message.  There is no reason people must forgo use of their 
> email-addresses when it is not directly associated with their provider 
> who adopts DKIM.
> 
> ,---
> definition.  The MUA is likely to exclude the display of the 
> email-address and favor the display-name.  More than one email-address 
> terminology, in conjunction with the first sentence of the introduction, 
> expresses desire rather than definitions useful for assessing threats or 
> ascribing basic roles.  DKIM should not require a provider add some 
> email-address in a header to claim control of the email-address.  The 
> DKIM signature indicates who handled the message which provides value in 
> and of itself.  How that information is used is independent of the 
> appearance of an email-address in some header.  Few provider's who 
> employ DKIM would be wanting to claim they are responsible for the 
> email-address appearing in the From header, nor would they wish to add 
> an inappropriate Sender or Resent-From header.
> 
> Change to:
> 
> NOTE WELL: This list operates according 
> tohttp://mipassoc.org/dkim/ietf-list-rules.html
>

---

From: Douglas Otis <[email-masked]>
Date: Mon, 10 Apr 2006 15:55:53 -0700

> unless someone else on the list does that for me in the meantime

http://www.sonic.net/~dougotis/dkim/ietf-dkim-threat-02-diff.html

In the prior message, I recalled the wrong version of the threat  
draft.  Sorry for the inaccurate statement regarding the extent of  
the changes in two sections regarding network amplification and the  
cryptographic weaknesses.  The other suggestions do not attempt to  
change the meaning of the draft, but were intended to improve  
clarity.  The existing text appears to be technically in error, where  
corrections should be helpful for future work.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Apr 2006 21:12:43 +0100

Doug,

> http://www.sonic.net/~dougotis/dkim/ietf-dkim-threat-02-diff.html

Thanks for that. Always takes me ages to find that tool for
some reason :-(

> In the prior message, I recalled the wrong version of the threat draft.  
> Sorry for the inaccurate statement regarding the extent of the changes 
> in two sections regarding network amplification and the cryptographic 
> weaknesses.  The other suggestions do not attempt to change the meaning 
> of the draft, but were intended to improve clarity.  The existing text 
> appears to be technically in error, where corrections should be helpful 
> for future work.

Ok, so this is therefore wordsmithing in which case I guess its best
to make no change now. But if (say in response to IESG comments), we do
re-work the document, perhaps you can make your suggestions again.
I'd guess there's a fair likelihood of that, and I assume that if
this is important enough for you, you'll remember to bring it back
to the WG's attention at that point.

Cheers,
Stephen.