Subject: [ietf-dkim] Output summary

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 27 Apr 2011 12:28:32 -0700

Trust me, this is (supposed to be) minor!

Someone off-list pointed out to me that it might be helpful to summarize the expected outputs of a DKIM verifier.  Indeed, on review, we don't do that all in one place; some of it is in Section 3 and some in Section 7.

With that in mind, I propose this as a new Section 4.9, moving the others down:

4.9.  Output Requirements

The output of the verifier MUST embody:

-          A result code that indicates whether or not the signature was validated (PERMFAIL or TEMPFAIL as described in Section 7.1, or a success result code)

-          If the signature did validate, the value of the "d=" tag, i.e., the signing domain

The verifier MAY include other outputs, but this is implementation-dependent and not mandatory.  The verifier MAY also include as secondary data some information indicating the specific cause of a failure.

Comments?

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

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 27 Apr 2011 12:42:24 -0700

On 4/27/2011 12:28 PM, Murray S. Kucherawy wrote:
> -A result code that indicates whether or not the signature was validated
> (PERMFAIL or TEMPFAIL as described in Section 7.1, or a success result code)
>
> -If the signature did validate, the value of the “d=” tag, i.e., the signing domain
>
> The verifier MAY include other outputs, but this is implementation-dependent and
> not mandatory. The verifier MAY also include as secondary data some information
> indicating the specific cause of a failure.

This creates a formal protocol specification semantic in the part of the 
document dedicated to that sort of thing.

Although that's entirely too reasonable a basis for the choice, I'll give it a

+1

I note that there is similar text in the current Section 3.9 -- which will 
become 3.10 -- concerning SDID/AUID:

>    Hence, DKIM's mandatory output to a receive-side Identity Assessor is
>    a single domain name.  Within the scope of its use as DKIM output,
>    the name has only basic domain name semantics; any possible owner-
>    specific semantics are outside the scope of DKIM.  That is, within
>    its role as a DKIM identifier, additional semantics cannot be assumed
>    by an Identity Assessor.

I suggest deleting the first sentence and moving the remainder tot he new 3.9.

d/
-- 

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 27 Apr 2011 12:46:33 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
> Sent: Wednesday, April 27, 2011 12:42 PM
> To: [email-masked]
> Subject: Re: [ietf-dkim] Output summary
> 
> > 4.9. Output Requirements
> >

Correction: "For each signature on the message that was not ignored by the verifier, the output..."

> I suggest deleting the first sentence and moving the remainder tot he

WFM.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 27 Apr 2011 12:58:04 -0700

>>> The output of the verifier MUST embody:

sorry for not noticing this earlier:  what does it mean for a verifier to 
'embody' something.

i can guess, given the history of discssion but offhand i think it entirely to 
literary (or English) a word usage, in a spec that doesn't create bodies...

d/

-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 27 Apr 2011 13:09:05 -0700

> From: Dave CROCKER [mailto:[email-masked]]
> Sent: Wednesday, April 27, 2011 12:58 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]

As in "must be this, or something equivalent to it".

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 27 Apr 2011 13:11:18 -0700

> As in "must be this, or something equivalent to it".

    MUST include:

or

    MUST contain at least:

?

d/

-- 

   Dave Crocker

---

From: "John Levine" <[email-masked]>
Date: 27 Apr 2011 21:10:11 -0000

>The output of the verifier MUST embody:

embody --> include (if it embodied them, that arguably implies that it doesn't
  include anything else)

>-          A result code that indicates whether or not the signature was validated (PERMFAIL or TEMPFAIL as
>described in Section 7.1, or a success result code)
>
>The verifier MAY include other outputs, but this is implementation-dependent and not mandatory.  The verifier
>MAY also include as secondary data some information indicating the specific cause of a failure.

Do we need to say anything about the possibility that there are multiple
signatures?

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 27 Apr 2011 14:11:26 -0700

> From: John Levine [mailto:[email-masked]]
> Sent: Wednesday, April 27, 2011 2:10 PM
> Cc: Murray S. Kucherawy

How about "For each signature not ignored by the verifier" or such.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 27 Apr 2011 14:20:46 -0700

> How about "For each signature not ignored by the verifier" or such.

Unfortunately, moving the text is this direction for this item requires going 
back over the rest of the protocol spec to make sure it deals with multiple 
signatures consistently.

I think it simpler and safer to have the core spec deal with a single signature 
-- a single DKIM-Signature field -- and then add the section on multiple sigs to 
say that the basic mechanism can interate over multiple sig fields.

"the verifier" therefore would refer only to the handler of a single sig.

d/
-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Wed, 27 Apr 2011 17:22:38 -0400

> The verifier MAY include other outputs, but this is implementation-dependent and not mandatory.  The verifier MAY also include as secondary data some information indicating the specific cause of a…

Once again we are limiting DKIM Mail Integration designs.  This is 
more than minor.  Its keeps with the presumption Failure Detection is 
not going to be considered regardless of what the DKIM-BASE documents 
continues to try to mandate or hide. If people don't believe in it, it 
won't be followed. If they find it lacking, they will compensate.

Just consider the two items in your proposed 4.9 are in conflict; the 
1st item considers failure, the 2nd item says don't consider failure. 
  The 2nd item is not going to hold across the board with verifiers; 
SDID can be returned. Its not like SDID will be returned as a NULL or 
blank string for failed signatures.

IMO, to be completely DKIM Mail Integration ready, this new proposed 
section SHOULD also include policy-related or AUID output semantics as 
well, but since thats a hot iron, so.......

I think the Identity Assessor section is sufficient.

If you are in the mood to add such a section, I propose to cover the 
I/O and called it:

4.9 DKIM Mail Integration I/O

   (summary itemization)

   Minimum INPUT for Signing

     - RFC5322 compliant message
     - SDID signer domain for d=
     - SELECTOR s=
     - PVTKEY (Private Key)

     Process model

       RFC4871  DKIMSIGNER(RFC5322,SDID,SELECTOR, PVTKEY)

   Minimum INPUT for Verification

     - RFC4871 DKIM Signed compliant message
     ? PUBKEY (Public Key)

     Process model

      RESULT DKIMVERIFY(RFC4871 [, PUBKEY?])

      ? = the function has all the info from RFC4871 namespace
          to obtain public key.

   Where RESULT is the minimum output namespace:

     - RCODE  (Verification Result Code)
     - AUID
     - SDID

     Assessment Modules

      TRUST  DKIMTRUST(RCODE, SDID)
      POLICY DKIMADSP(RCODE, AUID, SDID)

   Where TRUST is the output from Trust Assessment
         POLICY is the output from Policy Assessment

Its a little closer to what we have now implementations and where 
things are headed. But if you want to take out the POLICY semantics, 
well, I can understand.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: "John R. Levine" <[email-masked]>
Date: 27 Apr 2011 17:27:13 -0400

> How about "For each signature not ignored by the verifier" or such.

Section 5.3 says:

    Verifiers SHOULD ignore failed signatures as though they were not
    present in the message.

and Section 7 says:

    In the following description, text reading "return status
    (explanation)" (where "status" is one of "PERMFAIL" or "TEMPFAIL")
    means that the verifier MUST immediately cease processing that
    signature.  The verifier SHOULD proceed to the next signature, if any
    is present, and completely ignore the bad signature.  If the status
    is "PERMFAIL", the signature failed and should not be reconsidered.
    If the status is "TEMPFAIL", the signature could not be verified at
    this time but may be tried again later.  A verifier MAY either defer
    the message for later processing, perhaps by queueing it locally or
    issuing a 451/4.7.5 SMTP reply, or try another signature; if no good
    signature is found and any of the signatures resulted in a TEMPFAIL
    status, the verifier MAY save the message for later processing.  The
    "(explanation)" is not normative text; it is provided solely for
    clarification.

If you believe that, the output should only include signatures that 
verified, right?  So you aren't suppsed to report TEMPFAIL or PERMFAIL. 
Except that if it TEMPFAILed, the output can optionally include a queued 
copy of the message and part of a of SMTP transaction.

I fear the worms are escaping.  Maybe it should say that the output 
includes the signatures that validated.  If nothing validated, it might 
include a hint that the caller might get a better answer later.  And we 
should fix Section 7, since you can't even assume that the validator is 
running anywhere near an SMTP session.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 27 Apr 2011 14:39:05 -0700

> From: John R. Levine [mailto:[email-masked]]
> Sent: Wednesday, April 27, 2011 2:27 PM
> To: Murray S. Kucherawy
> Subject: RE: [ietf-dkim] Output summary
> 

There are two layers of output: Output of the algorithm, and output of some API that performs it.  I think I was talking about the former, but I realize the section could be read as the latter.

A truly minimal API output might just be the list of domains for which there was a valid signature, and that set might be empty.

As for TEMPFAIL, you'd have to know which signature(s) were temp-failed in order to decide about a later retry, which then leans us back toward giving the whole list of signatures that were present and a status for each.

---

From: "John R. Levine" <[email-masked]>
Date: 27 Apr 2011 18:33:02 -0400

> As for TEMPFAIL, you'd have to know which signature(s) were temp-failed in order to decide about a later retry, which then leans us back toward giving the whole list of signatures that were present…

I wouldn't be opposed to doing so, except that 4871 says in two separate 
places not to do that.  Section 7 is, now that I look at it, really badly 
written, since it implies that a "verifier" is an SMTP server.

We probably have reasonably good agreement about what a verifier should 
do:

a) If at least one signature verifies, report success with the d= value(s)
of the valid signature(s) and optionally other stuff.

b) If nothing verified and nothing tempfailed, report no signatures.

c) If nothing verified and something tempfailed, return a hint to try 
again later.

d) If at least one signature verified and at least one tempfailed, uh, 
flip a coin and either report success or a try again hint.

Unfortunately, that's not really what the existing language says.

Regards,

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 28 Apr 2011 00:48:29 +0200

> As for TEMPFAIL, you'd have to know which signature(s) were temp-failed in order to decide about a later retry, which then leans us back toward giving the whole list of signatures that were present…

IMO section 7.2 in its current form allow such ambiguities between 
output of algorithm and output of API, as the paragraph introduces the 
term 'other parts of the mail system'. I suggest to use the same 
terminology here as in par. 3.2:

"Verifiers wishing to communicate the results of verification to a 
consuming agent..."

And for a consuming agent I think the bare minimum set of possible 
statuses which MUST be communicated by the verifier contains just 
SUCCESS and FAILED. A verifier MAY choose to add more information about 
failure (tempfail and other statuses), but is not required to do so.

/rolf

---

From: Hector Santos <[email-masked]>
Date: Wed, 27 Apr 2011 23:24:55 -0400

Murray S. Kucherawy wrote:
> There are two layers of output: Output of the algorithm, and output 
> of some API that performs it.  I think I was talking about the 
> former, but I realize the section could be read as the latter.

+1

> A truly minimal API output might just be the list of domains for 
> which there was a valid signature, and that set might be empty.

+1, "A DKIM Complete API...."

> As for TEMPFAIL, you'd have to know which signature(s) were 
> temp-failed in order to decide about a later retry, which then 
> leans us back toward giving the whole list of signatures that 
> were present and a status for each.

Murray,

How do you reconcile section 7.2 Communicate Verification Results with 
this new section for verifiers?

I think this proposed Output Summary new section may fit better under 
section 7.2. After all that is what we are trying to do - 
communicating or reporting verification results. Since A-R is now 
considered to be added as a possible header to sign, we are further 
reinforcing the DKIM Mail Integration with A-R.

I am just throwing this out there (mod as necessary) to 7.2

                 ------------------

  7.2.  Communicate Verification Results

  To make DKIM verification output useful, there are mandatory outputs
  that MUST be made available to consumers of DKIM results.

  Verifiers may report results in whatever manner they see fit but
  the recommended reporting method is using the Authentication-Results
  [RFC5451] header.

    INFORMATIVE ADVICE to MUA filter writers: Patterns intended to
    search for results header fields to visibly mark authenticated
    mail for end users should verify that such header field was added
    by the appropriate verifying domain and that the verified identity
    matches the author identity that will be displayed by the MUA.  In
    particular, MUA filters should not be influenced by bogus results
    header fields added by attackers.  To circumvent this attack,
    verifiers may wish to delete existing results header fields after
    verification and before adding a new header field.

  All verifications MUST produce status code output indicating whether
  or not the signature was validated (PERMFAIL or TEMPFAIL as described
  n Section 7.1)

  Reporting SHOULD by done for each signature until the first valid
  signature is found.  Reporting invalid signatures is out of scope.
  but MAY be reported using Authentication-Results headers.

  For trust assessment reporting, the mandatory SDID (d=) value is
  required for the signer assessment for valid signatures only.
  Trust reporting MUST not be done for invalid signatures.

  Additional reporting can be done using additional DKIM output
  values including non-DKIM related values.  One consideration for
  the values to report would be values that are bound to the signature
  such as:

     - identity (i=)
     - selector (s=)
     - AUID (From: domain)

                 ------------------

My overall concernr with the proposed section 4.9 is that will 
handicap implementation following the strict DKIM interpretation. 
When they finally see there are added-value protocols like A-R, they 
will need to change they code again.

Case in point, the ALT-N API.  Its verifier output structure was 
insufficient to supply the values for the A-R reporting.   I did not 
want to duplicate a RFC5322 streaming parser since the verifier 
already did that.  So the output structure was changed, the function 
modified to set the values.   This allowed me to start generating the 
A-R record, for example:

  Authentication-Results: dkim.winserver.com;
    dkim=pass header.i=mipassoc.org header.d=mipassoc.org header.s=k00001;
    adsp=none author.d=cloudmark.com signer.d=mipassoc.org;

Refresh readers need the insight to determine what are all the 
"useful" values to report.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 27 Apr 2011 23:56:50 -0400

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of John R. Levine
> Sent: Wednesday, April 27, 2011 6:33 PM
> To: Murray S. Kucherawy
> > As for TEMPFAIL, you'd have to know which signature(s) were temp-
> failed in order to decide about a later retry, which then leans us
back
> toward giving the whole list of signatures that were present and a
> status for each.
> 

I'm not comfortable with this statement. If I have two signatures, one
from the domain in the From and one from a random 3rd party and the From
domain signature fails and the 3rd party passes then we declare success
with the 3rd party d=signature? To me that dog won't hunt.

> c) If nothing verified and something tempfailed, return a hint to try

And what exactly might this hint be? (not being sarcastic, probably just
dense). How much later? How many retries? How likely is the verifier to
be willing or able to hold large queues to accommodate tempfails? If
not, is this a potential attack vector against the receiver? 

> flip a coin and either report success or a try again hint.

Ugh, no way on d). For multiple signatures where one or more is a
tempfail, it should really be that each one gets its own output (signing
domain plus result) and leave it to the consumer of the output to
determine what to do. What happens if you have 3 signatures? It gets
messy real quick. 

I don't think we have had a thorough discussion on multiple signature
issues along this thought line and I'm not sure throwing something in at
the last moment during last call is the way to address it.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 27 Apr 2011 21:11:21 -0700

On 4/27/2011 8:56 PM, MH Michael Hammer (5304) wrote:
> I'm not comfortable with this statement. If I have two signatures, one from
> the domain in the From and one from a random 3rd party and the From domain
> signature fails and the 3rd party passes then we declare success with the 3rd
> party d=signature? To me that dog won't hunt.

Mike, I believe you are continuing to different parts of the architecture.

The DKIM verifier does not know anything about the "type" of the signature, such 
as whether it is first party or third.  An architectural function that is 
outside of DKIM signing makes those sorts of higher-level, integrative analyses.

The current discussion is only about signature validation and how to report them.

To make this more direct:  For DKIM signing, there is no such concept of "From 
domain signature".

The issue for payload at the level of DKIM Signing, the issue needs to be kept 
quite simple:  Report signatures that validate and I guess also report 
signatures that get a temporary failure.

No other formal payload comes out of the DKIM Signing spec, no matter what other 
sorts of cleverness a particular implementer might provide.  The cleverness is 
fine, but it goes beyond the spec.

d/
-- 

   Dave Crocker

---

From: "John R. Levine" <[email-masked]>
Date: 28 Apr 2011 00:15:14 -0400

>> a) If at least one signature verifies, report success with the d=
>> value(s) of the valid signature(s) and optionally other stuff.
>

That is quite specifically what 4871 says.  To do anything different would 
be a major incompatible change.  We have explicitly rejected the idea that 
"first party" signatures are special in DKIM.  (They are in ADSP, but 
that's ADSP.)  Among the reasons we rejected the "first party" stuff is 
that it would make DKIM unable to work usefully with mailing lists like 
this one.

> not, is this a potential attack vector against the receiver?

Those are all reasonable questions, but I don't think this is a change 
from 4871, which suggests using SMTP 451 codes to force the sender to 
resend the message later, for whatever the sender's interpretation of 
later is.  Can't get much vaguer about retry strategy than that.

> determine what to do. What happens if you have 3 signatures? It gets

The current language in 4871 says in more than one place that you ignore 
signatures that don't verify.  It also contradicts itself by suggesting 
that you don't quite ignore a tempfail but somehow arrange to try again 
later.

If we require a verifier to report the details of signatures that don't 
verify, that strikes me as a significant incompatible change.

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 27 Apr 2011 23:22:56 -0700

> Sent: Wednesday, April 27, 2011 3:33 PM
> To: Murray S. Kucherawy

I can take a run at fixing Section 7.  What's the other place that says not to do that?

> Unfortunately, that's not really what the existing language says.

My preference would be to return a list of signatures that either passed or TEMPFAILed, which could be the empty set if all of them PERMFAILed or the message was unsigned, or none of them were acceptable in the first place for whatever policy reasons.  The caller can decide whether it wants to try the whole shebang again later, or continue with what it got.  It's simple and complete.

Can folks live with that?

---

From: Hector Santos <[email-masked]>
Date: Thu, 28 Apr 2011 02:55:22 -0400

> that it would make DKIM unable to work usefully with mailing lists like 

I think you meant to suggest to work unrestrictedly by intentionally 
ignoring policy-based DKIM security controls defined in two WG 
consensus built productions:

     RFC4686  Analysis of Threats Motivating DKIM
     RFC5016  Requirements for a DKIM Signing Practices Protocol

While the MLM if not technical required by IETF standards to support 
policy, there is still intent to neglect security and POLICY every 
becomes a standard or a BCP, the ignorant MLM will be conflict.  You 
might not see that as a problem. I do.  Since ADSP is still in scope 
of the IETF-DKIM charter, its perfectly "legal" to discuss and apply 
it to DKIM.  RFC4871bis can not stop it and hasn't since day 1 and 
odds are very good it never will be able it bury it.

Honoring security guidelines is very useful in all MLMs that chooses 
to support it. Our MLM product does, why can yours?

It was made very simple:

     - Stop restrictive policy from subscribing,
     - Optionally check for restrictive policy subscription,

Problem solved. DKIM mail integration integrity maintained, useful and 
no harm to anyone.

-- 
HLS

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 28 Apr 2011 05:47:18 -0400

> Sent: Thursday, April 28, 2011 12:11 AM
> To: MH Michael Hammer (5304)
> value(s)
> > signature fails and the 3rd party passes then we declare success
with
> the 3rd

I understand that Dave. My point is that if we follow the logic that
John laid out and we end up with outcomes that leave one scratching
their head, there is a potential issue. We have been round and round the
block on the 1st party vs 3rd party issue but this specific point is in
the context of multiple signatures on a single message rather than the
general discussion of evaluating a message with a single signature.

> fine, but it goes beyond the spec.

That's what I said. Report the domain and the outcome for each signature
and leave something else to sort things out. Don't try and do it within
DKIM itself. The decision choices by that something else could be based
on reputation or authoritative assertion, or a combination of the two. I
was simply responding to the choices within DKIM that John was laying
out.

Mike

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 28 Apr 2011 06:03:50 -0400

> Sent: Thursday, April 28, 2011 12:15 AM
> Cc: Murray S. Kucherawy; [email-masked]

The fact that the standard itself does not explicitly go into the "first
party" stuff was a compromise. It doesn't mean that the concept isn't
out there. The logic you are laying out for multiple signatures is
exactly the same flaw that SIDF has where it demands that if a
(arbitrary) Sender field is present then that is the PRA. It allows
attacks to game the system. By allowing someone to break the original
signature and then sign with a signature from some arbitrary domain (I
think we are all aware of the concept of throw away domains) that
passes, it is game the system time.

> later is.  Can't get much vaguer about retry strategy than that.

There has been quite a bit of discussion about how the DKIM evaluation
is occurring after acceptance by a border MTA in many environments. Do
we really want an architecture that does what you are saying? 

> verify, that strikes me as a significant incompatible change.

Coin flipping is a rigorous scientific method of achieving consistent
outcomes.

I'm beginning to wonder if DKIM is truly ready for standards track. I'd
take a significant change that simply says report details including ones
that fail to verify over coin flipping and contradictory language.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 28 Apr 2011 07:53:57 -0700

On 4/28/2011 2:47 AM, MH Michael Hammer (5304) wrote:
>> The DKIM verifier does not know anything about the "type" of the signature,
>> such as whether it is first party or third.  An architectural function
>> that is outside of DKIM signing makes those sorts of higher-level,
>> integrative analyses.
>>
> I understand that Dave. My point is that if we follow the logic that John
> laid out and we end up with outcomes that leave one scratching their head,
> there is a potential issue. We have been round and round the block on the 1st
> party vs 3rd party issue but this specific point is in the context of
> multiple signatures on a single message rather than the general discussion of
> evaluating a message with a single signature.

Mike,

With respect, I believe you do /not/ understand the architectural point at issue 
here.

The confusion that you are experiencing is between the component of the system 
that validates and reports signatures, versus other components that evaluate 
additional aspects of signatures, such as the correlation of the SDID with other 
identifiers in the message..

The fact that the current discussion is about multiple signatures does not 
change the scope of DKIM Signing, nor does it change the fact that correlation 
with other identifiers is outside the scope of DKIM Signing.

I believe that the core confusion here is a tendency to think only in terms of 
the whole system rather than being able to isolate aspects of the system into 
components.

Nothing in the current discussion prevents:

    a) other parts an implementation to make correlations

    b) specific implementations from reporting more information that is 
specified formally for DKIM Signing.  (The only issue with reporting more is 
making sure that no one believes that both sides of the signing process will 
know about these extensions.)

>> To make this more direct:  For DKIM signing, there is no such concept of
>> "From domain signature".
>>
>> The issue for payload at the level of DKIM Signing, the issue needs to be
>> kept quite simple:  Report signatures that validate and I guess also
>> report signatures that get a temporary failure.
>>
>> No other formal payload comes out of the DKIM Signing spec, no matter what
>> other sorts of cleverness a particular implementer might provide.  The
>> cleverness is fine, but it goes beyond the spec.
>
> That's what I said. Report the domain and the outcome for each signature and
> leave something else to sort things out. Don't try and do it within DKIM
> itself. The decision choices by that something else could be based on
> reputation or authoritative assertion, or a combination of the two. I was
> simply responding to the choices within DKIM that John was laying out.

If, by this, you mean report validation failures then you are trying to change a 
core aspect of DKIM.  The reason for treating verification failures equivalent 
to the absence of a signature is a fundamental feature of DKIM.  We should not 
have to re-discuss that issue.

Again, a particular software implementation might choose to do more, but the 
formal DKIM Signing specification MUST NOT.

d/

-- 

   Dave Crocker

---

From: Barry Leiba <[email-masked]>
Date: Thu, 28 Apr 2011 11:17:53 -0400

> identifiers in the message..

Indeed, and we've been back over this many times throughout
discussions, in the last five years.  I sometimes think we should have
started with an architecture document.

On the other hand, maybe we can make all that clearer in a revision of
the Overview doc... start that document with a section about
architecture.  I haven't read it in a while: perhaps it already has
this issue laid out clearly.

Barry, as participant

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 28 Apr 2011 08:25:56 -0700

> this issue laid out clearly.

In:

   <http://dkim.org/specs/rfc5585.html>, Figure 1

there are separate modules for verification, assessment, signing practices and 
filtering.  The text discusses these in terms of what they are for.

If anyone feels that the diagram or the accompanying text needs changing, we can 
of course do that.

The one change that I would make to the diagram is what we did for the later, 
Deployment document (RFC 5863):

    <http://tools.ietf.org/rfc/rfc5863.txt>, Figure 1

which adds a box around the core DKIM service portion of the overall service, to 
distinguish what functions are inside vs. outside of DKIM Signing.

At this point, I'm not hopeful that more explanation or clearer diagrams will 
help folks who do not yet see the difference between a component and a system, 
or a protocol specification and a software specification.

d/
-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 28 Apr 2011 10:38:08 -0700

> From: MH Michael Hammer (5304) [mailto:[email-masked]]
> Sent: Thursday, April 28, 2011 3:04 AM
> To: John R. Levine

We are continuing to conflate the layers of implementation of a total system.  DKIM itself, just the signing and verifying function, contains (quite correctly) absolutely no meaning about the payload it delivers.  None.  And that's not a broken design, it's a layered design.  That information (the "d=" and maybe other stuff) gets passed up to another layer that is free to compare that string to other stuff as much as it wants and make a filtering decision.  But that's not what DKIM itself does.

By analogy, SMTP is a mechanism for moving a message around.  SMTP itself, and by that I mean RFC5321, tells you absolutely nothing about what the content it delivers (a message) means or how your mail programs should handle it.  SMTP doesn't even know if the message is properly formatted.  It's just a mechanism for one end to pack up a message and send it along, the middle guys to relay it on its way, and the end guy to receive it and then do "something" with it, for an arbitrary definition of "something".  It's the envelope around your letter and the system that moves it from place to place; that system has no idea what's in the envelope or the box, because if it had to know that, it would be hugely more complex and expensive.

Another example?  IP is a way of taking a packet of data, regardless of what that data might be, wrapping it up with some useful (destination) information, and moving it from one hop to the next.  It has no idea about congestion control, retries when packets get dropped, where it goes after the next hop, or any of that.  It just knows how to move a blob of data from one place to the next.  If a packet gets lost, the IP layer doesn't have any idea what to do about that.  Now, when a packet does get to the next hop successfully, it gets handed up to the TCP layer, which decides what to do with it next.  It's TCP that decides to look at some of the meta-data in the wrapping and then figure out what to do with it next, or whether or not a packet needs to get re-sent.  But still it doesn't look at the payload of the packet; that gets handed up to yet another layer that actually cracks open the payload and interprets the data.  It's there, in the higher layers, that meaning is fin!
 ally ascribed to what's inside a packet.

Thus it is with DKIM.  DKIM sits on top of RFC5322 and related message format specs, which in turn sit on top of SMTP, which sits on top of TCP, which sits on top of IP, which sits on top of Wi-Fi or Ethernet, etc.  DKIM delivers the "d=" and other stuff to the next layer up.  It doesn't know or care what that "d=" is other than its use to complete the key retrieval step.  The next layer up, i.e. what sits on top of DKIM, is the one that is free to compare "d=" to From: or whatever else it wants to do.  That's not DKIM, that's ADSP or domain reputation or whatever other application we want to come up with that makes use of the output of DKIM.

Let's say we have a separate layer that evaluates a domain name, comparing it to From:, and then does something meaningful with it.  We connect it to DKIM and it works great.  The good thing about this design is that you might be able to take the very same module, with few or no changes, and plug SPF into it too, and it might work just fine, maybe even better.  Cramming all of this logic into DKIM destroys that potential flexibility.

Layered designs are a well established and successful concept.  A quick search online for "layered design" will show you numerous articles that illustrate and explain why this is the case.  This is a good path we're taking, not a bad one.

Ask yourself:  Would it make sense to pack all of RFC5322 into RFC5321, and maybe all the MIME specs, all the registered header fields, and an explanation of how to scan for spam and viruses, etc.?  Would such a specification be usable?  Or is separating them a good idea, making for cleaner, modular design, and making it easier to update one component's specifications without messing with all the others?

If you insist that DKIM itself has to consider policy or first party vs. third party or must enforce the normative parts of RFC5322, then you must also agree that SMTP needs to be expanded to do things like confirm that TCP got the sliding window right.  But if you think that's absurd, then you agree that none of those things belong in DKIM itself.

All of those things we're trying to cram into (or back into) DKIM are not bad questions or things anyone wants to avoid or suppress.  But they don't belong here.  We can and should do all the R&D in the world to determine solutions to those problems.  But not in RFC4871bis.

Please?  Pretty please?  With sugar on top?

---

From: "John R. Levine" <[email-masked]>
Date: 28 Apr 2011 13:52:19 -0400

> I can take a run at fixing Section 7.  What's the other place that says 

Last paragraph of sec 5.2: " Verifiers SHOULD ignore failed signatures as 
though they were not present in the message."

> My preference would be to return a list of signatures that either passed 
> or TEMPFAILed, which could be the empty set if all of them PERMFAILed or 
> the message was unsigned, or none of them were acceptable in the first 
> place for whatever policy reasons.  The caller can decide whether it 
> wants to try the whole shebang again later, or continue with what it 
> got.  It's simple and complete.

That seems reasonable, but I wonder if that's a large enough change to 
provoke a recycle.  I suppose we can argue that the prior language was 
inconsistent.  What does opendkim do?  My verifier, which sometimes runs 
in the SMTP session and sometimes runs other places, treats tempfail 
and permfail the same.

Regards,

---

From: Hector Santos <[email-masked]>
Date: Thu, 28 Apr 2011 13:54:22 -0400

Barry Leiba wrote:

>> Dave Crocker writes to MH Hammer:
>> With respect, I believe you do /not/ understand the architectural 
>> point at issue here.
>>
>> The confusion that you are experiencing is between the component of 
>> the system that validates and reports signatures, versus other 
>> components that evaluate additional aspects of signatures, such 
>> as the correlation of the SDID with other identifiers in the message..
> 

Not officially, but I believe we did, abeit two competing ones. More 
below.

> this issue laid out clearly.

As an long time  engineer, WG outsider, participant, DKIM Implementor 
looking in,  the problem has been the inconsistencies.  Let me try to 
summarize.

These are not exclusively the top three issues of conflict.

   - Mixing of Protocol vs Product Designs
   - Mixing of exclusion vs inclusion of semantics
   - Mixing of Security vs Usefulness

Overall, the two completing architectures is based on long time modeling:

   A1) 3rd party signers honoring security controls based on
       WG consensus built RFC4686, RFC5016, RFC5617

   A2) Unrestricted 3rd party signers with no technical requirement
       nor responsibility to honor security controls, even if they
       are optional.

And if we can even removed A1 from the picture, the A2 leading WG key 
cogs required an out of scope reputation model to resolve the security 
concerns continue to perform in ways where the issues of conflict emerges.

In other words, the issues still crop up.  Take for example, Dave's 
overview document, in Figure 1 DKIM Service Architecture:

     http://dkim.org/specs/rfc5585.html#rfc.section.5

There is nothing wrong with that, except for two things:

    - Checking Signing Practices is a major component of
      the architecture and there is no references to this
      in RFC4871bis

    - An Optimization consideration (above Verify Signature)
      is missing.  This was defined in RFC5016.

No fresh eyes reading RFC4871bis would be able to put together the 
Figure 1 architectural design. He will design code that that is not 
ready for whats described in RFC5585.

So RFC5585 is required and when those same eyes see this software 
engineering flow and module about Checking Signing Practices, the more 
insightful engineer will see that its in the wrong place - for 
optimization reasons.

Yes, its understand that these are all recommendations and 
implementors do not need to add optimization.  But we continue to 
discuss RFC4871bis as if RFC5585 never existed, nor RFC4686, RFC5016, 
RFC5617.

Yes, the RFC5585 architectural design exist, and also the RFC5863 
deployment guide has an entire section devoted to ADSP,  yet we refuse 
to say anything regarding an "Checking Signing Practices" Identity 
Assessor module or anyt closely resembling a "authorized signer" 
concept in general.

Finally, the argument for exclude Signing practices is because it 
makes MLM useful is kinda weak because it is still useful if a MLM 
supported the architectural.  Right now the argument is that it SHOULD 
NOT follow the RFC5585 architectural.

Overall, the non-policy advocates makes it too easy for continue 
debates because you can't bury a live and highly desirable original 
DKIM concept.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 28 Apr 2011 11:02:00 -0700

> Sent: Thursday, April 28, 2011 10:52 AM
> To: Murray S. Kucherawy

Is that inconsistent with the idea of only reporting signatures that verified or those that TEMPFAILed?  In that model, failed ones aren't reported which is logically equivalent to them being ignored.  Seems like a fit to me.

> in the SMTP session and sometimes runs other places, treats tempfail

The return code provided by the final evaluation function does make the distinction, although the caller could treat the two the same just as you do.  It also provides a mechanism for the caller to look through the signatures and get a result for each so that if the caller doesn't want to use that distilled result, it's free to do something more complicated.

---

From: Hector Santos <[email-masked]>
Date: Thu, 28 Apr 2011 14:35:02 -0400

Murray S. Kucherawy wrote:

>> Last paragraph of sec 5.2: " Verifiers SHOULD ignore failed 
>> signatures as though they were not present in the message."

> Is that inconsistent with the idea of only reporting signatures 
> that verified or those that TEMPFAILed?  In that model, failed ones 
> aren't reported which is logically equivalent to them being ignored.  
> Seems like a fit to me.

Why can't we say something that infers?

   Reporting invalid signatures is out of scope but may be
   reported to communicate failure to advanced Identity
   Assessors.

And why can't we just layout the output namespace and let 
implementators decides?

I think it is really unreasonable to throw in this section (that is 
not minor) at the last minute without the proper WG-man-hours for a 
thorough consideration.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 28 Apr 2011 21:00:33 +0200

On 4/28/11 7:38 PM, Murray S. Kucherawy wrote:
> Another example?  IP is a way of taking a packet of data, regardless of what that data might be, wrapping it up with some useful (destination) information, and moving it from one hop to the next.  It has no idea about congestion control, retries when packets get dropped, where it goes after the next hop, or any of that.  It just knows how to move a blob of data from one place to the next.  If a packet gets lost, the IP layer doesn't have any idea what to do about that.  Now, when a packet does get to the next hop successfully, it gets handed up to the TCP layer, which decides what to do with it next.  It's TCP that decides to look at some of the meta-data in the wrapping and then figure out what to do with it next, or whether or not a packet needs to get re-sent.  But still it doesn't look at the payload of the packet; that gets handed up to yet another layer that actually cracks open the payload and interprets the data.  It's there, in the higher layers, that meaning is f!
 in!
> Thus it is with DKIM.  DKIM sits on top of RFC5322 and related message format specs, which in turn sit on top of SMTP, which sits on top of TCP, which sits on top of IP, which sits on top of Wi-Fi…

Right. I strongly believe in the layered approach. However, that's 
exactly the problem here. Like with IP and SMTP and any layered 
application, the upper layer is dependent on what the lower layer 
provides it with. If DKIM only enforces:

d= and
verification status

to be output, then the layered applications you describe (ADSP, domain 
reputation, whatever) doesn't (always) have the means to do their job. 
Or maybe they would have sufficient information if there was a single 
DKIM signature present and all singletons are only once present in the 
header. However, in practice we will see multiple DKIM signatures, with 
possibly multiple From's. Which of the From's is associated with which 
of the successfully verified signatures? For the d= payload, this 
question is not interesting. But for the still-to-be-designed layered 
applications, this question can become quite important.

 From the design view of DKIM I know we should not want it, but what if 
we would add the From address as a third _required_ output parameter? 
With From: I mean: that particular From address that was used to verify 
that particular signature for which the success status is handed over. 
So if there are two From's, and only one signature verifies, the upper 
layer application knows for which of the two From addresses the success 
status applies. Then the upper layer applications are enabled to perform 
whatever they want to do. Wouldn't that also mitigate the problem of 
multiple singletons present?

As the From: address is mandatory input for the signature, it may be a 
logical step to also make it mandatory in the output?

/rolf

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 28 Apr 2011 12:10:52 -0700

> From: Rolf E. Sonneveld [mailto:[email-masked]]
> Sent: Thursday, April 28, 2011 12:01 PM
> To: Murray S. Kucherawy
> header.

But that's not true.  ADSP asks the question:  Did this message have a valid author domain signature?  The output of a set of "d=" names that verified is sufficient to answer that question: Either the author domain is in that list, or it isn't.

Since signatures can break for more reasons than you can count, the only valuable signature is a good one.  Thus, a reputation implementation should only be interested in domain names whose signatures passed.  The output thus also satisfies that requirement.

The only utility in revealing failed signature information is forensics.  That sort of debugging function doesn't need to go in a protocol specification.

> However, in practice we will see multiple DKIM signatures, with

There are three easy answers to that:

a) The specification presumes valid input, and warns signers and verifiers to be sure that those rules have been observed.

b) If an application is presented two different From: fields and handed them to DKIM, and the signature passes, the bottom one is the one that was signed.  We verify from the bottom up specifically to deal with the case where a message has "m" signed instances but "n" total instances, where "m" is less than "n".

c) If an application is presented two different From: fields, it could just as easily reject the message as invalid without even trying to apply DKIM to it.

> that particular signature for which the success status is handed over.

It's always the bottom one.  (More generally, if the signer signed "n" of them, and the signature passed, the bottom "n" of them were signed.)  If you signed the top one, verification will fail, unless they were both the same anyway.

> logical step to also make it mandatory in the output?

Given the above, do we still need to?

-MSK

---

From: Hector Santos <[email-masked]>
Date: Thu, 28 Apr 2011 15:32:27 -0400

> The only utility in revealing failed signature information is forensics.  
> That sort of debugging function doesn't need to go in a protocol specification.

-1.  It is not a debugging function.

It is about security (RFC4686) and deployments considerations 
(RFC5863, see Section 7.3).

> Given the above, do we still need to?

To be more DKIM Mail Integration Consistent and Complete - yes.

See RFC5585 Figure 1 DKIM Service Architecture. The AUID is needed for 
the major CSP (Checking Signing Practice) black box flow in the DKIM 
design.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 28 Apr 2011 12:44:28 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hector Santos
> Sent: Thursday, April 28, 2011 12:32 PM

Neither of those citations give any value to a failed signature.

> the major CSP (Checking Signing Practice) black box flow in the DKIM

Since ADSP is predicated on the SDID, the AUID is not useful here.  Moreover, the AUID in a failed signature is not useful as it could have been modified.

And, once again, DKIM delivers those values but does not use them.  You're talking about making a filtering decision based on them.  Those happen in different layers.  It's fine to have other layers do other amazing things, but we're trying to stay focused on this one.

---

From: Hector Santos <[email-masked]>
Date: Thu, 28 Apr 2011 15:49:20 -0400

>>> Rolf Wrote:

>> Murray Responded:

> Hector Santos responded:

Follow up:

To illustrate this in RFC5585 by labeling the inputs required:

                     |
                     |- RFC5322 Message
                     V
      +--------------------------------+
      |  Message Signed?               |
      +-----+--------------------+-----+
            |yes                  |no
            |                     |
            |SDID/AUID            |AUID
            |                     |
            V                     |
      +-------------+ SDID/AUID   |
      |  Verify     +---------+   |
      |  Signature  |         |   |
      +------+------+         |   |
         pass|            fail|   |
             |SDID            |   |
             V                |   |
      +-------------+         |   |
      | Assessments |         |   |
      |             |         V   V
      +--------+----+      +-------+
          |    |          / Check   \
          |    +--SDID-->/  Signing  \
          |             /   Practices \
          |            +-------+-------+
          |                    |
          V                    V

As you can see, per RFC5585, both SDID and AUID are mandatory DKIM 
outputs.

---

From: "John R. Levine" <[email-masked]>
Date: 28 Apr 2011 16:01:06 -0400

> Is that inconsistent with the idea of only reporting signatures that 
> verified or those that TEMPFAILed?  In that model, failed ones aren't 
> reported which is logically equivalent to them being ignored.  Seems 
> like a fit to me.

I read that as inconsistent with reporting tempfails.

Regards,

---

From: Hector Santos <[email-masked]>
Date: Thu, 28 Apr 2011 16:19:18 -0400

> Neither of those citations give any value to a failed signature.

Sure it does.  DKIM explicits states that a failed signature is too be 
promoted (or demoted depending on your perspective) to a unsigned 
message. Policy security covers that.

But I also agreed that this becomes a flaw in DKIM as there is 
forensic value to failure, especially when there is no policy.   The 
difference is the strong deterministic nature for the existence of 
policy - "I declared it, don't question it." Thats the premise of an 
explicitly declared policy.

> Since ADSP is predicated on the SDID, the AUID is not useful 
> here.  Moreover, the AUID in a failed signature is not useful as 
> it could have been modified.

Thats a different issue altogether.

> And, once again, DKIM delivers those values but does not use them.  
> You're talking about making a filtering decision based on them.  
> Those happen in different layers.  It's fine to have other layers 
> do other amazing things, but we're trying to stay focused on this one.

I am not speaking of filtering and I understand the focus is output 
isolated to a limited DKIM strict set.

The question is where that summary section is DKIM correct and/or 
sufficient for proper DKIM Mail Integration implementation?

Limited to the two outputs (status and SDID), I believe it is not. 
Rolf asked the question I have pointed out many times about the 
inconsistence.

So again from a "strict dkim" standpoint, I lean towards AUID being a 
mandatory input and output.   This is reinforces with the Security, 
Overview and Deployment documents.

And optionally from more DKIM mail integration standpoint, if we want 
to prepare for A-R, semantics about those "extended" output might be 
considered.

I just think that for the sake of completing RFC4871bis, we have too 
many WG-man-years of deployment and experience and limited it to a 
strict DKIM definition is outdated.

So I suggest to find some WGLC compromise that finishes the job and 
still makes RFC4871bis useful for today's DKIM deployment requirements.

Can that be done?  I don't know.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 28 Apr 2011 13:26:47 -0700

> To illustrate this in RFC5585 by labeling the inputs required:

You are confusing DKIM requirements with ADSP requirements.

d/

-- 

   Dave Crocker

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 28 Apr 2011 23:12:20 +0200

> But that's not true.  ADSP asks the question:  Did this message have a valid author domain signature?  The output of a set of "d=" names that verified is sufficient to answer that question: Either…

[Note: ADSP is used here just as an example layered application.] What 
is the author domain in case there are multiple From headers, if DKIM 
doesn't specify it to the upper layer? You gave the answer, but see below.

> Since signatures can break for more reasons than you can count, the only valuable signature is a good one.

Agreed.

>    Thus, a reputation implementation should only be interested in domain names whose signatures passed.

Agreed.

> The output thus also satisfies that requirement.
>

Let's concentrate for the moment on good signatures for this discussion.

> a) The specification presumes valid input, and warns signers and verifiers to be sure that those rules have been observed.

I'm not sure this is an easy answer, given the amount of discussion on 
this topic ;-)

> b) If an application is presented two different From: fields and handed them to DKIM, and the signature passes, the bottom one is the one that was signed.  We verify from the bottom up specifically…

Right. But this is DKIM logic, 4871bis. By not specifying the address in 
the output, it means that the upper layer application needs to follow 
the DKIM spec (4871bis) in order to be able to determine which From 
address it should use for whatever function it provides (e.g. determine 
1st vs 3rd party signature or determine whether something is an author 
domain signature). In other words: by not specifying this type of 
information in the output of DKIM we create a layering violation, as the 
upper layer needs to be aware of the way DKIM deals with this kind of 
situation. Or we rest with a situation where all sorts of functionality 
in layered applications will never be developed, as the required 
information is missing.

> c) If an application is presented two different From: fields, it could just as easily reject the message as invalid without even trying to apply DKIM to it.

Yep, but then it has to check something that is already prescribed in 
RFC5322, thus causing another layering violation.

> It's always the bottom one.  (More generally, if the signer signed "n" of them, and the signature passed, the bottom "n" of them were signed.)  If you signed the top one, verification will fail, un…

Again, this requires DKIM knowledge in the upper layer application.

> Given the above, do we still need to?

I'm afraid we do have. However, I agree it doesn't fit in the current 
limited scope of DKIM (deliver 'd=' as the payload).

/rolf

---

From: Douglas Otis <[email-masked]>
Date: Thu, 28 Apr 2011 14:14:50 -0700

> logical step to also make it mandatory in the output?
Don't dismiss the fact DKIM accepts input that could have been easily 
established as bogus during its handling.

Validating input does not represent an ugly Layer violation.  However, 
not validating input represents an evil Trust violation.

Policy conveyed to recipients likely depends upon DKIM's valid signature 
result combined with the signature header field's "d=" parameter when 
making basic acceptance decisions that vary from domain to domain.

Would one describe the expected use of DKIM to be a layer violation?   
Since DKIM only requires the From header field be confirmed by its 
signature, failing an easy check for unsigned pre-pended From header 
fields clearly indicates DKIM can not be trusted!

DKIM MUST verify the form of critical elements and not simply assume 
they are valid.  DKIM's output MUST accurately reflect the validity of 
the signature AND the validity of message format related to the From 
header field AND the validity of the A-Label used to reference the 
public key.  These checks are not a protocol layer violation.  Not 
making these checks would be misleading and a violation of trust.

Do not assume recipients will be protected by more complex output not 
reflected in the elemental output of a valid signature and its domain.

DKIM is a security mechanism.  Negligence can not be escaped blaming the 
underlying protocol since it does not make any additional assurances of 
trust.  That is clearly the role accepted by DKIM for good or for evil.

-Doug

---

From: <[email-masked]>
Date: Thu, 28 Apr 2011 13:52:48 -0400

+100
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Murray S. Kucherawy [[email-masked]]
Sent: Thursday, April 28, 2011 1:38 PM
To: [email-masked]
Subject: Re: [ietf-dkim] Output summary

---

From: Hector Santos <[email-masked]>
Date: Thu, 28 Apr 2011 18:23:40 -0400

> You are confusing DKIM requirements with ADSP requirements.

Please respect there is no intent to do this.

Rather I am highlighting the limited DKIM output requirements is 
outdated and  insufficient to support today's (extended) DKIM mail 
integration and security needs outlined by WG consensus-built RFC 
documents:

      DKIM Security Assessment  (RFC4686)
      DKIM Service Architecture (RFC5585)
      DKIM Deployment Guideline (RFC5863)
      DKIM Signing Practices    (RFC5617)
      DKIM Reporting using A-R  (RFC5451)

Here is a way to view the old vs new design dilemma:

      SMTP vs ESMTP (Extended SMTP)

We have decades of engineering foresight to not repeat completing a 
protocol design with an outdated limited output scope especially when 
extensions are already available.

While I am in no way suggesting RFC4871Bis should be updated as an 
EDKIM (Extended DKIM) standard,  we should recognized that DKIM-BASE 
has limited usefulness with its limit outputs requirements.   As we 
know today, AUID should not be excluded from the output summary.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 28 Apr 2011 15:42:30 -0700

On 4/28/2011 3:23 PM, Hector Santos wrote:
> Rather I am highlighting the limited DKIM output requirements is outdated and
> insufficient to support today's (extended) DKIM mail integration and security
> needs outlined by WG consensus-built RFC documents:

What part of "that's ADSP, not DKIM (signing)" did you not understand?

d/
-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 28 Apr 2011 15:48:54 -0700

> Sent: Thursday, April 28, 2011 2:12 PM
> To: Murray S. Kucherawy
> > b) If an application is presented two different From: fields and
> > handed them to DKIM, and the signature passes, the bottom one is the
> > one that was signed.  We verify from the bottom up specifically to deal
> > with the case where a message has "m" signed instances but "n" total
> > instances, where "m" is less than "n".
> 

Layering design stipulates that the lower layers don't depend on the upper ones.  The reverse, however, is not a constraint; an assessment module that knows it's consuming DKIM output is allowed to know something about what's coming up from below.  That's consistent with the idea that such a layer knows DKIM only validates header fields from the bottom up.

If you're adding DKIM to an application, it doesn't seem a layer violation to me to understand and apply what it's telling you, provided it's well-documented.

As another example, your web browser chooses how to render pages by parsing the content it's given by the TCP stack and applying it accordingly.  The transport layer doesn't know anything about the data it's handing up the chain, but the layers sitting on top of it do have some idea of how to make proper use of it.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 28 Apr 2011 15:55:12 -0700

> Sent: Thursday, April 28, 2011 3:24 PM
> To: [email-masked]
> Subject: Re: [ietf-dkim] Output summary - Mandatory Outputs
> 

Please show me any citation in RFC5451 that demonstrates your claim.

> extensions are already available.

And we're not.  To use your analogy: DKIM returns a status and "d="; extended DKIM (whatever that means) can return that and more.  We're updating the specification of DKIM here, not declaring what extended DKIM might be.

It works just fine.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 28 Apr 2011 16:15:06 -0700

> And we're not.  To use your analogy: DKIM returns a status and "d="; extended DKIM (whatever that means) can return that and more.  We're updating the specification of DKIM here, not declaring what…

Just to check:  I'm not seeing any new material in these new exchanges.  So it 
doesn't look like it needs further discussion?

d/

-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Thu, 28 Apr 2011 19:27:57 -0400

Dave CROCKER wrote:
>> integration and security needs outlined by WG consensus-built RFC documents:
> 

> What part of "that's ADSP, not DKIM (signing)" did you not understand?

When asked this way, I don't understand "not DKIM (signing)."

Per DKIM, since AUID is a mandatory input for signing via the required 
From: binding to the signature, with engineering reason, it should be 
included in the output summary.  What is done with it is not the question.

I believe you are trying to infer perhaps the Output Summary section 
should have an initial introduction:

    A trust assessment final output is the only DKIM final output 
requirement.

If so, there has never been any confusion over this limited DKIM goal 
and IMO, the proposed new section would be redundant.

I'm saying no one in their right mind is only going solely read 
RFC4871bis but also your other fine overview documents.  If they did, 
they will design code that is functionally incapable to support 
anything but a trust model only and to develop any new assessment 
engines (probably because they read the overview and deployment 
guides), they will need to change their software. The practical world 
will not design their code with only a RFC4871bis limited scope 
because the experiences already exist - as your overview and 
deployment guides show.

So its more about how one can sneak in some verbiage without 
conflicting with RFC4871bis final production, if all possible.

Can that be done?

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Thu, 28 Apr 2011 19:49:02 -0400

> Please show me any citation in RFC5451 that demonstrates your claim.

Sorry, correction, it would be the RFC5451 extension for DKIM

          DKIM Reporting using A-R  (RFC6008)

          http://www.rfc-editor.org/rfc/rfc6008.txt

> And we're not.  To use your analogy: DKIM returns a status 
> and "d="; extended DKIM (whatever that means) can return that and 
> more.  We're updating the specification of DKIM here, not 
> declaring what extended DKIM might be.
> 
> It works just fine.

I agree, for current implementors.

Not for a fresh reader just reading RFC4871bis.  I was hoping the 
analog was obvious.  It would be like reading only SMTP (RFC821) 
today, designing your software around this model only knowing full 
well there are for Extended SMTP operations and design needs. You will 
read those relevant documents starting with RFC5321.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 28 Apr 2011 17:03:09 -0700

> From: Hector Santos [mailto:[email-masked]]
> Sent: Thursday, April 28, 2011 4:49 PM
> To: Murray S. Kucherawy

Please show me any citation in RFC6008 that demonstrates your claim.

---

From: Hector Santos <[email-masked]>
Date: Thu, 28 Apr 2011 20:06:12 -0400

> doesn't look like it needs further discussion?

So basically the answer to Rolf's question:

     As the From: address is mandatory input for the signature, it may
     be a logical step to also make it mandatory in the output?

is no.

No further discussions needed about From: Address nor the AUID for the 
Output Summary.

---

From: Hector Santos <[email-masked]>
Date: Thu, 28 Apr 2011 20:28:10 -0400

> Please show me any citation in RFC6008 that demonstrates your claim.

Hmm, what specific claim you think is being made?  What are you 
driving at?  That A-R is not a fundamental part of Today's DKIM 
architecture?   Its is all over the place tieing DKIM to A-R, 
including in RFC4871bis. A google search will show all this. [1]

Do you have an RFC5451 "extension" I-D specific for DKIM A-R reporting?

I don't recall whether you do or not but I followed some DKIM A-R 
examples out there to produce A-R to include DKIM, ADSP reporting.  As 
an implementor,  I needed all the extra output and had to modify 
existing code to get that extra information not spelled out by DKIM.

The point is you need these extra documents to get it right.  You need 
A-R today because its the only "BCP" around for DKIM and if anyone who 
dares to claim it not needed and even tries to compete with it, well, 
you, I and probably many others will contest that claim as well.

[1] http://en.wikipedia.org/wiki/DomainKeys_Identified_Mail

Signature verification failure does not force rejection of the 
message. Instead, the precise reasons why the authenticity of the 
message could not be proven should be made available to downstream and 
upstream processes. Methods for doing so may include sending back an 
FBL message, or adding an Authentication-Results header to the message 
as described in RFC 5451.

---

From: Hector Santos <[email-masked]>
Date: Fri, 29 Apr 2011 06:13:34 -0400

> trust.  That is clearly the role accepted by DKIM for good or for evil.

DKIM becomes very simple to understand, enlightening and incredibly 
very mind smoothing when you completely remove from your mind security.

DKIM (RFC4872bis) is an intermediate signer trust mechanism for 
authenticated messages.  There is no certifiable trust in the 
self-signed signature.  Anything beyond that is out of scope.

What are the outputs?

There are arguably (maybe not) only two outputs at the DKIM level; The 
signature validity status and the signer identity. Anything beyond 
that is out of scope.

Since a valid signature signer identity MUST be communicated to an 
independent trust assessment service or a local policy trust table, 
arguably (maybe not), the third final or ultimate output is the trust 
status. Anything beyond that is out of scope.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Fri, 29 Apr 2011 07:01:05 -0400

> in layered applications will never be developed, as the required 

+1.

The issue as I see is that is that DKIM (RFC4871bis) audience can be 
easily confused by reading RFC5585 Figure 1.

Figure 1 is a very good software engineer process flow diagram called 
DKIM Service Architecture. It properly depicts the optional module 
(trapezoid) for Checking Signing Practices.

So the question is should that be part of RFC4871bis to help avoid 
implementor confusion.  After all, that is the goal in protocol designs.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 29 Apr 2011 14:00:51 +0100

>> Thus it is with DKIM.  DKIM sits on top of RFC5322 and related message  
>> format specs, which in turn sit on top of SMTP, which sits on top of  
>> TCP, which sits on top of IP, which sits on top of Wi-Fi or Ethernet,  
>> etc.  DKIM delivers the "d=" and other stuff to the next layer up.  It  
>> doesn't know or care what that "d=" is other than its use to complete  
>> the key retrieval step.  The next layer up, i.e. what sits on top of  
>> DKIM, is the one that is free to compare "d=" to From: or whatever else  
>> it wants to do.  That's not DKIM, that's ADSP or domain reputation or  
>> whatever other application we want to come up with that makes use of  
>> the output of DKIM.
>

Indeed so. The task of DKIM is to express a *reliable* opinion on the  
validity of a signature. All it can say is "PASS" or "FAIL" (actually  
PERMFAIL or TEMPFAIL) and quote the 'd=' and 'h=' tags which it is  
affirming. No Ifs or Buts.

BUT the higher layers include not ony the assessor (which will surely be  
DKIM-aware) but all the subsequent agents through which it may pass  
(notably the recipient's MUA) which are likely less DKIM-aware; but all of  
them need to *rely* in some way on the verifier's assessment.

Therefore, it there is any possibility that subsequent agents will  
misinterpret the assurance given or implied to them, then it is much  
better for the verifier to report "FAIL" which, to agents beyond the  
assessor, indicates that no *reliable* signature was seen.

-- 
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: "Charles Lindsey" <[email-masked]>
Date: Fri, 29 Apr 2011 14:04:50 +0100

> though they were not present in the message."

Actually, that does not seem quite right. It is assessors who should do  
that. Verifiers are explicitly asked to report "PERMFAIL" in that case,  
which is not quite the same thing as "ignoring".

---

From: Hector Santos <[email-masked]>
Date: Fri, 29 Apr 2011 10:49:33 -0400

+1.

The sentence/paragraph should probably be reworded:

CURRENT:

    Verifiers SHOULD ignore failed signatures as though they were not
    present in the message.  Verifiers SHOULD continue to check
    signatures until a signature successfully verifies to the
    satisfaction of the verifier.  To limit potential denial-of-service
    attacks, verifiers MAY limit the total number of signatures they will
    attempt to verify.

PROPOSED CHANGED:

    Verifiers SHOULD continue to check signatures until a signature
    successfully verifies to the satisfaction of the verifier.

    While Verifiers MAY report invalid signatures using methods
    described in section 7.2, verifiers MUST never evaluate invalid
    signatures for trust-based SDID identity assessment.

    If no valid signature is found, the message is considered to be
    unsigned by DKIM standards.

    To limit potential denial-of-service attacks, verifiers MAY
    limit the total number of signatures they will attempt to verify.

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 29 Apr 2011 10:56:03 -0700

Two quick reactions about the first part of the ticket:

    1. This is just a variant of the basic hole created by use of l=

    2. The premise that having the l= go to a multipart boundary somehow 
increases security is simply wrong.  More generally, the idea that one or 
another tidbit might tighten things a bit, l= opens such a huge door, the small 
tidbits don't matter.

As for the second part, with or without Content-Type, messing with the message 
in any interesting way will break the signature.

d/

-- 

   Dave Crocker

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 29 Apr 2011 20:52:28 +0200

> in any interesting way will break the signature.

I'm not sure what you mean by "second part" and "interesting way".
The change to that security consideration section was meant to warn
against the attack that John mentioned, that is:

original:

  DKIM-Signature: d=example.com; h=From:From:Subject; l=17; ...
  From: [email-masked]
  Subject: unsigned Content-Type follows
  Content-Type: text/plain

  This is signed!

changed by attacker:

  DKIM-Signature: d=example.com; h=From:From:Subject; l=17; ...
  From: [email-masked]
  Subject: unsigned Content-Type follows
  Content-Type: multipart/mixed; boundary=boundary

  This is signed!
  --boundary
  Content-Type: text/plain

  Now this is the only visible part of the message,
  the (invisible) MIME preamble is still signed,
  the original signature is not broken.

  --boundary--

---

From: "John R. Levine" <[email-masked]>
Date: 29 Apr 2011 15:14:46 -0400

> another tidbit might tighten things a bit, l= opens such a huge door, the small

On further consideration, I'm with Dave.  Suggest removing the current 
language about l= and MIME boundaries, and replace with a note that if you 
use l=, added content can change the appearance of a message in hard to 
anticipate ways.

Regards,

---

From: "John R. Levine" <[email-masked]>
Date: 29 Apr 2011 15:32:51 -0400

On Fri, 29 Apr 2011, Murray S. Kucherawy wrote:

> Replace the whole section with just that, or only the first paragraph?

Sheesh, you actually want me to read the thing?  Oh, all right.

In 4.4.5, delete "  Signers
    of MIME messages that include a body length count SHOULD be sure that
    the length extends to the closing MIME boundary string."

Also delete the subsequent INFORMATIVE IMPLEMENTATION NOTE.

The note earlier in the section says the bad guy can replace the displayed 
contents, so I don't think we need to say it again.

Regards,

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 29 Apr 2011 13:50:22 -0700

> contents, so I don't think we need to say it again.

+1 to three changes above.

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Sat, 30 Apr 2011 01:26:54 +0200

On 4/29/11 12:48 AM, Murray S. Kucherawy wrote:
> Layering design stipulates that the lower layers don't depend on the upper ones.

Don't get me wrong, I just wanted to demonstrate that, IF we follow the 
logic of not crossing protocol boundaries strictly, THEN communicating 
the d= payload /without additional information/, we

    * either enforce upper layers to violate layers or
    * in advance we discourage in advance the design and development of
      a number of useful applications that otherwise could have been
      built on top of DKIM.

In the archives I found exactly this same concern and discussion, see 
for example the contribution of Jim: 
http://www.mail-archive.com/[email-masked]/msg11105.html

/rolf

---

From: Michael Thomas <[email-masked]>
Date: Fri, 29 Apr 2011 16:37:05 -0700

> http://www.mail-archive.com/[email-masked]/msg11105.html

Indeed, the chickens have come to roost. This was ill-conceived at the
time of the errata, and it is ill-conceived here. It is yet another reason
why I believe that the protocol described in 4871bis only bears passing
resemblance to 4871 and interoperation will be purely coincidental.

Mike

---

From: Hector Santos <[email-masked]>
Date: Fri, 29 Apr 2011 21:15:58 -0400

> resemblance to 4871 and interoperation will be purely coincidental.

What gets me is that I thought IETF bis work were suppose to help 
codify existing implementations - bring it up-to-date.   That was 
burned into me by Hansen and Klensin.  All implementations go beyond 
what RFC4871 and RFC4871bis is not really learning from those 
DKIM-years deployment experiences.  Older APIs had to be changed to 
include A-R. Policy was always part of the API and never removed. Just 
modified from SSP to ADSP.

RFC4871bis is like someone reading RFC821/RFC822 today knowing full 
well it is out of date for today SMTP mail hosting requirements.  You 
won't, you will need to combine all the DKIM documents which was what 
we had to do with I considered the "holy bible" for internet hosting - 
RFC1123. Twelve years later RFC2821 made RFC1123 obsolete.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 29 Apr 2011 19:08:53 -0700

Actually I interpret the message you cited as supporting the current effort to declare that the required output is "d=" plus success/TEMPFAIL, while also very clearly stating that a DKIM verification module is certainly within its rights to provide more than that.

Indeed, OpenDKIM makes a ton of information about the message and signatures available to the caller, so it would be fairly hypocritical for me to be saying "don't do that" while doing it myself.

But I don't think the current language encourages any specific next-layer applications, nor does it discourage any.  The DKIM key and signature tag sets were deliberately made extensible, and so too is the proposed mandatory output description.  If someone were to invent a policy or reputation or other evaluation mechanism that requires the AUID, then one could either create a DKIM validator that provides it to that module (which would still be fully compliant with RFC4871bis), or one could create a "DKIM+" defined in that way and publish that specification.

The strict layer separation you're talking about would prevent some systems from working.  DNS, for example, alters the way it behaves based on whether the layer below it is TCP or UDP; it has to, because the two transport mechanisms have distinct properties.  If you accept that, then it's also OK for an MUA to understand that a validated DKIM signature definitely included the lowest of the From: fields in its header hash, even if many were signed.

-MSK

From: Rolf E. Sonneveld [mailto:[email-masked]]
Sent: Friday, April 29, 2011 4:27 PM
To: Murray S. Kucherawy
Cc: [email-masked]
Subject: Re: [ietf-dkim] Output summary

-----Original Message-----

To: Murray S. Kucherawy

Cc: [email-masked]<mailto:[email-masked]>

information is missing.

Don't get me wrong, I just wanted to demonstrate that, IF we follow the logic of not crossing protocol boundaries strictly, THEN communicating the d= payload /without additional information/, we

 *   either enforce upper layers to violate layers or
 *   in advance we discourage in advance the design and development of a number of useful applications that otherwise could have been built on top of DKIM.

In the archives I found exactly this same concern and discussion, see for example the contribution of Jim: http://www.mail-archive.com/[email-masked]/msg11105.html

/rolf

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 29 Apr 2011 19:10:46 -0700

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Friday, April 29, 2011 4:37 PM
> To: Rolf E. Sonneveld

I don't agree.  I don't know of any current implementations that would be hampered by what's being done here.

An implementation, new or old, that provides both the SDID or AUID up the chain is fully compliant with both versions.  You would only have an interoperability problem if you had written a DKIM verifier that exported only the AUID, or only failed signatures, or something like that.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 29 Apr 2011 19:24:15 -0700

> Sent: Friday, April 29, 2011 6:16 PM
> To: Michael Thomas
> burned into me by Hansen and Klensin.

It is indeed an effort based, at least in part, on clarifying stuff we learned since the earlier version based on experience.  I think it's pretty clear that's what's being done.  Dropping "g=" is a prime example.

But "codifying existing implementations" sounds like you expect a bis effort to write into "law" the code you or others may have written.  That's not what this is for, especially if we got parts of it wrong.  The point is to learn what worked and what didn't, and what can be improved both in design and description.

If you look at your DKIM implementation and see RFC4871, RFC5451 and RFC5617 all present, that doesn't justify the argument that RFC4871bis has to explicitly support all possible use combinations of the three.  That's mixing specification with product design, and it's a gigantic no-no. 

> All implementations go beyond

Sorry, but this doesn't make any sense.  Both A-R and policy functions, plus reputation and anything else that wants to use what DKIM provides, operate at different levels than DKIM does.  A DKIM API doesn't need to know anything about A-R, because DKIM works just fine without A-R.  Same with policy, same with reputation.

An API that was based solely on RFC4871 and was never modified, augmented, or wrapped to support ADSP or A-R will work just fine as-is in the RFC4871bis world.  Whatever you're doing now, unless it's already broken by definition, doesn't have to change.

The sky is not falling.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 29 Apr 2011 19:24:43 -0700

> I don't agree.  I don't know of any current implementations that would be hampered by what's being done here.

Current implementations are irrelevant. They will completely and utterly ignore what is in
4871bis, because they are done and work fine. The problem is whether we've introduced problems
which will cause new implementations to not interoperate with current implementations. Given
the huge number of changes, it's impossible to tell without getting real life data.

This wholesale rewrite of 4871 needs to cause the document to be recycled to PS so that we
can have evidence that we haven't broken something. There is far too small an audience to
vet the changes going on here, and few if any of them are writing code from it.

Going to DS isn't an invitation to change all of the things the few remaining interested
parties didn't like in PS. But that's what I see going on here.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 29 Apr 2011 19:33:38 -0700

> Sent: Friday, April 29, 2011 7:25 PM
> To: Murray S. Kucherawy

I quite agree that there's lots of text that's changing, but I'm having trouble finding much in the way of actual protocol change.  Most of the changes I can recall have to do with dropping advice or technical context that was simply incorrect or poorly stated given the hindsight we now have.  Fixing all of that can only help future implementations.

This is why moving to DS is not allowed if we add stuff, only if we remove stuff.  So far, unless I've missed something, that's all we've done.

---

From: Hector Santos <[email-masked]>
Date: Fri, 29 Apr 2011 23:28:19 -0400

Dave CROCKER wrote:

>   2. The premise that having the l= go to a multipart boundary 
>      somehow increases security is simply wrong.  More generally, 
>      the idea that one or another tidbit might tighten things 
>      a bit, l= opens such a huge door, the small tidbits don't matter.
> 
> As for the second part, with or without Content-Type, messing with 
> the message in any interesting way will break the signature.

+1.

Reviewing all peppered information in the document regarding l=, you 
will find a reference in all these sections.

     4.5.  The DKIM-Signature Header Field
     4.7.  Computing the Message Hashes
     5.1.  Example Scenarios
     6.5.  Recommended Signature Content
     6.6.  Compute the Message Hash and Signature
     7.1.3.  Compute the Verification
     9.1.  Misuse of Body Length Limits ("l=" Tag)
     Appendix D.  MUA Considerations

I find the repeated concerns regarding l= and I also see it may imply 
l= is assumed to be used when in fact it may not.  Overall, we should 
consulate all the l= concerns to one place (references to section 
where applicable).

In section 4.5, 1st sentence for bh= description, it can lead to 
confusion a "l=" will be included in the DKIM-Signature. We certainly 
do not wish to mistakenly cause implementators to set l= when not 
necessary.  I rewording might be:

    bh=  The hash (base64; REQUIRED) of the canonicalized body part
         of the message. It is limited to the entire body length
         count or length explicitly set with optional "l=" tag count
         value. If the hash is to represent the entire body with
         no expectation for additional unhashed text appended to the
         body, the l= tag SHOULD NOT be used. (See Section 9.1).

For the l= description, I proposed removing the INFORMATION 
IMPLEMENTATION WARNING and change the paragraph;

    l= Body length count (plain-text unsigned decimal integer; OPTIONAL).
       By default, when l= is not used, the count is entire body.  The
       length represent the canonicalized message body used for the
       body hash as defined for bh=. If defined, this tag informs the
       verifier of the number of octets in used for the body hash,
       starting from 0 immediately following the CRLF preceding the 
body.
       This value MUST NOT be larger than the actual number of octets
       in the canonicalized message body. See Section 9.1 for security
       related issues concerning the use of l=.

In section 4.7, 4th paragraph, 1st sentence, it can also lead to idea 
the l= tag is going to be used and needs to be part of the 
DKIM-signature.  A rewording might be:

    In hash step 1, the signer/verifier MUST hash the message body,
    canonicalized using the body canonicalization algorithm specified in
    the "c=" tag to create the "bh=" tag (See section 4.5). Setting the
    "l=" body count should only be set if the entire body is not going
    to hash.  See Section 9.1 for security related issues concerning
    the use of l=.

In section 6.5, last paragraph, I think it should be moved to either 
4.5 or 9.1.  This section is about headers to consider and that last 
paragraph has no connections to header, unlike the 4th paragraph which 
describes a l= condition to consider Context-Type header.

In section 6.6, last paragraph, last sentence, it once again can lead 
to the suggestion that a "l=" should be used when it may not be 
necessary, but in this paragraph I believe there is MUST requirement. 
  Rewording might be:

    The signer MAY elect to limit the number of bytes of the body that
    will be included in the hash and hence signed.  When the number of
    bytes is less then the actual body length, the number MUST be set
    in the "l=" tag and added to the DKIM-Signature header field.

In section 7.1.3, itemized step 1, once again, there is a suggestion
the "l=" will be expected to be present. Possible rewording

    1.  Based on the algorithm defined in the "c=" tag, the entire
        body length or length limited by a "l=" tag value, ......

Similarly in section 7.1.3, last paragraph, it infers an existence of 
the "l=" tag.  A possible rewording:

    When the "l=" tag is found in a DKIM-Signature, the value limits the
    number of bytes of the body passed to the verification algorithm.

I guess overall, with the above changes the intent it to not encourage 
the natural use of the harmful "l=" tag when not necessary.

I think the final l= reference in Appendix D for MUA Considerations is 
a good practical consideration for MUA developers.

Finally, since the l= is controversial, limited in areas of usage, all 
the  notes regarding the misusing "l=" and security related concerns 
peppered in the document should be consolidated under 9.1.

---

From: "John Levine" <[email-masked]>
Date: 30 Apr 2011 04:29:01 -0000

>It is indeed an effort based, at least in part, on clarifying stuff
>we learned since the earlier version based on experience.  I think
>it's pretty clear that's what's being done.  Dropping "g=" is a prime
>example.

We've hardly changed the parts that describe how to create and verify
the signature at all, other than perhaps to say that the main output
is d= rather than i=.  (Even there, the way the verifier extracts them
from the message hasn't changed.)

But we've trimmed or removed a lot of what's called in the legal world
dicta, non normative comments.  A good example is all the stuff that
said that a verifier edits the message, which was someone's (I
honestly don't know whose) idea of how it would fit into an
application, but which no implementation I'm aware of actually did.

R's,
John

---

From: SM <[email-masked]>
Date: Fri, 29 Apr 2011 23:59:12 -0700

At 19:33 29-04-2011, Murray S. Kucherawy wrote:
>I quite agree that there's lots of text that's changing, but I'm 
>having trouble finding much in the way of actual protocol 
>change.  Most of the changes I can recall have to do with dropping 
>advice or technical context that was simply incorrect or poorly 
>stated given the hindsight we now have.  Fixing all of that can only 
>help future implementations.

That sounds fine as long as there is agreement on the new text.

>This is why moving to DS is not allowed if we add stuff, only if we 
>remove stuff.  So far, unless I've missed something, that's all we've done.

DS is not about not adding stuff and removing stuff.  The advancement 
is about the maturity of the specification.  This can be gauged in 
terms of implementation and interoperability.

There are different approaches for such a move; a conservative one 
where changes are narrow to avoid destabilizing the specification or 
one where the rationale is changed without affecting the 
requirements.  This case can be argued both ways.  I prefer to see 
implementer buy-in than a label in name only.

Regards,
-sm

---

From: Hector Santos <[email-masked]>
Date: Sat, 30 Apr 2011 03:52:43 -0400

>> Current implementations are irrelevant. They will completely 
>> and utterly ignore what is in 4871bis, because they are done 
>> and work fine. The problem is whether we've introduced problems
>> which will cause new implementations to not interoperate with
>> current implementations. Given the huge number of changes, it's 
>> impossible to tell without getting real life data.

> having trouble finding much in the way of actual protocol change.  
> Most of the changes I can recall have to do with dropping advice 
> or technical context that was simply incorrect or poorly stated 
> given the hindsight we now have.  Fixing all of that can only 

Probably, but with less functionality which will not depict the 
current DKIM Service Architecture currently supported by implementations.

> This is why moving to DS is not allowed if we add stuff, only 
> if we remove stuff.  So far, unless I've missed something, that's 
> all we've done.

But I think the comments are suggesting there really isn't anything 
new being added from what is not already peppered throughout the 
document in some form providing non-spec changing justification to 
include in-scope outputs in the proposed Output Summary.

Isn't RFC4871bis should be about codify existing implementations which 
if you think about it, what the RFC5585 overview has done?

Overall, I believe there are four output values that are not new and 
can be extracted from DKIM:

      status
      d=
      i=
      From:

You can probably write text for From:

     Since the From: is a mandatory input header bound
     to the signature, the address or the domain part
     of the address may be considered output to be
     consumed by an optional signature signing practice
     as described in the DKIM Service Architecture [RFC5585].

It would not be untrue and consistent with RFC5585 which is not new. 
   If we allowed to RFC5451 to RFC4871bis, then we should allow a add 
a more directly DKIM related reference to DKIM Service Architecture 
[RFC5585] document.

Doesn't that fit with DS?

---

From: Hector Santos <[email-masked]>
Date: Sat, 30 Apr 2011 04:55:15 -0400

SM wrote:

>> Murray stated:

+1  Thanks for your input SM.

I think we have four in-scope outputs that are non-spec nor code 
changing and are 100% compatible with the DKIM Service Architecture 
[RFC5585] and existing implementations that support the RFC5585 
architecture.

    verifier return status
    d=
    i=
    From:

We have implementations and API libraries that inherently support 
Checking Signing Practices (CSP) as shown in RFC5585.  This inherent 
support came with the original SSP support when DKIM and Policy was 
one and was only modified to ADSP [RFC5617] definition.

I would like to also note that RFC4871bis has added references to 
AuthRes [RFC5451] and with this official inclusion, we began to 
support it and that required code changes to the API, but it is not 
mandatory if you only stick with reporting the first three outputs 
(status, d= and i=).

More importantly, if RFC5451 reference was compliant with DS, I would 
suggest adding a reference to RFC5585 DKIM Service Architecture is 
more justified and DS compliant and doesn't promote any current 
implementation code changes and better prepares future implementations 
with the proper DKIM output values.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 30 Apr 2011 05:56:00 -0700

> Sent: Saturday, April 30, 2011 1:55 AM
> To: SM
> Cc: Murray S. Kucherawy; Michael Thomas; [email-masked]
> Subject: Re: [ietf-dkim] Output summary - Purported Author
> 

It's not mandatory at all.  It's given as an example mechanism for communicating results between different pieces of the email architecture.  There is no mandate to do anything specific to support RFC5451 over any other mechanism.

> with the proper DKIM output values.

Referencing RFC5451 as an example doesn't promote any current implementation code changes.

Providing a reference to RFC5585 may not be a bad idea though, and RFC4686 and RFC5863 as well.  Perhaps somewhere in Section 1?

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 30 Apr 2011 09:15:54 -0700

>> Current implementations are irrelevant. They will completely and utterly
>> ignore what is in 4871bis, because they are done and work fine. The problem
>> is whether we've introduced problems which will cause new implementations
>> to not interoperate with current implementations. Given the huge number of
>> changes, it's impossible to tell without getting real life data.
>
> I quite agree that there's lots of text that's changing, but I'm having
> trouble finding much in the way of actual protocol change.

An assertion that there have been problematic changes, such as going violating 
the requirements for advancing to Draft, needs affirmative, specific support. 
"Too many changes" is generic and unresolvable and therefore cannot be evaluated 
and is unfixable.

What is "too many"?  Where is the IETF basis for claiming that that criterion 
prevents advancement?  What specific changes are problematic?

These are the sorts of questions that a generic criticism should engender.

Reviewing changes does take a bit of work.  In the IETF, folks making complaints 
are expected to do the work of making things specific.

Fortunately, it's relatively easy work.  Time-consuming, perhaps, but not 
cognitively challenging:  Just look at the diffs across the draft versions.

Diffs are now provided automatically by the IETF's datatracker.  No single diff 
is that massive.  The one diff the datatracker does not provide is between the 
original RFC and the first Internet-Draft, so I've created one, albeit between 
the RFC and the /second/ version of the draft.

The references are conveniently accessible at:

    <http://dkim.org/ietf-dkim.htm#rfc4871bis>

d/

-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Sat, 30 Apr 2011 19:58:14 -0400

> implementation code changes.

Correct. That is what I found when the API only provided the three 
outputs (status, signer, selector).  A-R reporting with more relevant 
information about the process (Checking Signing Practices) did 
necessitate an extension of the API verification output.

> Providing a reference to RFC5585 may not be a bad idea though, 
> and RFC4686 and RFC5863 as well.  Perhaps somewhere in Section 1?

Section 1 as in Introduction? or Note to the Editor?

For an introduction, I think that will work. Most people perusing a 
document like quick references to overviews with "pictures" very helpful.

How will you state it?

---

From: Hector Santos <[email-masked]>
Date: Sat, 30 Apr 2011 20:13:24 -0400

Dave,

My perspective was that the "damage was done" per se in the last 
errata and changes with this bis are irrelevant and don't reflect 
current existing implementations. Code changes are not necessary for 
current implementations because they already follow the DKIM Service 
Architecture with does include ADSP support. However from a strict 
RFC4871bis and the proposed Output Summary standpoint, it does not 
reflect with complete DKIM Service Architecture (RFC5585), as it was 
written, so it be told.

Its really a simple matter from my engineering perspective and if I 
was confusing the DKIM requirement with ADSP requirements, I am not 
the only one.  There is a clear history of this in the WG and I don't 
see anything reducing the "confusion" or as I prefer to call it, 
inconsistencies.

One simple Bug Fix:

Add Author Identity to the Output Summary with a reference to Checking 
Signing Practices per RFC5585.

Thanks

---

From: Hector Santos <[email-masked]>
Date: Sat, 30 Apr 2011 20:32:02 -0400

I think this message by Barry in March 2009 summarizing a conference 
call between Pasi, Stephen and Barry nicely captures the upper/lower 
layers, ADSP, i= and outputs conflicts that continue today:

    http://mipassoc.org/pipermail/ietf-dkim/2009q1/011314.html

Perhaps Dave to lower confusion, you need to remove the "Checking 
Signing Practices" process module from the DKIM Service Architecture 
or perhaps consider changing the title:

       DKIM Service Architecture with optional ADSP support
       Extended DKIM Service Architecture

To ADSP or not ADSP, that is the question.

-- 
Sincerely

Hector Santos

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 30 Apr 2011 19:12:10 -0700

> Sent: Saturday, April 30, 2011 5:32 PM
> Cc: [email-masked]

I think that message doesn't say a single thing about layers.  It looks entirely procedural to me.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 30 Apr 2011 19:21:15 -0700

> Sent: Saturday, April 30, 2011 4:58 PM
> To: Murray S. Kucherawy

That's probably true, but that is also completely different from necessitating a change to the mandatory output.

> Section 1 as in Introduction? or Note to the Editor?

The editor note, quite obviously, is temporary.

> document like quick references to overviews with "pictures" very

How about:

1.  Introduction

[...]

1.1.  DKIM Architecture Documents

Readers are advised to be familiar with the material in [RFC4686] and [RFC5585] and [RFC5863], which respectively provide the background for the development of DKIM, an overview of the service, and deployment and operations guidance and advice.

1.2.  Signing Identity

[...]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 30 Apr 2011 19:42:46 -0700

> Sent: Friday, April 29, 2011 12:33 PM
> To: Murray S. Kucherawy
> Cc: DKIM List
> Subject: RE: [ietf-dkim] Ticket 23 -- l= and Content-type
> 

Sorry, still confused.

What's your counter-proposal to Alessandro's proposal to modify 9.1.1?

The stuff above talks about 4.4.5.  I see what you want there, but resolution of 9.1.1 is an open question (to me).

---

From: Hector Santos <[email-masked]>
Date: Sun, 01 May 2011 00:10:06 -0400

Murray S. Kucherawy wrote:

>> Hector stated:

Darn it. I copied the wrong link and now I can't find it. :(

Let me search again...... Quick search failed. I'll search deeper 
later if you still want me to.  I will find it at some point just to 
have it in my DKIM notes.

Barry provided an outline of the AUID, i=, ADSP relationships 
including possible logic in how to work with it, how it conflicts or 
justified with layer and concluded with suggestions on how to move 
forward.   I thought it captured the unsolved issues and conflicts we 
are still dealing with today highlighted in this Output Summary 
thread.  It was reading like as an possible algorithm to resolve the 
ADSP input value; AUID vs From Domain value applicable to signing 
practice.

But what it did most of for me (yesterday) was highlight the confusion 
with AUID with the lack of an official DKIM label for an Originating 
Domain Identity.  I guess I was moving forward the past year with 
integrating DKIM into our mail products and I see now I was mistakenly 
labeling the AUID as the FROM domain when its not officially defined 
as the From domain.

DKIM-BASE has it "Agent or User" yet defines it as the "i=" value 
which has a direct and specific format related to SDID.  So what is an 
Agent or User?   I think we can agree a USER is the From: address. 
N'est-ce pas?

So perhaps to help shut down this ambiguity we should add a DKIM 
terminology to clearly separate it from AUID.

   3.x  Originating Domain Identity (ODID)

   The ODID is the domain part of the From: address.  This identity
   MAY be considered as an output communicated to an advanced
   Identity Assessor module.

      INFORMATIVE IMPLEMENTATION NOTE:

      The ODID and SDID are inputs for the optional
      Checking Signing Practices component as described
      in the DKIM Service Architecture [RFC5585]

---

From: "John R. Levine" <[email-masked]>
Date: 1 May 2011 00:18:32 -0400

> What's your counter-proposal to Alessandro's proposal to modify 9.1.1?

Oh, that.  Replace all of sec 9.1 with:

  "As noted in Section 4.4.5, use of the l= tag enables a variety of
  attacks in which added content can partially or completely changes the
  recipient's view of the message."

I don't think we actually understand all the ways that l= allows you to 
shoot yourself in the foot, so I would prefer not to give the impression 
that if people avoid a few cases we describe, they're safe.

Regards,

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 30 Apr 2011 21:55:52 -0700

>     Identity Assessor module.

Oh heck, let's just declare that the DKIM Signing module MAY output anything it 
wants.  That way we satisfy every possible output desire that has been expressed 
or might be expressed.  After all, it's clear that implementers need the permission.

Or we might notice that the purpose of a protocol specification is to define 
conventions that are followed by both sides of an interaction and that specific 
specifications are constrained to specific functions, in order to keep them 
tractable.  Telling implementers that they are free to follow any local 
conventions they want violates both of these otherwise-normal requirements.

So rather than continue to fight old, settled issues that primarily have to do 
with making DKIM try to be something it isn', a better idea would be to review:

Section 2.1:
>       INFORMATIVE RATIONALE: The signing identity specified by a DKIM
>       signature is not required to match an address in any particular
>       header field ...

Section 4.5, i=:
>          INFORMATIVE DISCUSSION: This specification does not require the
>          value of the "i=" tag to match the identity in any message
>          header fields.

Section 4.10:
>       INFORMATIVE DISCUSSION: This document does not require the value
>       of the SDID or AUID to match an identifier in any other message
>       header field.

In other words, DKIM has nothing to do with the rfc5321.From field, and 
therefore it is entirely inappropriate -- that is, out of scope -- for the 
specification to suggest dealing with it.

At least, please show working group rough consensus support for doing what you 
suggest.

d/
-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 30 Apr 2011 22:37:14 -0700

> Sent: Saturday, April 30, 2011 9:10 PM
> To: Murray S. Kucherawy
> Subject: Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"
> 

That's unfortunate, but it's also the first case I've heard of someone mistaking the AUID for the From: field.

>    Identity Assessor module.

We already have a name for that: "RFC5322.From".  We don't need a new name for something old.

I don't see any ambiguity here that needs fixing, unless there are lots of people that want to come forward now and admit they had the same misunderstanding you did.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 30 Apr 2011 23:43:54 -0700

I'd like to leave in MIME and HTML exploits as examples if people agree that wouldn't be harmful, such as this updated text in 4.4.5:

                     <t>INFORMATIVE IMPLEMENTATION NOTE: Using body length
                        limits enables an attack in which an attacker modifies a
                        message to include content that solely benefits the
                        attacker. It is possible for the appended content to
                        completely replace the original content in the end
                        recipient's eyes, such as via alterations to the MIME
                        structure or exploiting lax HTML parsing in the MUA,
                        and to defeat duplicate message detection algorithms.
                        To avoid this attack, signers should be wary of using
                        this tag, and verifiers might wish to ignore the tag,
                        {DKIM 2} perhaps based on other criteria.</t>

I'm worried that without this, a neophyte won't see what the attack is.

I'm fine with the proposed simplification of 9.1, and I think at least Dave and JD have +1'd it already as well.

Is that acceptable?