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
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822