On 4/28/11 7:38 PM, Murray S. Kucherawy wrote:
-----Original Message-----
From: MH Michael Hammer (5304) [mailto:MHammer(_at_)ag(_dot_)com]
Sent: Thursday, April 28, 2011 3:04 AM
To: John R. Levine
Cc: Murray S. Kucherawy; ietf-dkim(_at_)mipassoc(_dot_)org
Subject: RE: [ietf-dkim] Output summary
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.
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 f!
in!
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.
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html