ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Output summary

2011-04-28 12:41:17
-----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 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