Re: one can re-sign without a permission to re-sign header

On 5/2/2014 1:09 PM, Douglas Otis wrote:

> Dear Hector,
>
> I hope you are willing to review a TPA draft.

Doug, I did go over your drafts in 2009 when it was rev3.  I see I 
even explored compiling your C code under Windows to create labels:

  Directory of M:\rfc\dkim

10/12/2009  10:45 PM            39,185 draft-otis-dkim-tpa-label-03.txt
10/17/2009  08:44 AM             7,175 tpa3.cpp
10/17/2009  08:44 AM            16,384 tpa3.exe

I don't know how much rev6 changed, but as I recalled mentioning to 
you in 2009, there was too much details to follow but it was 
definitely a much wider scope and coverage.  But we all had the same 
basic idea and fundamental problem of an authorized 3rd party 
(re)signer need, whether it was with:

    SSP  Sender Signer Practices
    ADSP Author Domain Signer Practices (RFC5617)
    ASL  ADSP extension for 3rd party (smaller scale)
    ATPS ADSP extension for 3rd party (RFC6541) (larger scale)
    TPA  ADSP extension for 3rd party (wider scope, large scale)

The technical problem was how to best do this via DNS, the scaling and 
optimization with a plug and play DKIM security policy layer as it was 
originally envisioned.  The practical problem was to how convince 
publishers and verifiers, especially resigners, to support and also 
enforce the stronger, restrictive policies as a deterministic mail filter.

It was made a harder problem with the interest of the 3rd party 
resigner became more important than the interest of the originating 
author domain.  This was burned in RFC5016 Section 5.3 Item 10 
functional requirements.  IMO, that needs to be corrected and not 
carried over to any future signing practice requirements or 
specifications doc.  That is not to suggest local policy does not 
prevail in any situation, but it would be the first security protocol 
principle to support the highest domain protection payoff value a 
security protocol has to offer over all any other modes of operations. 
You can't just intentionally ignore it knowing full well what the 
purpose of the security policy protocol was designed to do.

So I think we need to revisit the functional requirements for a DKIM 
Sender/Author Signing Practice protocol.  I believe this will help 
update DMARC or any other "improved DMARC" that comes down the road. 
We need to revisit the basic process model DKIM framework for both 
POLICY and TRUST where a:

    - Message comes in,
    - Verifier Check Author Domain Policy,
    - Verifier Check Signer Trust Policy.

Just like the RFC5585 DKIM Service Overview illustrates and outlines 
in Figure 1:

                              |
                              |- RFC5322 Message
                              V
+--------+    +--------------------------------+
| Private|    |  ORIGINATING OR RELAYING ADMD  |
| Key    +...>|  Sign Message with SDID        |
| Store  |    +---------------+----------------+
+--------+                    |
  (paired)                 [Internet]
+--------+                    |                     +-----------+
| Public |    +--------------------------------+    | Remote    |
| Key    |    |  RELAYING OR DELIVERING ADMD   |    | Sender    |
| Store  |    |  Message Signed?               |    | Practices |
+----+---+    +-----+--------------------+-----+    +-----+-----+
      .              |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  |
+-------------+                  +-----------+     +------------+

                 Figure 1: DKIM Service Architecture



So the framework was laid out. We just need to get folks to support 
the Check Signing Practice (CSP) module and also honor the policy. 
The "Local Info On Sender Practices" module is what John Levine wants 
people to do, including a whitelist.  Thats fine, but it wouldn't be a 
consistent and persistent result across SMTP receiver sites unless 
they had the same local information. Even if this WhiteList was 
centralized,  it should still check and honor how restrictive the 
domain policy is.

-- 
HLS


_______________________________________________
ietf-822 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-822