[ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Murray S. Kucherawy
Sent: Thursday, April 28, 2011 1:38 PM
Subject: Re: [ietf-dkim] Output summary
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 fin!
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.
Let's say we have a separate layer that evaluates a domain name, comparing it
to From:, and then does something meaningful with it. We connect it to DKIM
and it works great. The good thing about this design is that you might be able
to take the very same module, with few or no changes, and plug SPF into it too,
and it might work just fine, maybe even better. Cramming all of this logic
into DKIM destroys that potential flexibility.
Layered designs are a well established and successful concept. A quick search
online for "layered design" will show you numerous articles that illustrate and
explain why this is the case. This is a good path we're taking, not a bad one.
Ask yourself: Would it make sense to pack all of RFC5322 into RFC5321, and
maybe all the MIME specs, all the registered header fields, and an explanation
of how to scan for spam and viruses, etc.? Would such a specification be
usable? Or is separating them a good idea, making for cleaner, modular design,
and making it easier to update one component's specifications without messing
with all the others?
If you insist that DKIM itself has to consider policy or first party vs. third
party or must enforce the normative parts of RFC5322, then you must also agree
that SMTP needs to be expanded to do things like confirm that TCP got the
sliding window right. But if you think that's absurd, then you agree that none
of those things belong in DKIM itself.
All of those things we're trying to cram into (or back into) DKIM are not bad
questions or things anyone wants to avoid or suppress. But they don't belong
here. We can and should do all the R&D in the world to determine solutions to
those problems. But not in RFC4871bis.
Please? Pretty please? With sugar on top?
NOTE WELL: This list operates according to
NOTE WELL: This list operates according to