Subject: [ietf-dkim] ISSUE: dkim-overview -- normative statements

From: Dave Crocker <[email-masked]>
Date: Sat, 14 Jul 2007 14:55:17 -0400

Folks,

The overview document states that it is seeking Informational RFC status. 
Further, it does not include the usual citation and statement that normative 
vocabulary is used to assert normative requirements.

Nonetheless, the document has quite a number of apparently normative 
statements -- including some in uppercase -- such as:

> 2.2.  Email Infrastructure Agents
> 
>    It is expected that the most common venue for a DKIM implementation
>    will be within the infrastructure of an organization's email service,
>    such as a department or a boundary MTA.
...
>       Outbound:   An MSA or Outbound MTA should allow for the automatic
>          verification of the MTA configuration such that the MTA can
...
>          An outbound MTA should be aware that users may employ MUAs that
>          add their own signatures and be prepared to take steps
...
>       Intermediaries:   An email intermediary is both an inbound and
>          outbound MTA.  Each of the requirements outlined in the
>          sections relating to MTAs apply.  If the intermediary modifies
>          a message in a way that breaks the signature, the intermediary
> 
>          +  SHOULD deploy abuse filtering measures on the inbound mail,
>             and
> 
>          +  MAY remove all signatures that will be broken

and

> 2.5.3.3.  Boundary Enforcement
> 
>    In order for an assessment module to trust the information it
>    receives about verification (e.g., Authentication-Results headers),
>    it MUST eliminate verification information originating from outside
>    the ADMD in which the assessment mechanism operates.  As a matter of

This seems anomalous and raises a line of questions:

    If the apparently normative statements are actually trying to be normative 
and are reasonable, has the intent of the document changed?

    Even though I've written some portion of the language in the document, I 
have mixed feelings about this issue.  Some of the apparently-normative 
statements I like and some I don't -- and I don't know which ones I wrote, so 
that's not the issue.

    Beyond being a summary of DKIM, the document also has become something of 
a  higher-level "system specification".  As such, some of the normative 
language really pertains to the higher-level integration of DKIM into an 
operational email service and well could be extremely useful for guiding 
design, implementation and deployment of DKIM.  I think that's a good thing, 
but I think we need to resolve whether this document is making architectural, 
normative specification or whether it is providing tutorial exemplars.

Unfortunately I don't think this can be resolved by a simple assertion of an 
underlying principle.

I think we need to look at the actual language in the document and decide what 
is important for the current work.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 14 Jul 2007 13:01:34 -0700

Many thanks to Dave for bringing this up.

At 2:55 PM -0400 7/14/07, Dave Crocker wrote:
>The overview document states that it is seeking Informational RFC 
>status. Further, it does not include the usual citation and 
>statement that normative vocabulary is used to assert normative 
>requirements.
>
>. . .
>    If the apparently normative statements are actually trying to be 
>normative and are reasonable, has the intent of the document changed?
>
>    Even though I've written some portion of the language in the 
>document, I have mixed feelings about this issue.  Some of the 
>apparently-normative statements I like and some I don't -- and I 
>don't know which ones I wrote, so that's not the issue.
>
>    Beyond being a summary of DKIM, the document also has become 
>something of a  higher-level "system specification".  As such, some 
>of the normative language really pertains to the higher-level 
>integration of DKIM into an operational email service and well could 
>be extremely useful for guiding design, implementation and 
>deployment of DKIM.  I think that's a good thing, but I think we 
>need to resolve whether this document is making architectural, 

I think it would be fine to make this a standards-track document with 
normative language.

--Paul Hoffman, Director
--Domain Assurance Council
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Eliot Lear <[email-masked]>
Date: Sat, 14 Jul 2007 23:41:21 +0200

An overview is not the place for normative statements.  Can we discuss 
this in person in Chicago?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Sat, 14 Jul 2007 18:23:31 -0400

> this in person in Chicago?

Eliot, et al,

I think your response highlights the dilemma:  There is the title (and the 
original intent) and there is (possibly) a different reality to the current 
content.  On the theory that the current content is, in fact, useful, 
something needs to be reconciled.

That's why I noted that the content has moved more towards an integrated 
system-level (or service-level) description of DKIM.

Take a look over the document for the various must/should/may language and 
note that much of it seems like reasonable directives to folks seeking to 
integrate a DKIM service component into their email software and operations.

That might well qualify as a service specification, along the lines that the 
IETF frequently publishes as standards-track.

d/

-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Sat, 14 Jul 2007 22:42:19 -0700

Dave Crocker wrote:
> status. Further, it does not include the usual citation and statement 
> that normative vocabulary is used to assert normative requirements.

I'd say that this is a poor idea as it becomes rather unclear who is 
authoritative
>>          +  MAY remove all signatures that will be broken

and RFC4871 which sez:

   Signers SHOULD NOT remove any DKIM-Signature header fields from
   messages they are signing, even if they know that the signatures
   cannot be verified.

I really don't see why we should be setting ourselves
up for this kind of conflict. 

To my mind, this document has been ever chomping at the
bit to be a BCP. I'm all in favor of a BCP, but only when
we really know those B's, C's, and P's are. Inserting 
new normative language about how one should use DKIM beyond
what's in 4871 seems rather premature to me.

		Mike

> apparently-normative statements I like and some I don't -- and I don't 
> know which ones I wrote, so that's not the issue.
>
> something of a  higher-level "system specification".  As such, some of 
> the normative language really pertains to the higher-level integration 
> of DKIM into an operational email service and well could be extremely 
> useful for guiding design, implementation and deployment of DKIM.  I 
> think that's a good thing, but I think we need to resolve whether this 
> document is making architectural, normative specification or whether 
> it is providing tutorial exemplars.
>
> Unfortunately I don't think this can be resolved by a simple assertion 
> of an underlying principle.
>
> I think we need to look at the actual language in the document and 
> decide what is important for the current work.
>
> d/
>

---

From: Eliot Lear <[email-masked]>
Date: Sun, 15 Jul 2007 09:53:32 +0200

Dave,

I agree with Mike Thomas.

As a general rule I believe you are better off with fewer documents with 
normative text than more. There is a lot of text around mailing lists 
that comes dangerously close to text in the SSP draft (see -overview 
Section 2.5, and -ssp, Section 5.1).  The last thing we want are two 
documents that mandate behavior in the same components in what could end 
up being subtly different ways.

It may be useful to have a BCP or an overview, but the scope of that 
document must be made clear, and should not overlap with standards 
specifications.  The use of normative language in the draft today is 
IMHO inappropriate even for a BCP, and in some cases is overly broad.  
Here are two examples:

    * In section 2.1 you talk about memory models and keeping private
      keys private.  I think that states the obvious, while at the same
      time going way down the implementation path.  If you're going to
      state the obvious, do so once and not at only some of numerous
      opportunities for a key to be exposed.  Furthermore, this text
      goes into implementation design.  That's not BCP territory, IMHO.
    * In Section 2.2 you talk about requiring secure zone updates
      without really defining what you mean.  Are you, for instance,
      talking about DNS registrars needing to use SSL?  Is a login
      password good enough or is that not strong enough?  Is DDNS useful
      in this context?  If so, how?  If not why not?  (I'd argue the
      latter, but there's no argument in there at all right now.)

Given these issues, how would you want to proceed?

Finally, because it's clear that a fair amount more work is needed on 
this document, and as SSP is progressing, I think it would be prudent to 
be mindful of SSP, and to reconsider gating this document to SSP, 
assuming we keep moving forward on the latter.

Eliot

---

From: <[email-masked]>
Date: Sun, 15 Jul 2007 11:50:01 -0400

Its not a conflict, the document in question states an intermediate MTA MAY remove broken sigs. The RFC states "Signers SHOULD NOT remove any DKIM-Signature header" an intermediate MTA may or may not be a signer, its not the issue being addressed
thanks,
Bill

-----Original Message-----
From: [email-masked] on behalf of Michael Thomas
Sent: Sun 7/15/2007 1:42 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [ietf-dkim] ISSUE:  dkim-overview -- normative statements

and RFC4871 which sez:

		Mike

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 16 Jul 2007 11:03:28 +0100

On Sat, 14 Jul 2007 21:01:34 +0100, Paul Hoffman  
<[email-masked]> wrote:

>> document is making architectural, normative specification or whether it  
>> is providing tutorial exemplars.
>>
>

I disagree. The purpose of an "Overview" is to give an informal summary of  
the effect, and especially the reasoning and motivation for, a collection  
of standards. So it may well outline what the standards do, and indicate  
the sort of normative provisions they would make (which can include  
indication of whether such provisions are MUST/SHOULD/MAY).

But it should include somewhere wording such as:

      "This document provides an overview of the DKIM collection of related  
standards, indicating how they are intended to work together to produce  
[list of desirable effects]. But this document is not normative itself;  
{RFCxxx], [RFCyyy] and [RFCzzz] should be consulted for the detailed  
normative requirements."

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Mon, 16 Jul 2007 09:46:39 -0700

On Jul 16, 2007, at 3:03 AM, Charles Lindsey wrote:

>> I think it would be fine to make this a standards-track document  
>> with normative language.
>
> I disagree. The purpose of an "Overview" is to give an informal  
> summary of the effect, and especially the reasoning and motivation  
> for, a collection of standards. So it may well outline what the  
> standards do, and indicate the sort of normative provisions they  
> would make (which can include indication of whether such provisions  
> are MUST/SHOULD/MAY).
>
>      "This document provides an overview of the DKIM collection of  
> related standards, indicating how they are intended to work  
> together to produce [list of desirable effects]. But this document  
> is not normative itself; {RFCxxx], [RFCyyy] and [RFCzzz] should be  
> consulted for the detailed normative requirements."

An overview should not be normative.  Agreed.

At some point, corrections to RFCs describing the protocol might be  
required, or a BCP document to explain desired methods to address  
various issues might be appropriate, but much later.  This overview  
has not been reviewed from a perspective of noting whether it creates  
new or conflicting normative requirements.  Expectations were just  
the opposite.

As a side note, would it be possible to reference the TPA-SSP instead  
of the DOSP draft in the working drafts section on the DKIM website?   
TPA-SSP will be easier to understand.  You should have the XML and  
HTML versions of this draft.

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Mon, 23 Jul 2007 09:59:20 -0500

Eliot,

Eliot Lear wrote:
> normative text than more.

As a general rule, I believe the number of documents should strike a useful
balance between flexibility for later enhancement and ease of cross-reference 
while reading the specification.  These are competing constraints, since the 
former argues for more documents and the latter argues for fewer.  We have 
seen problems with too few documents and others with too many.  Both problems 
tend to be serious in the long run.

Again, this is why I suggested that this thread worry a bit less about generic
rules -- bu note that "a bit less" does not mean "not at all" -- than about 
the particulars of the current situation.

For example:

1. -base and -ssp exist.  So does -overview.  What we do not officially have
is a document that describes the integrated service.  -base and -ssp do not
seek that role, so this is hardly an matter of their being "deficient".

2.  -overview has evolved.  As you and Jim Fenton have done so diligently, 
other folk should take a careful look at it and describe what areas of 
discussion it has that they believe should be eliminated or moved elsewhere. 
(If the latter, then where? If they think it should be eliminated, then why?)

3.  -overview must not be redundant with any other normative text.  Every time 
we've had two normative documents make normative statements about the same 
thing, we've hadlong-term problems.  So I suspect no one will argue with this. 
  Where the current -overview draft does appear to be redundant, the text 
should either be eliminated or modified to sound purely pedagogical, possibly 
with a reference to the proper, external normative text. Such redundancies are 
not uncommon when developing tutorial material, since that's sort of its 
purpose.  The problem, in these cases, is with the nature of the language, not 
the topic.

 >    There is a lot of text around mailing lists
> Section 2.5, and -ssp, Section 5.1). 

Auditing, to catch possible discrepancies and redundancies, is extremely helpful.

>  The last thing we want are two

Completely agree.

> IMHO inappropriate even for a BCP, and in some cases is overly broad.  

In Section 1.1, par 3, the opening sentence is:

    "This document provides a description of DKIM's architecture, 
functionality, deployment and use. "

    That's rather terse, but I'm not understanding what additional statements 
you would like to see.  Is there more than a clear disclaimer that any 
statements that appear to conflict with DKIM specification documents are 
resolved by taking the normative portions of the specification documents as 
definitive?

>       latter, but there's no argument in there at all right now.)

Well, your friendly authors certainly had some discussion about the scope of 
this section.  My sense of the motivation for the section is that security 
coding and operations issues are not well-ingrained in the industry and that, 
therefore, some basic tutorial about generic issues, would be helpful.  (This, 
of course, does not mean that the current text there -- or anywhere else in 
the document -- would not benefit from revision.)

> assuming we keep moving forward on the latter.

The industry needs -overview today.  Not tomorrow.

Some of us attended a Federal Trade Commission anti-spam workshop where we 
heard a senior FTC staffer state that the only way he could familiarize 
himself with DKIM was to read -base.  This is such an unreasonable demand to 
place on him that it's not his fault that he viewed DKIM as too complicated 
and risky...

d/
-- 

   Dave Crocker