Please define "fault". Also "lookup". I doubt I'm the only one who
doesn't understand what you mean by these words.
A lookup is a callout, a shim, a hook, a "blackbox" query, a "function
generator" and so on. In this case, the lookup is a DNS-based query.
We can today offer a practical functional process model as so:
Result = CheckSigningPractice(ADID [, SDID])
where
ADID is the required Author Domain Identity, and
SDID is the optional Signer Domain Identity.
Note, I used the optional parameter prologue definition since that is
what we have today and we are trying to get SDID back into the lookup
algorithm which MAY be a non-DNS algorithm as well. That is what you
are trying to do. I am saying you need a fallback with the
DKIM-Delegate idea, so at best, it a short circuiting optimization
concept.
The functional concepts are described and outlined in various
documents developed over the years, including the RFC documents
referenced in DKIM RFC6376 section 1.1:
1.1. DKIM Architecture Documents
Readers are advised to be familiar with the material in [RFC4686],
[RFC5585], and [RFC5863], which provide the background for the
development of DKIM, an overview of the service, and deployment and
operations guidance and advice, respectively.
The three documents are:
RFC4686 Analysis of Threats Motivating DKIM
RFC5585 DKIM Service Overview
RFC5863 DKIM Development, Deployment, and Operations
Review the documents to get a functional understanding of the entire
DKIM layered framework. Fundamentally, the lookup in RFC4686 was
conceptualized as "Sender Signing Practices Query" (SSP):
+---------------------------------+
| SIGNATURE CREATION |
| (Originating or Relaying AU) |
| |
| Sign (Message, Domain, Key) |
| |
+---------------------------------+
| - Message (Domain, Key)
|
[Internet]
|
V
+---------------------------------+
+-----------+ | SIGNATURE VERIFICATION |
| | | (Relaying or Delivering AU) |
| KEY | | |
| QUERY +--->| Verify (Message, Domain, Key) |
| | | |
+-----------+ +----------------+----------------+
| - Verified Domain
+-----------+ V - [Report]
| SENDER | +----------------+----------------+
| SIGNING | | |
| PRACTICES +--->| SIGNER EVALUATION |
| QUERY | | |
| | +---------------------------------+
+-----------+
This model still applies as well as the model in RFC5585 where it was
conceptualized as a "Check Signing Practices" (CSP) module, component,
"blackbox" concept:
|- RFC5322 Message
V
+--------------------------------+
| Message Signed? |
+-----+--------------------+-----+
|yes |no
| |
| |
| |
V |
+-------------+ |
| Verify +---------+ |
| Signature | | |
+------+------+ | |
pass| fail| |
V | |
+-------------+ | |
| Assessments | | |
| | V V
+-----+--+----+ +-------+
| | / Check \
| +-------->/ Signing \
| / Practices \
| +-------+-------+
| |
V V
For describing "fault," it is semantically more complex since its a
system level security concept but also a well understood concept among
industry peers across various technical and communications fields
including automated process control concepts, artificial intelligence
concepts like expert systems, fuzzy logic, neural networking, robotics
and yes IETF protocol client/server engineering.
If you have a "series of steps" for an operation, you look for faults,
holes, inconsistencies, "errors" in that operation -- in short,
protocol faults would be threat entry points. They become threat
entry points if you don't watch for these basic conditions:
- no mail expected,
- only 1st party signature expected,
- any valid signature is expected,
- only 1st party or authorized 3rd party.
At best, DKIM-Delegate allows a reduction for lookups, but not
eliminating them. This mean that verifiers must now have fallback and
migration complexities, more coding. It might be worth to explore as
an optimizer. Definitely, not a replacement.
The policy is X, but Y is seen. The payload can be
DKIM-Delegate compliant but the actual policy is exclusive
and doesn't allow it.
You're thinking about a case where one or more unprivileged users at
the first party have been cracked, and mail that dkim-delegate
authenticates is being sent through 3rd parties but shouldn't be?
Its below all that. The logic is detecting a fault in the domain
policy declaration and mail operation expectation compared to what is
actually detected. A condition expected did not happen. What will be
done about it?
The power of the DKIM+POLICY framework since its invention comes from
the detection of these enforceable failure points and taking
enforcement action when the domain has declared such enforcement. If
not enforced, then we have reduced payoff, increase security problems,
high processing wastes.
--
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
