Subject: [ietf-dkim] New Issue: note on figure in overview draft

From: John Levine <[email-masked]>
Date: 11 Mar 2008 04:20:49 -0000

At the end of section 5, just before the header 5.1 (page 15 of the txt
version) it says:

   Note:  Figure 1 does not show the effects on the message handling
      when multiple signatures or non-author signatures are present.

By my reading, fig 1 covers all signatures, single, multiple, author,
or otherwise, e.g., in the figure it says Verify Signatures with
Signatures in the plural.

Suggested fix: delete the note.

R's,
John
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Wed, 12 Mar 2008 08:06:20 -0700

> Suggested fix: delete the note.

I'm still having a little trouble with Figure 1.  The box that says 
"Verify Signatures" has a "pass" and "fail" output; does that mean "one 
or more signatures pass", "all signatures pass", or what?

This might be addressed by following "verify signatures" with a decision 
box that says "Valid signatures?" with outputs "none" and ">= 1".  This 
might even replace the "Message signed?" decision box.

I had been thinking it would be nice to have a decision box to see if 
the valid signatures are author signatures for all authors, but I'm OK 
if that is lumped into "Assess Signer" (which should really be "Assess 
Signer(s)").

Also please note that Eric's comment on terminology in the Section 5 
intro (with which I agree) applies to Figure 1 as well.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Sun, 23 Mar 2008 14:31:14 -0700

Mumble.

Proposed new text:

               <t hangText="Note:"> By virtue of showing a single private/public
                   key pairing, <xref target="DKIMSvc" /> can be taken to refer
                   to a single message signature. The figure is not intended to
                   comment upon single vs. multiple signature and merely shows
                   the sequential relationship between a signer and a validator
                   and their functional components. </t>

d/

-- 

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

---

From: Dave Crocker <[email-masked]>
Date: Sun, 23 Mar 2008 14:34:49 -0700

Double mumble.

Jim,

Per the response to Levine's concern, I'd rather simply have text that dodges 
the question of multiple signatures, here.  Multiple sigs are fine, but the 
figure is trying to look at a more contained topic.  I believe that having the 
figure explicitly show multiple sigs will, for example, require showing multiple 
private/public key pairs, and probably some sort of iterative behavior to cycle 
through each key.  Since this is an architectural diagram, rather than a 
functional flow chart, I don't think the complexity of iteration is needed.

Can you live with that?

Here is the complete section:

             <artwork name="DKIM Service Architecture"><![CDATA[
                              |
                              |- RFC2822 Message
                              V
+--------+   +--------------------------------+
| Private|   |  ORIGINATING OR RELAYING ADMD  |
| Key    +..>|  Sign Message                  |
| Store  |   +---------------+----------------+
+--------+                   |
  (paired)                    |
+--------+                   |                 +-----------+
| Public |                   |                 | Remote    |
| Key    |               [Internet]            | Sender    |
| Store  |                   |                 | Practices |
+----+---+                   |                 +-----+-----+
      .                       V                       .
      .       +--------------------------------+      .
      .       |  RELAYING OR DELIVERING ADMD   |      .
      .       |  Message Signed?               |      .
      .       +-----+----------------+---------+      .
      .             |yes             |no              .
      .             V                |                .
      .       +------------+         |                .
      +......>| Verify     +-----+   |                .
              | Signatures |     |   |                .
              +-----+------+     |   |                .
                pass|        fail|   |                .
                    V            |   |                .
                +--------+       |   |                .
      +........>| Assess |       |   |                .
      .         | Signer |       V   V                .
      .         +---+----+     +-------+              .
      .             |         / Check   \<............+
      .             +------->/  Signing  \
      .             |       /   Practices \<..........+
      .             |      +-------+-------+          .
      .             |              |                  .
      .             |              V                  .
+----+--------+    |        +-----------+     +------+-----+
|Reputation/  |    |        | Message   |     | Local Info |
|Accreditation|    +------->| Filtering |     | on Sender  |
|Info         |             | Engine    |     | Practices  |
+-------------+             +-----------+     +------------+]]>
             </artwork>
          </figure>
          <t>As shown in <xref target="DKIMSvc" />, basic message processing is
             divided between a signing Administrative Management Domain (ADMD)
             and a validating ADMD. At its simplest, this is between the
             Originating ADMD and the delivering ADMD, but can involve other
             ADMDs in the handling path. <list style="hanging">
                <t hangText="Signing"> Signing is performed by an authorized
                   module within the signing ADMD and uses private information
                   from the Key Store. Within the originating ADMD, this might be
                   performed by the MUA, MSA or an MTA.</t>
                <t hangText="Validating"> Validating is performed by an
                   authorized module within the validating ADMD. Within a
                   delivering ADMD, validating might be performed by an MTA, MDA
                   or MUA. The module verifies the signature or determines
                   whether a signature was required. Verifying the signature uses
                   public information from the Key Store. If the signature
                   passes, reputation information is used to asses the signer and
                   that information is passed to the message filtering system. If
                   the signature fails or there is no signature, information
                   about the related signing practices is retrieved remotely
                   and/or locally, and that information is passed to the message
                   filtering system. </t>
                <t hangText="Note:"> By virtue of showing a single private/public
                   key pairing, <xref target="DKIMSvc" /> can be taken to refer
                   to a single message signature. The figure is not intended to
                   comment upon single vs. multiple signature and merely shows
                   the sequential relationship between a signer and a validator
                   and their functional components. </t>
             </list>
          </t>

-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Sun, 23 Mar 2008 15:28:49 -0700

On Mar 23, 2008, at 2:34 PM, Dave Crocker wrote:

> Double mumble.
>
> Jim,
>
> Per the response to Levine's concern, I'd rather simply have text  
> that dodges the question of multiple signatures, here.  Multiple  
> sigs are fine, but the figure is trying to look at a more contained  
> topic.  I believe that having the figure explicitly show multiple  
> sigs will, for example, require showing multiple private/public key  
> pairs, and probably some sort of iterative behavior to cycle through  
> each key.  Since this is an architectural diagram, rather than a  

Signature validation will incur additional processing and must also  
deal with multiple signatures per message as this is afforded by  
DKIM.  With actions flowing from "Verify Signatures" step in the  
diagram, this appears to be based upon an assumption all signatures  
within a message are to be validated.  Domain/address assessments  
ahead of signature validations may be needed to defend limited  
resources.   Unfortunately it appears there is no consideration as to  
where such strategy might be employed in defending the receiver's  
validation resources.  It is possible a practical solution would be to  
only check signatures of white-listed domains.  Where would this fit  
within the diagram?  It seems defensive methods for DKIM validation  
processing are not congruent with the described workflow in the  
diagram.  Is it really necessary to assume that all messages will have  
all their signatures validated?

-Doug

---

From: John Levine <[email-masked]>
Date: 23 Mar 2008 23:38:50 -0000

>that dodges the question of multiple signatures, here.  Multiple sigs
>are fine, but the figure is trying to look at a more contained topic.
>I believe that having the figure explicitly show multiple sigs will,
>for example, require showing multiple private/public key pairs, and
>probably some sort of iterative behavior to cycle through each key.

I'd rather have it just show one signature and put side text saying
that messages can have multiple signatures, but the way a receiver
interprets multiple valid signatures is beyond the scope of this
document.

R's,
John

---

From: "John L" <[email-masked]>
Date: 23 Mar 2008 22:48:13 -0400

The more I look at this, the messier it gets.

Assuming SSP/ADSP ships in something close to its current form,
how about if we change the figure on page 14 to say Assess Signers
rather than Assess Signer, and change the note to say:

  Note:  If message has more than one valid signature, the order in
  which the signers are assessed and the interactions among the
  assessments are not defined in this document.

I mostly want to be sure we lose the language about not showing
the effects of non-author signatures, which is just wrong.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sun, 23 Mar 2008 22:39:17 -0700

> the effects of non-author signatures, which is just wrong.

Note "Assessments" box and replacement of Note to use your text. I think we are 
done:

             <artwork name="DKIM Service Architecture"><![CDATA[
                              |
                              |- RFC2822 Message
                              V
+--------+   +--------------------------------+
| Private|   |  ORIGINATING OR RELAYING ADMD  |
| Key    +..>|  Sign Message                  |
| Store  |   +---------------+----------------+
+--------+                   |
  (paired)                    |
+--------+                   |                 +-----------+
| Public |                   |                 | Remote    |
| Key    |               [Internet]            | Sender    |
| Store  |                   |                 | Practices |
+----+---+                   |                 +-----+-----+
      .                       V                       .
      .       +--------------------------------+      .
      .       |  RELAYING OR DELIVERING ADMD   |      .
      .       |  Message Signed?               |      .
      .       +-----+-----------------+--------+      .
      .             |yes              |no             .
      .             V                 |               .
      .       +-------------+         |               .
      +......>|  Verify     +-----+   |               .
              |  Signature  |     |   |               .
              +------+------+     |   |               .
                 pass|        fail|   |               .
                     V            |   |               .
              +-------------+     |   |               .
              |             |     |   |               .
      +......>| Assessments |     |   |               .
      .       |             |     V   V               .
      .       +------+------+   +-------+             .
      .              |         / Check   \<...........+
      .              +------->/  Signing  \
      .              |       /   Practices \<.........+
      .              |      +-------+-------+         .
      .              |              |                 .
      .              |              V                 .
+----+--------+     |        +-----------+    +------+-----+
|Reputation/  |     |        | Message   |    | Local Info |
|Accreditation|     +------->| Filtering |    | on Sender  |
|Info         |              | Engine    |    | Practices  |
+-------------+              +-----------+    +------------+]]>
             </artwork>
          </figure>
          <t>As shown in <xref target="DKIMSvc" />, basic message processing is
             divided between a signing Administrative Management Domain (ADMD)
             and a validating ADMD. At its simplest, this is between the
             Originating ADMD and the delivering ADMD, but can involve other
             ADMDs in the handling path. <list style="hanging">
                <t hangText="Signing: "> Signing is performed by an authorized
                   module within the signing ADMD and uses private information
                   from the Key Store, as discussed below. Within the originating
                   ADMD, this might be performed by the MUA, MSA or an MTA.</t>
                <t hangText="Validating: "> Validating is performed by an
                   authorized module within the validating ADMD. Within a
                   delivering ADMD, validating might be performed by an MTA, MDA
                   or MUA. The module verifies the signature or determines
                   whether a signature was required. Verifying the signature uses
                   public information from the Key Store. If the signature
                   passes, reputation information is used to asses the signer and
                   that information is passed to the message filtering system. If
                   the signature fails or there is no signature, information
                   about the related signing practices is retrieved remotely
                   and/or locally, and that information is passed to the message
                   filtering system. </t>
                <t hangText="Note: "> If message has more than one valid
                   signature, the order in which the signers are assessed and the
                   interactions among the assessments are not defined in this
                   document. </t>
             </list>
          </t>

-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Mon, 24 Mar 2008 21:32:00 -0700

Jim,

Jim Fenton wrote:
> I don't think that the interpretation of multiple valid signatures is 
> beyond the scope of this document.  The overview was created in order to 
> provide information on how DKIM might be used; ignoring the multiple 
> signature case does not serve that purpose well.

For the draft text I circulated in a message postd Sun, 23 Mar 2008 22:39:17 
-0700, what changes are you suggesting.  (Or elsewhere in the document?)

d/
-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Mon, 24 Mar 2008 21:12:03 -0700

John Levine wrote:

I disagree.  The input to the "message filtering engine" block is
likely to involve information on more than one valid signature, as is
the decision made by  "assess signer" (which, I argue, should be
plural) as to whether to check signing practices.  The evaluation of a
signature is something that can be done on a per-signature basis, but
later assessments and filtering should show the role of multiple
signatures.

I don't think that the interpretation of multiple valid signatures is
beyond the scope of this document.  The overview was created in order
to provide information on how DKIM might be used; ignoring the multiple
signature case does not serve that purpose well.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Mon, 24 Mar 2008 22:20:33 -0700

Dave Crocker wrote:
>> to provide information on how DKIM might be used; ignoring the 
>> multiple signature case does not serve that purpose well.
>
>
> For the draft text I circulated in a message postd Sun, 23 Mar 2008 
> 22:39:17 -0700, what changes are you suggesting.  (Or elsewhere in the 
> document?)

That version is quite a bit better.  I'd suggest that the block "Verify 
Signature" be "Verify Signature(s)" instead.  The diagram is a bit of a 
tradeoff, but I agree it needs to be.

In the notes underneath, you talk about "validating", but I don't think 
I have seen that term defined anywhere.  From the context, it seems to 
be authentication + assessment, but this should be more explicit.  I 
also prefer the word "validation" to "validating".

Last paragraph, s/are not defined in this document/are at the discretion 
of the validator./

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Mon, 24 Mar 2008 22:36:20 -0700

> tradeoff, but I agree it needs to be.

Tempting, but that would have a cascading effect, because then, for example, the 
diagram would have to deal with different sources of signature and different key 
stores.  Messy.

> also prefer the word "validation" to "validating".

Oops.  The word should be "verifying" since it only was meant to refer to 
verifying a signature.  THe gerund form of the word is intended to echo the 
"signing" term used for the the other ADMD being mentioned.  Parallel 
construction, and all that.

> Last paragraph, s/are not defined in this document/are at the discretion 

1. The current language is formally correct. It declares an explicit boundary, 
with this issue outside of it.

2. Anything that is not within a specification is always at the discretion of 
whoever is doing the processing.  Perhas counter-intuitively there is actually 
more information in saying explicitly that the issue is outside the 
specification than in saying the processor may do whatever it wants.

d/
-- 

   Dave Crocker