Subject: RE: [ietf-dkim] x= lets senders expire responsibility

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 13 Apr 2006 07:24:32 -0700

> [mailto:[email-masked]] On Behalf Of Paul Hoffman

> At 5:41 AM -0700 4/12/06, Hallam-Baker, Phillip wrote:
> >I think the semantics are 'don't count on being able to verify this 
> >message after this date'.
> 
> Why would you think that? The semantics of x= say nothing about those
> semantics:
>         Signature expiration in seconds-since-1970 format
>         as an absolute date, not as a time delta from the signing
>         timestamp.  Signatures MUST NOT be considered valid if the
>         current time at the verifier is past the expiration date.
> If you *want* the semantics to mean 'don't count on being 
> able to verify this message after this date', that's fine, 
> but you need to ask the WG to change the document for that to happen.

The semantics of the attributre are the product of the context in which it
is used.

It would be a good thing for the WG to give a correct descripton of the
semantics but I am relaxed on this point. It is not possible to realize the
semantics proposed. I can use the signature in a court of law any time I
please.

>From an administrative point of view it is useful to be able to tell the
signer 'hey dude' (that's technical speak) 'hey dude if you want to verify
this signature better get the signature key before this date.'

         Signature expiration in seconds-since-1970 format
         as an absolute date, not as a time delta from the signing
         timestamp. The signature expiration date allows the signer
	   to notify verifiers that distribution of the signing key 
	   MAY cease once the expiration date has passed.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 13 Apr 2006 11:19:36 -0400

----- Original Message -----
From: "Hallam-Baker, Phillip" <[email-masked]>

> From an administrative point of view it is useful to be able to
> tell the signer 'hey dude' (that's technical speak) 'hey dude if you
> want to verify this signature better get the signature key before
> this date.'
>
>

Ok.  In short, you are saying don't bother trying to do a Verification
because the odds are good it is will fail, and it does fail, this would be
one reason.

Question: Why limit the signer ability to have DKIM system that keeps the
same selector, creates different x= values depending on message type or
value?

I see that is a pretty powerful option.

If we remove x=, we are left with removing selector.

The result is a guarantee that it will fail based on a NXDOMAIN error.

So it is correct to say:

   Signatures with selectors resulting in NXDOMAIN DNS querys SHOULD NOT
   be considered valid?

I prefer to see a more direct "signal" from the signer that says this
signature is no longer valid.   Are we willing to say NXDOMAIN is sufficient
for this?

How about this in section 5.2:

| 5.2  Select a private-key and corresponding selector information
|
|    ..
|    A signer SHOULD NOT sign with a key that is expected to expire within
|    seven days; that is, when rotating to a new key, signing should
|    immediately commence with the new key and the old key SHOULD be
|    retained for at least seven days before being removed from the key
|    server.

That basically means that x= must be used if there is planned event for
selector removal within 7 days.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Mark Delany <[email-masked]>
Date: Thu, 13 Apr 2006 15:59:23 +0000

>    Signatures with selectors resulting in NXDOMAIN DNS querys SHOULD NOT

I have to check the spec, but I thought that you set p= to the empty
string and leave the Selector in place if you wish to revoke the key.

Mark.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 13 Apr 2006 09:01:37 -0700

> selector removal within 7 days.

When the transport includes IMAP and POP, this 7 day advice is far  
too short of a period to ensure verification.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 13 Apr 2006 12:43:23 -0400

----- Original Message -----
From: "Douglas Otis" <[email-masked]>
To: "Hector Santos" <[email-masked]>

>> That basically means that x= must be used if there is a planned event
>> for selector removal within 7 days.
>

Agreed. This SWAG must be from the recommended SMTP retry limits:

| RFC 2821:
| 4.5.4.1 Sending Strategy
|
|  ...
|
|  Retries continue until the message is transmitted or the sender gives
|  up; the give-up time generally needs to be at least 4-5 days.  The
|  parameters to the retry algorithm MUST be configurable.

But for the time-shifted application, if the message reception time
(Received: header) is used, then it shouldn't matter.

Just consider that in a offline MUA like Outlook, where it shows two
possible dates in its message list,  the dates are from:

  Sent: Column  <-- Date: Header
  Received: Column <-- Topmost Received: Header (ISP MDA timestamp)

The MUA (today) only understands these two dates.  Why would it want to use
the current time for a DKIM plug-in?   That doesn't make sense.   You want
to emulate the idea of real time reception so you would use the MDA
reception time.  Not the pick up time.

---
Hector

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 13 Apr 2006 12:59:47 -0400

----- Original Message -----
From: "Mark Delany" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, April 13, 2006 11:59 AM
Subject: Re: [ietf-dkim] x= lets senders expire responsibility

>> Signatures with selectors resulting in NXDOMAIN DNS queries
>> SHOULD NOT be considered valid?
>

Just for readership:

|   p=   Public-key data (base64; REQUIRED).  An empty value means that
|       this public key has been revoked.  The syntax and semantics of
|       this tag value before being encoded in base64 is defined by the
|       k= tag.

Ahhh,  I missed this point - keeping the selector but setting the data to
empty.

ok,  sounds like this will work then to signal an expiration.  Not as
efficient (need a lookup), but in such a case,  as long as the selector is
still active and p= data is empty, x= is not required.  You got your
indicator.

I think I might change my vote to "Get Rid of X="   :-)

I still like the idea of expiring a signing on a per message basis.  Pretty
powerful option for signers.   x= will provide this.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 13 Apr 2006 10:06:00 -0700

> (Received: header) is used, then it shouldn't matter.

When verification occurs at the MUA, the key must remain available  
_beyond_ the SMTP transport period.  Removing keys prior to  
verification impacts assurances being sought with DKIM.  DKIM  
protects messages through more than just the SMTP transport, and is  
one reason given for excluding the envelope.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 13 Apr 2006 14:17:20 -0400

----- Original Message -----

> _beyond_ the SMTP transport period.

Agreed.

Of course, the further away you are from real time, the higher the potential
for failure.  This is par for the course with time-shifted applications for
DKIM.

Unless it has help from the backend server, offline mail systems will not
work very reliably when keys are being changed.

The only way I see to reduced this is to increase the frequency of your
pickup times so that is closer to real time.  At pickup, the DKIM plug-ins
do their work.  So even if you are away on vacation, your computer is still
on and doing its mail pickup.

But the more you shift/delay your verification time, the more you get away
from the real time dynamics of the system and you have more potential
failure.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 13 Apr 2006 11:40:11 -0700

On Apr 13, 2006, at 11:17 AM, Hector Santos wrote:
>
>>> But for the time-shifted application, if the message reception  
>>> time (Received: header) is used, then it shouldn't matter.
>>
> ...
> Unless it has help from the backend server, offline mail systems  
> will not work very reliably when keys are being changed.

Should DKIM require services beyond DNS for verification?

> The only way I see to reduced this is to increase the frequency of  
> your pickup times so that is closer to real time.  At pickup, the  
> DKIM plug-ins do their work.  So even if you are away on vacation,  
> your computer is still on and doing its mail pickup.

Access to email can occur at fairly slow rates.  A delay due to a  
short vacation suggests typical transit times may easily span several  
weeks.  Not every MUA is continuously on-line.

> But the more you shift/delay your verification time, the more you  
> get away from the real time dynamics of the system and you have  
> more potential failure.

This seems to be failure induced by a poor recommendation.   
Recommendations should ensure time for the intended use.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 14 Apr 2006 08:56:55 -0400

----- Original Message -----
From: "Douglas Otis" <[email-masked]>
To: "Hector Santos" <[email-masked]>

> Should DKIM require services beyond DNS for verification?

Is this a trick question? :-)

In contexts of the offline MUA, for it to work reliably, I would think it
will need from feedback from the work done in the backend (ISP, ESP, Mail
Host).

Otherwise, how would get your Offline Mail Reader to work correctly with
DKIM when you have the problem of unknown key revocation?

> weeks.  Not every MUA is continuously on-line.

Agree. The point was, with today's software, the current DKIM specs, fixing
or at least reducing the problem, would be to make it do higher frequency
pickups.

I don't see any other solution for the person who wants to use DKIM with his
offline mail reader and isn't getting any help from this host.  Do you?  How
will you pull this rabbit out of the hat without having a higher frequency
pickup?

What would be the "recommended frequency" for the DKIM ready MUA?

Is this information that should be added to DKIM-BASE?  Maybe. But then I
will have to stop telling some of some of my users to top polling our pop
server every freaking minute! <g>

---

From: Douglas Otis <[email-masked]>
Date: Fri, 14 Apr 2006 09:26:21 -0700

On Apr 14, 2006, at 5:56 AM, Hector Santos wrote:

> In contexts of the offline MUA, for it to work reliably, I would  
> think it will need from feedback from the work done in the backend  
> (ISP, ESP, Mail Host).
>
> Otherwise, how would get your Offline Mail Reader to work correctly  
> with DKIM when you have the problem of unknown key revocation?

While not on-line in the sense of continuous connectivity, an  
intermittent POP or IMAP connection would likely also have concurrent  
access to DNS for resolving such Internet services.

With what you are suggesting, it would seem these DNS records will  
not be retained for a period adequate for protecting IMAP or POP  
transit unless some alternate repository of keys is obtained.

>>> The only way I see to reduced this is to increase the frequency  
>>> of your pickup times so that is closer to real time.  At pickup,  
>>> the DKIM plug-ins do their work.  So even if you are away on  
>>> vacation, your computer is still on and doing its mail pickup.
>>
>> short vacation suggests typical transit times may easily span  
>> several weeks.  Not every MUA is continuously on-line.
>
> Agree. The point was, with today's software, the current DKIM  
> specs, fixing or at least reducing the problem, would be to make it  
> do higher frequency pickups.

One simple solution would be to change the recommendations and ensure  
a reasonable period for accessing keys to enable protections over  
IMAP and POP transit.  A recommendation might be changed to weeks  
rather than days.

> I don't see any other solution for the person who wants to use DKIM  
> with his offline mail reader and isn't getting any help from this  
> host.  Do you?  How will you pull this rabbit out of the hat  
> without having a higher frequency pickup?

What problem is being solved by rapidly removing the availability of  
keys?

> What would be the "recommended frequency" for the DKIM ready MUA?

This is limited by human interaction and as such, is necessarily slow.

> Is this information that should be added to DKIM-BASE?  Maybe. But  
> then I will have to stop telling some of some of my users to top  
> polling our pop server every freaking minute! <g>

A faster polling rate for an MUA is a not a solution. : (

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 14 Apr 2006 13:31:42 -0400

----- Original Message -----
From: "Douglas Otis" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: "IETF-DKIM" <[email-masked]>
Sent: Friday, April 14, 2006 12:26 PM
Subject: Re: [ietf-dkim] x= lets senders expire responsibility

> A faster polling rate for an MUA is a not a solution. : (

Doug,  the current recommendation is 7 days.  That means that at a minimum
the polling rate for your MUA needs to be 6.9 days or less if you don't want
to experience problems.  Right?

Even if the recommended key retention time is increased to 2 weeks, your MUA
minimum polling rate is now 1.9 weeks or less, and so on.

So while the higher retention time is better for the MUA to not miss revoked
keys,  you will always have the same timing issue with the offline MUA.

Right?

---
Hector

---

From: Douglas Otis <[email-masked]>
Date: Fri, 14 Apr 2006 12:12:20 -0700

On Apr 14, 2006, at 10:31 AM, Hector Santos wrote:
>
>> One simple solution would be to change the recommendations and  
>> ensure a reasonable period for accessing keys to enable  
>> protections over IMAP and POP transit.  A recommendation might be  
>> changed to weeks rather than days.
>> ...
>>
> Doug,  the current recommendation is 7 days.  That means that at a  
> minimum the polling rate for your MUA needs to be 6.9 days or less  
> if you don't want to experience problems.  Right?

Many people will not be able to access their email at this rate.

> Even if the recommended key retention time is increased to 2 weeks,  
> your MUA minimum polling rate is now 1.9 weeks or less, and so on.

This is better, but it would be still too little time to assure  
messages within the IMAP/POP transport.

> So while the higher retention time is better for the MUA to not  
> miss revoked keys,  you will always have the same timing issue with  
> the offline MUA.
>
> Right?

Timing email is problematic.  The Date header provides roughly the  
same information as the t= parameter.  The Date header could be  
encompassed by the signature to offer an approximate date of when the  
message was prepared and signed.  The same variation in timing might  
occur when signing, as with delays in the recipient's initial access  
via IMAP/POP.  DKIM does not indicate whether the email was signed  
prior to being submitted by the MUA, or whether the message was  
signed by the MSA.  A very large disparity in the message date could  
be an indication a stale message.  A stale message might happen by  
accident, or due to equipment failures, and would seem to require  
either acceptance or rejection which might lead to the message being  
bounced.

What happens to the message when the key is revoked?

A retired key flag, rather than blanking the public key, can extend  
protections within the IMAP/POP transport while also permitting a  
change in the acceptance criteria at the MDA, which seems to be the  
goal.

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 18 Apr 2006 13:42:48 -0400

> A faster polling rate for an MUA is a not a solution. : (
I think this whole sub-thread highlights the impossibility of designing DKIM 
as an completely reliable MUA level tool.  While it may be useable in the 
MUA, I think the target of the protocol design should remain squarely in the 
MSA-MTA-MDA relm.

In terms of other MUA level timing sources, IIRC, the original Microsoft 
Caller ID for E-mail specifications recommended keeping things published in 
their DNS record for 30 days beyond when they had last been used.  If you 
want to target MUAs, then that's probably about where you need to be.

>From a protocol design perspective, I think the right answer is to design for 
the case where the receiving MTA/MDA will check the signature and record a 
result that, if appropriate, an MUA can use.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Tue, 18 Apr 2006 11:18:24 -0700

On Apr 18, 2006, at 10:42 AM, Scott Kitterman wrote:
>
> From a protocol design perspective, I think the right answer is to  
> design for the case where the receiving MTA/MDA will check the  
> signature and record a result that, if appropriate, an MUA can use.

Depending upon an unsigned "results" header being added to the  
message is an unsafe practice.

It is not practical to determine who added the "results" header,  
whether the MDA strips/adds all prior results headers, and whether  
all possible backup and alternative paths also strip/adds all  
"results" headers.  Retaining the integrity of the DKIM signature for  
a suitable period should permit message verification for transports  
that carry messages beyond the MDA.  Message protection beyond SMTP  
is an important aspect of DKIM.  Reliance upon a results header may  
produce many years of victims that DKIM intended to protect.

Explain the motivation for not including DKIM protection beyond SMTP?

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 18 Apr 2006 14:33:17 -0400

> Explain the motivation for not including DKIM protection beyond SMTP?

The problem is inherent in your statement, "a suitable period".  What's that 
and how do we figure it out?  If you include the MUA, then the only suitable 
period is essentially forever.  

If we decide to design for MSA/MTA/MDA, but do nothing that would explicitly 
preclude MUA use (which is, as I understand it the approach currently 
intended) then MUA based verifiers would likely be able to work reasonably 
well, but without forcing us into a corner on what "a suitable period" is for 
an MUA.  

I would not say that we shouldn't include DKIM protection beyond SMTP, but 
that whatever happens after delivery shouldn't distract us from the primary 
use case.

Some method that can be relied on to store the verification result for future 
use is going to need to be needed in any case so that the verification state 
of stored e-mail can be retrieved when needed.  Whatever solution that is, 
should also work for MDA to MUA delivery of the result.

No reason that I can see that the MDA couldn't add an Auth results header 
field, re-sign the message with it's own DKIM signature (including signing 
the Auth results) and then deliver it.  That would allow the MUA to rely on 
the results header field.  Since the MDA and the MUA are generally in the 
same adminstrative domain, any key rollover issues could be handled 
internally.  I'm not saying that's the right answer, just one possibility 
(and yet another potential reason to solve multiple signatures).

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Tue, 18 Apr 2006 12:43:43 -0700

On Apr 18, 2006, at 11:33 AM, Scott Kitterman wrote:

>> "results" headers.  Retaining the integrity of the DKIM signature  
>> for a suitable period should permit message verification for  
>> transports that carry messages beyond the MDA.  Message protection  
>> beyond SMTP is an important aspect of DKIM.  Reliance upon a  
>> results header may produce many years of victims that DKIM  
>> intended to protect.
>>
> The problem is inherent in your statement, "a suitable period".   
> What's that and how do we figure it out?  If you include the MUA,  
> then the only suitable period is essentially forever.

The period of time a key should remain available would be for as long  
as messages are normally acted upon.  One or two months should cover  
the majority of cases.  The message may request dangerous actions,  
such as clicking upon a link.  When it is assumed normal for messages  
not to verify after a few days, individuals verifying DKIM signatures  
at the MUA would experience many valid messages with an unknown  
status.  This category of messages would create a potential for  
exploitation, which DKIM is attempting to avoid.

> If we decide to design for MSA/MTA/MDA, but do nothing that would  
> explicitly preclude MUA use (which is, as I understand it the  
> approach currently intended) then MUA based verifiers would likely  
> be able to work reasonably well, but without forcing us into a  
> corner on what "a suitable period" is for an MUA.

What is the difference between 1 week and 8 weeks?  How is one more  
of a corner case than the other?

> I would not say that we shouldn't include DKIM protection beyond  
> SMTP, but that whatever happens after delivery shouldn't distract  
> us from the primary use case.

Or the primary goal of offering protection for all obtainable use cases?

> Some method that can be relied on to store the verification result  
> for future use is going to need to be needed in any case so that  
> the verification state of stored e-mail can be retrieved when  
> needed.  Whatever solution that is, should also work for MDA to MUA  
> delivery of the result.

Logging of verification results would be independent of the DKIM  
related protection being sought.

> No reason that I can see that the MDA couldn't add an Auth results  
> header field, re-sign the message with it's own DKIM signature  
> (including signing the Auth results) and then deliver it.

Just as with the results header, even this MDA signing strategy  
depends upon the MDA/MSA properly handling such signatures.

> That would allow the MUA to rely on the results header field.   
> Since the MDA and the MUA are generally in the same adminstrative  
> domain, any key rollover issues could be handled internally.  I'm  
> not saying that's the right answer, just one possibility (and yet  
> another potential reason to solve multiple signatures).

I think this approach could be a good solution for several reasons.   
However, it would only be useful when the handling is defined from  
the outset.

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 18 Apr 2006 16:03:39 -0400

> Or the primary goal of offering protection for all obtainable use cases?

I guess we disagree about MUA level verification being obtainable.  I actually 
have some e-mail accounts I only check about once or twice a year.  If we 
design for the MSA-MTA-MDA case, it should cover most typical MUA cases too.  
In the MSA-MTA-MDA case we can place an upper bound on how long from signing 
to delivery.  With the MUA case, we could spend weeks arguing over it to no 
point.

MUA level verification will never have the same level of reliability as 
MTA/MDA verification for a variety of reasons, of which this is only one, so 
lets not focus on it.  If you'd like some experience with this, you can go 
play with the Thunderbird Extension for Sender Verification.

http://taubz.for.net/code/spf/

In the end, deployed experience with DKIM will tell us how long to leave keys 
in DNS.  No point in getting to worked up over it now anyway.

Scott K

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Apr 2006 21:35:21 +0100

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.

A good part of the discussion seems to me to fall under
this heading. So while MUA verification isn't precluded,
that bullet says that we should not spend time figuring
out what needs to happen in an MUA, or indeed anywhere,
months after signing.

So let's move on.

Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 18 Apr 2006 14:05:48 -0700

On Apr 18, 2006, at 1:03 PM, Scott Kitterman wrote:

> I guess we disagree about MUA level verification being obtainable.   
> I actually have some e-mail accounts I only check about once or  
> twice a year.  If we design for the MSA-MTA-MDA case, it should  
> cover most typical MUA cases too.

When the design criteria handles the typical MUA use scenarios, it  
would also meet the needs of the MSA/MDA verification case.  Checking  
email every 6 months does not represent the typical use of email.

> In the MSA-MTA-MDA case we can place an upper bound on how long  
> from signing to delivery.  With the MUA case, we could spend weeks  
> arguing over it to no point.

DKIM verification is still specified as taking place beyond the MDA.   
MUA verification was the reason for excluding the envelope.  The MUA  
use case has already resulted in design considerations.

> MUA level verification will never have the same level of  
> reliability as MTA/MDA verification for a variety of reasons, of  
> which this is only one, so lets not focus on it.

The MUA verifications should not have lower reliability due to poor  
key availability recommendations.  As this is forgoing perhaps  
critical protections, there should be a reason offered besides  
verification at the MUA may take longer.  Add a statement that MUA  
verifications may take longer than verification at the MDA.

5.2  Select a private-key and corresponding selector information
,---
'__

Here the draft has completely discounted DKIM verification at the  
MUA. : (

To ensure MUA verification remains practical and safe, the draft  
should change key availability recommendations.

: A signer SHOULD NOT sign with a key that is expected to expire within
: 45 days; that is, when rotating to a new key, signing should
: immediately commence with the new key, and the old key SHOULD be
: retained for at least 45 days before being removed from the key
: server.

Adding the expiry within the key could still retain the shorter SMTP  
acceptance constraint.

: A signer SHOULD NOT sign with a key that is expected to expire within
: 45 days; that is, when rotating to a new key, signing should
: immediately commence with the new key, and the old key SHOULD be
: retained for at least 45 days before being removed from the key
: server.  The signer may add a retirement date that represents the
: time the key was no longer used for signing.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Tue, 18 Apr 2006 14:15:24 -0700

>   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.  The goal of DKIM offering protection for the  
"expected transit time", ensuring the message reaches the  
"recipient", remains the critical criteria which seems well within  
the charter.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Apr 2006 22:25:56 +0100

Doug,

Douglas Otis wrote:
> The term transit however does include the IMAP and POP transport and the 
> recipient may perform DKIM verifications at the MUA rather than 
> "long term" assertion.  

Seems like it does to me: "a few days at most" is pretty clear.

Stephen.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 18 Apr 2006 15:13:59 -0700

> out what needs to happen in an MUA, or indeed anywhere,

Thank you.

That said, what I'd really, really, really like is a DKIM signer plugin for
Thunderbird. I've looked at the plugin for the DK verifier and have come
to the conclusion that I'm old and in the way.

       unhipply yours, Mike

---

From: Douglas Otis <[email-masked]>
Date: Tue, 18 Apr 2006 15:38:40 -0700

On Apr 18, 2006, at 2:25 PM, Stephen Farrell wrote:
>> 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.
>

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Apr 2006 00:10:54 +0100

Doug,

Douglas Otis wrote:
> The duration of the signature should cover the "expected" distribution 
> of transit times for a message from the originator to recipient.

Sure. Can you get us the peer reviewed stats so we can
remove those quotes from "expected"?

I certainly don't have 'em, and in the absence of such
real, agreed-upon information I think we're just wasting
time speculating.

There are recent mails talking about "months later", those
discussions are not, IMO, in scope and are significantly
distracting.

Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 18 Apr 2006 16:52:28 -0700

On Apr 18, 2006, at 4:10 PM, Stephen Farrell wrote:
> Sure. Can you get us the peer reviewed stats so we can remove those  
> quotes from "expected"?
>
> I certainly don't have 'em, and in the absence of such real, agreed- 
> upon information I think we're just wasting time speculating.

Section 5.2 in the base draft makes an _unsupported_ speculation  
about adequate key availability.  The transit period should extend  
beyond norms for SMTP, as indicated in other places within the this  
Base and the Threat draft, when describing MUA signing and verification.

> discussions are not, IMO, in scope and are significantly distracting.

Deciding whether other transports beyond SMTP might expect protection  
by DKIM message verification could be productive without too much  
distraction.

DKIM is to be used for:

1) SMTP only
    Starting at the MSA and ending at the MDA mailbox.

2) SMTP + other transports
    Starting at the originator and ending when first viewed by the  
recipient.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Apr 2006 01:36:41 +0100

Doug,

Your response is non-responsive :-(

Douglas Otis wrote:
>> I certainly don't have 'em, and in the absence of such real, 
>> agreed-upon information I think we're just wasting time speculating.
> 
> Section 5.2 in the base draft makes an _unsupported_ speculation about 
> adequate key availability.  The transit period should extend beyond 
> norms for SMTP, as indicated in other places within the this Base and 
> the Threat draft, when describing MUA signing and verification.

So you have no data to offer.

>> There are recent mails talking about "months later", those discussions 
>> are not, IMO, in scope and are significantly distracting.
> 
> Deciding whether other transports beyond SMTP might expect protection by 
> DKIM message verification could be productive without too much distraction.
> 
> DKIM is to be used for:
> 
> 1) SMTP only

So we agree that "months later" is irrelevant. Good.

Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 18 Apr 2006 18:36:06 -0700

On Apr 18, 2006, at 5:36 PM, Stephen Farrell wrote:
>>>> distribution of transit times for a message from the originator  
>>>> to recipient.
>>>
>>> Sure. Can you get us the peer reviewed stats so we can remove  
>>> those quotes from "expected"?
>>>
>> beyond norms for SMTP, as indicated in other places within the  
>> this Base and the Threat draft, when describing MUA signing and  
>> verification.
>

When talking about transports, such as those related to the MUA,  
transit times include SMTP delivery plus delays created by the  
typical vacation/convention/civic duties, etc.

If 7 days provides for the SMTP transport, and people in Sweden and  
France want to verify messages following their 5 week vacation, then  
this would require a minimum of 42 days of key availability.  The  
suggestion for 45 days provided an additional 3 days to assure  
availability following such a vacation.

The table below outlines minimum paid vacation mandates for full time  
workers:

  Country         Vacation Time
  Argentina       14 calendar days
  Australia       No national law, but 4 weeks is standard
  Belgium         20 days, premium pay
  Bulgaria        20 business days
  Canada          At least 2 weeks, determined by provincial law
  Chile           15 working days
  Czech Republic  4 weeks
  France          5 weeks
  Germany         4 weeks
  Hong Kong       7 days
  Hungary         20 work days
  Ireland         4 weeks
  Israel          14 days
  Italy           Mandated vacation, length determined by employment  
contract
  Japan           10 days paid time off (includes other leave time)
  Mexico          6 days
  Poland          18 working days
  Puerto Rico     15 days
  Saudi Arabia    15 days
  Singapore       7 days
  South Africa    21 consecutive days
  South Korea     10 working days
  Spain           30 calendar days
  Sweden          5 weeks
  Taiwan          7 days
  The Netherlands 4 weeks
  Turkey          12 work days
  UK              No national law, implementing EC directive (4 weeks  
annual leave)
  Ukraine         24 calendar days
  US              No national requirement.  Some public employee  
requirements.
  Venezuela       15 paid days

Source: Keller, William L., Timothy J. Darby, and American Bar  
Association.
International Labor Law Committee.
International Labor and Employment Laws. 2 vols. Washington, D.C.:  
Bureau of National Affairs, 1997, 2002 Supplements

http://www.ilr.cornell.edu/library/research/QuestionOfTheMonth/ 
archive/vacationtime.html

Concerns regarding how long a key should remain available depends  
upon what transport is being protected by the signature/key  
mechanism.  The desire was to focus upon determining the transports,  
rather than offering conservative estimates for what the transports  
may require when accessed directly by the recipient.  Too short a  
period unfortunately removes protection from some of these transports.

>> Deciding whether other transports beyond SMTP might expect  
>> protection by DKIM message verification could be productive  
>> without too much distraction.
>>
>> DKIM is to be used for:
>> 1) SMTP only

What is relevant is the transport being protected.  Each transport  
demands a different duration of key availability, even though in most  
cases, the key will be used within a few days.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Apr 2006 02:56:09 +0100

Doug,

> availability following such a vacation.

Eh... That's nonsense. You may as well say that if I choose to stay
offline for a year, then everyone has to abide by that and leave
keys lying about until I'm back.

If you knew the distribution of transit times based on some
reasonable sample, then I'd listen. Presumably there's a bell
curve in there and we could argue about how many std. devs. to
ask signers to take into account. Anything less soundly based
is only as good as our charter, i.e. "a few days at most" so
we may as well stick with that.

Ostensibly non-arbitrary vacation rules don't count. The fact
that you forgot maternity/paternity/parental leave e.g. in
Bayern or Ireland and the fact that those durations differ and
change outside the control of the IETF are all exceptionally
good indicators that you're basically way off base.

The real point is that there is no required correlation
between x= and the duration for which a key is made
available (!= being available) in DNS. There are many
reasons why x= can be in the future but yet no key is
available to check a signature. Endless argument about
some subset of those is unproductive.

So, let's move on. This is a useless dead-end.

Stephen.

---

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 18 Apr 2006 19:26:31 -0700

> we may as well stick with that.

Factoring on normal successful deliveries misses an uncommon, but  
important, class of messages: those delayed by temporary transport  
failures.  E.g. hardware-induced SMTP server failure, intermediate  
network outages, system- and network-admin PEBKAC, recipient mail  
store quota violations, and inbound SMTP server throttling (AOL,  
Yahoo).  All of these are out of the transacting parties control  
(even the quota case, since the receiver can't always control what  
gets dumped in their inbox).

What we need to examine are the stat's related to these delay  
scenarios, and base the lifetime on those numbers, ignoring the  
typical successful delivery case.  (My guess is that sendmail's  
default delivery timeout will heavily influence the results.)

--lyndon

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Apr 2006 03:30:32 +0100

Lyndon Nerenberg wrote:
> Factoring on normal successful deliveries misses an uncommon, 

How (un)common?

 > but
> network outages, system- and network-admin PEBKAC, recipient mail store 
> quota violations, and inbound SMTP server throttling (AOL, Yahoo).  All 
> of these are out of the transacting parties control (even the quota 
> case, since the receiver can't always control what gets dumped in their 
> inbox).
> 
> What we need to examine are the stat's related to these delay scenarios, 
> and base the lifetime on those numbers, ignoring the typical successful 
> delivery case.  (My guess is that sendmail's default delivery timeout 
> will heavily influence the results.)

Real, significant, usable, numbers would be welcome. I've not seen
any.

Absent such we're back at the charter text.

S.

---

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 18 Apr 2006 19:44:13 -0700

> Real, significant, usable, numbers would be welcome. I've not seen

I'll see what I can pull from the mail logs at work.  We push a  
couple of million messages a day, and exercise the AOL and Yahoo mail  
throttles on an ongoing basis.

--lyndon

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Apr 2006 03:50:27 +0100

Lyndon Nerenberg wrote:
> I'll see what I can pull from the mail logs at work.  We push a couple 
> of million messages a day, and exercise the AOL and Yahoo mail throttles 
> on an ongoing basis.

That'd be great. Esp. if you could co-ordinate with a few others
first that see similar distributions.

Thanks,
S.

---

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 18 Apr 2006 20:11:26 -0700

> first that see similar distributions.

Sure.  I'm swamped with other stuff until next week, though.

If there are others on the list who can contribute datasets to the  
cause, please contact me offline.

Note: if you plan to participate, it is critical that the log data  
preserve enough information to uniquely identify each message from  
when it was injected until when it leaves, or dies.  If you have to  
sanitize your data you must ensure you do it in a way that preserves  
enough information to ensure I can accurately identify each  
transaction.  And to be of real value, the logs should contain a  
majority of locally originated messages.

--lyndon

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 18 Apr 2006 23:35:13 -0400

What exactly are we looking for here?  What's the goal?

  - Average User Mail Reception Time?
  - Average POP3/IMAP Polling Time?

---
Hector

---

From: Douglas Otis <[email-masked]>
Date: Tue, 18 Apr 2006 21:51:01 -0700

On Apr 18, 2006, at 6:56 PM, Stephen Farrell wrote:
>
> Douglas Otis wrote:
>> If 7 days provides for the SMTP transport, and people in Sweden  
>> and France want to verify messages following their 5 week  
>> vacation, then this would require a minimum of 42 days of key  
>> availability.  The suggestion for 45 days provided an additional 3  
>> days to assure availability following such a vacation.
>

When a large portion of a country's population goes on vacation for 5  
weeks (or maybe all of August), as provided by local laws, 90% of the  
time they would have normal access to their email.  This would  
significantly affect the distribution of transit delays.  A message  
verified at the MUA, where keys are removed every few days, then  
expose these individuals to the fraud DKIM could have prevented, even  
when only checked at the MUA.  August may become a phishing season. : (

> reasonable sample, then I'd listen. Presumably there's a bell curve  
> in there and we could argue about how many std. devs. to ask  
> signers to take into account. Anything less soundly based is only  
> as good as our charter, i.e. "a few days at most" so we may as well  
> stick with that.

"A few days at most" is _not_ what the charter says.

"... the expected transit time of a message from originator to  
recipient, which is normally only a matter of a few days at most.

Most engineers would read this sentence differently, looking for what  
is being measured.  Normal latency is _really_ not important nor  
significant consideration for establishing a limit.

Consider a European work schedule with an 8 hour work day 5 days a  
week, where email access is obtained from a system at the work  
place.  The standard deviation for email access latency would be  
about 50 hours.  Key availability needs to accommodate the possible  
SMTP latency of 7 days + access latency where 16/48 hours may be  
predominate latency.  This latency would suggest 99% of an area under  
a Gaussian bell curve or normal distribution would be encompassed by  
adding an additional 6.26 days to that needed for SMTP latency.  The  
problem with this conclusion is that the distribution caused by a  
vacation is _not_ Gaussian.

> Ostensibly non-arbitrary vacation rules don't count. The fact that  
> you forgot maternity/paternity/parental leave e.g. in Bayern or  
> Ireland and the fact that those durations differ and change outside  
> the control of the IETF are all exceptionally good indicators that  
> you're basically way off base.

Human behaviors are always outside the control of an IETF standard,  
however a protective standard should accommodate typical human  
behaviors. In some countries, a human induced latency within the MUA  
transport may commonly extend for better than a full month, where the  
mean is still 50 hours.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Apr 2006 09:33:43 +0100

> When a large portion of a country's population goes on vacation for 5 

Exactly what portion is that? I bet a beer that there are more
Swedes that have an email address they never or sporadically
read than there are Swedes that regularly read mail except for
during their supposed 5-week offline. But that's as bogus as
your assertion, since its also based on no data.

If you've got a real distribution, then that'd be interesting.
Deriving/divining a figure of 6.26 days without that isn't
usefully more interesting. Maybe John would like ASRG to
include this as part of their work.

Again, all this is an aside for us. There's no required
correlation between x= and key life cycles. Please stop
flogging that dead horse.

S.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 19 Apr 2006 12:11:37 -0700

On Apr 19, 2006, at 1:33 AM, Stephen Farrell wrote:

> Exactly what portion is that?

What portion of the population would be enough to matter?

"The expected transit time of a message from originator to recipient"  
refers to transit latency where originators and recipients are  
typically people.  A measure of "normal" or the mean of person to  
person email message transit latency will be within the realm of a  
few days at most.  Concerns related to how long a key should remain  
available to protect this transit period must consider typically  
induced latencies due to common human behavior.

While machine to machine latencies are often measured in seconds, but  
still equipment failure recovery often gives up after 5 days.   
Transports beyond SMTP listed as being protected by DKIM carry the  
message to the recipient.  These transports may suffer typical spikes  
in latency when a person is on vacation.  Unusual behaviors will not  
be attractive, as the bad actor would have trouble knowing when to  
exploit this behavior.  The question of expected transit time  
requires the consideration of what is "typical" human behavior.  The  
DKIM charter appears to ask the question of expected transit times of  
messages between humans.  The norm is not interesting, but social  
behavior is predicable.

The WG may conclude the mailbox following a vacation will not be  
assured protection based upon their inadequate recommendations.  This  
would be unfortunate.  A criminal could easily take advantage of such  
poor recommendations and run phishing expeditions during typical  
vacation periods.   People, being social, often exhibit predictable  
behaviors that criminals often exploit.  Going on vacation is a  
classic example.  A person coming back from vacation finding urgent  
notices from their bank, who also learns messages do not verify after  
a few days, would be exposed to possible exploits that deliberately  
spoof such messages knowing many other valid messages will also not  
verify.

In a quote from the Cornell page:
"In Europe, vacation time often occurs in August--all of August! A  
European Union directive prescribes four weeks annual leave for all  
employees (EC 93/104 Art.7(1))."

Average Number of Vacation Days Per Year
Italy		42 days
France		37 days
Germany		35 days
Brazil		34 days
United Kingdom	28 days
Canada		26 days
Korea		25 days
Japan		25 days
U.S.		13 days

Source: World Tourism Organization (WTO).

> I bet a beer that there are more Swedes that have an email address  
> they never or sporadically read than there are Swedes that  
> regularly read mail except for
> during their supposed 5-week offline.  But that's as bogus as your  
> assertion, since its also based on no data.

At this point in time, until some data supports the duration of the  
typical spikes in latency due to vacations, assuming the WG decides  
to protect recipients over their vacation, the recommendations made  
in Section 5.2 in the base draft should only explain what the key  
availability duration should cover, and not indicate that 7 days is  
okay.  In my view, 7 day key availability is not adequate to protect  
emails to the recipient at the MUA.  By assuring protection at the  
MUA, DKIM can offer protection once the sender starts signing their  
messages, and the recipient obtains an email client able to verify  
DKIM signatures.  No other dependency would slow DKIM deployment and  
use.  There would be no delay induced waiting for the deployment  
results header handling, for example.

> Deriving/divining a figure of 6.26 days without that isn't usefully  
> more interesting. Maybe John would like ASRG to include this as  
> part of their work.

The standard deviation figure was mentioned to explain that the  
nature of the distribution of the data must be considered before  
making conclusions about what a standard deviation implies.  If the  
WG decides to protect individuals over their vacation, then the  
duration of these vacations could be assessed using statistics.   
Looking at POP polling intervals and running statistics on this  
information as a whole will overwhelm the information related to  
vacations.  Looking for periods longer than a few days of no polling  
might provide suitable information.  With the US typically taking  
short vacations, the more interesting data would also likely be found  
elsewhere.

> Again, all this is an aside for us. There's no required correlation  
> between x= and key life cycles. Please stop flogging that dead horse.

The x= parameter is a totally separate issue.  Where have I conflated  
the two?

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Apr 2006 20:30:32 +0100

Doug,

I wish you'd stop with the spurious figures.

> The x= parameter is a totally separate issue.  Where have I conflated 

There: [1]. Took all of 5 seconds to find one. There are others.

Stephen.

[1] http://mipassoc.org/pipermail/ietf-dkim/2006q2/003248.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 19 Apr 2006 13:14:56 -0700

> I wish you'd stop with the spurious figures.

These figures strongly suggest the recommendation in section 5.2 is  
inadequate to accommodate lapses in availability owing to vacations,  
when that is important to the sender.

Section 5.2
...
,---
'___

A safer recommendation would be:

: A signer SHOULD NOT sign with a key that is expected to expire within
: a transit period where protection is desired; that is, when rotating
: to a new key, signing should immediately commence with the new key
: and the old key SHOULD be retained for at least the period where
: transit protection is desired before being removed from the key
: server.

>>> correlation between x= and key life cycles. Please stop flogging  
>>> that dead horse.
>>
>> The x= parameter is a totally separate issue.  Where have I  
>> conflated the two?
>

Hector made the inference key availability and the x= parameter are  
related.

My statement was simply:

"When the transport includes IMAP and POP, this 7 day advice is far  
too short of a period to ensure verification."

This was referring to section 5.2 and was not commenting upon the  
conclusion reached by Hector.  My apologies for not changing the  
subject line.

-Doug