> -----Original Message----- > From: MH Michael Hammer (5304) [mailto:mham...@ag.com] > Sent: Thursday, April 28, 2011 3:04 AM > To: John R. Levine > Cc: Murray S. Kucherawy; ietf-dkim@mipassoc.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 http://mipassoc.org/dkim/ietf-list-rules.html