Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side beni

On Apr 18, 2006, at 2:25 PM, Stephen Farrell wrote:
> Douglas Otis wrote:
> > On Apr 18, 2006, at 1:35 PM, Stephen Farrell wrote:
> > > There's been a good bit of MUA related discussion about
> > > long time periods.
> > >
> > > Our charter says explicitly that the following is out of
> > > scope:
> > >
> > > * Signatures that are intended to make long-term assertions  
> > > beyond the
> > >   expected transit time of a message from originator to recipient,
> > >   which is normally only a matter of a few days at most.
> > The term transit however does include the IMAP and POP transport  
> > and the recipient may perform DKIM verifications at the MUA rather  
> > than elsewhere.  The difference between 7 and 45 days does not  
> > make this a "long term" assertion.
> Seems like it does to me: "a few days at most" is pretty clear.
The duration of the signature should cover the "expected"  
distribution of transit times for a message from the originator to  
recipient.
The Threat and Base draft specifically includes the IMAP and POP MUAs  
as suitable transports using DKIM verification.
Many emails are received by their recipients over these transports  
within a few days.  A normal transit time does not describe the  
"expected" distribution of transit times however.  A good design  
should encompass a large percentage of the distribution of transit  
times.  Not all email will transit within a few days, and not all  
email is transmitted and verified exclusively by servers using SMTP.
If the goal is to provide a signature only to be verified between  
SMTP MTAs, then the Threat and Base draft need to be substantially  
changed to reflect this design constraint.  Creating a flow of about- 
to-expire messages does not offer significant protection from message  
replay abuse, which will still thrive within the current 7 day  
limit.  (Even 7 days is more than a few days.)
A statement of what is normal should not affect the consideration for  
the period of availability needed to reasonably cover the expected  
distribution of transit times over SMTP, IMAP, POP, UUCP, HTTP, etc.   
The charter criteria is clear, the signature should cover the transit  
duration from originator to recipient.  This statement does not  
appear to limit the signature availability to a few days, it only  
indicates what is normally seen for transit times.  Normal is not  
very interesting when setting limits.  A greater amount of  
information must be considered when setting such limits and why they  
call it engineering.
-Doug



_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html