Subject: [ietf-dkim] Notes from DKIM jabber meeting on 20 April 2006

From: DKIM Chair <[email-masked]>
Date: Thu, 20 Apr 2006 23:54:33 -0400

Some people joined the jabber room early, but we then had problems --
people lost contact with the room, couldn't re-join, and so on.
Problems seemed resolved by 15:15 GMT, and we decided to start at
15:30, to give everyone time to get back on.  

Meeting was called to order at 15:30 GMT.  Agenda posted:
1. Agenda bashing
2. Finialise text for x=
3. AOB

Attendees:
Stephen Farrell
Jim Fenton
Olafur Gudumundsson
Phillip Hallam-Baker
Tony Hansen
Arvel Hathcock
Paul Hoffman
Peter Koch
Barry Leiba
Doug Otis
Bill Oxley
Shamim Pirzada
Hector Santos

Agenda Item 1, agenda bashing:
Doug requested time in AOB to discuss the "7 days" text in section 5.2.
No other agenda issues.

Agenda Item 2, text for "x=":

Issue 1: "SHOULD" in proposed text.
Paul questions how SHOULD fits here, considering RFC 2119.  Several
comments that MAY is fine.  Hector initially thinks verifier "MAY
support" expiration is OK, but if supports, "MUST" honour expiration.
Arvel wonders why bother supporting it if you don't honour it,
supporting Hector's version.  Paul counters that x= is a REQUEST from
the signer, and the verifier can/should do what it wants with the
information.  Others agree.  Barry suggests that perhaps a supporting
verifier might want to honour it differently for different signers
(using reputation, perhaps), but that idea gets no interest.  Hector
and Arvel agree with Paul in the end, and Jim likens "x=" to a "best
sold before" date, where the verifier may "drink the milk" anyway, but
"shouldn't be surprised if it's sour." General agreement (and
amusement) here, and there are no objections to using MAY throughout.  
Resolution: Change to MAY; Stephen will propose new text to the mailing
list.  

Issue 2: Treating expired sig as "broken sig" vs "absent sig".
Hector is concerned that verifiers WILL treat broken different from
absent, despite what the spec says, and wants to make sure that we put
expired sigs on the right side of that.  Barry explains history: if we
recommend treating broken vs absent differently, they expose DKIM to
different attacks, and so we must advise treating them the same.  Given
that, there's little to be gained by worrying about where expired sigs
fit, because a verifier will still choose its own preference, and we
can only give advice.
Resolution: Leave as is.  

Issue 3: Barry checks something from mailing list discussion.  On the
mailing list, some seemed to think that some were advocating making
previous verifications become invalid after expiration.  WAS anyone
actually advocating that, or was it a misunderstanding.  Conclusion was
that it was a misunderstanding, and once the sig is verified (prior to
expiration), the expiration time becomes irrelevant.  

Issue 4: Which "time" at verifier is used to determine expiration?
"received" time, or "current" time?  The distinction is important if
verification is done in MUA, and Doug and Hector both want "received"
time.  Much discussion here, with lots of it centering on whether
received time can be determined reliably, people don't want to be
recommending parsing Received lines, and such.  
Resolution: Suggest using received time "if reliably available", else
current time.  Arvel and Jim aren't sure, but accept it if it's "MAY".
Stephen will propose text.  

Issue 5: Hector wants to add "step 0" in section 6.2, allowing verifier
to check x= first, and shortcut key retrieval if sig has expired.  Some
discussion there, consensus to add it, as "MAY".  

Along with this there was discussion of returning SMTP 4xx errors vs
<whatever else the verifier does with the message>.  Observation that
4xx is ONLY appropriate for true temporary key retrieval errors, and
should NOT be used for other verification problems.  We chould check
text to be sure that's reflected.  

Agenda Item 3, any other business.

Issue 6: Doug's item about "7 days" in 5.2.
If verification is done in MUA, 7 days is not enough time for a key to
remain available.  General agreement that there's a significant issue
here, but no good ideas how to resolve it.  Given that, and the fact
that we were out of time, we will take the general question of
"verification in MUA" issues to the mailing list, with the note that
DKIM is intended to be primarily used in the MTA/MDA, but that it
should allow for MUA use in its design.  We especially need to look at
the timeout and routine key rollover issues with that in mind.

Meeting adjourned at 16:30 GMT.

--
Barry Leiba, DKIM Working Group co-chair  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 21 Apr 2006 12:45:54 +0100

Folks.

I'd like to suggest we do this again in two weeks time in the
same time slot. Any objections/thoughts?

S.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 21 Apr 2006 06:09:33 -0700

>the timeout and routine key rollover issues with that in mind.

IMO, the problem here saying that MUA's can praticipate in verification is
a large rathole. There many structural impediments with them reliably
verifying signatures. For one, many MDA's torture messages in very DKIM
unfriendly ways. Like sucking the attachments into a database and 
regenerating
the mime on output to the MUA. For a pretty large class of MUA/MDA
mating, it's my understanding that trying to get this to work is pretty much
a fools errand.

On the DKIM side, however, if we define that MUA's can verify at all, we
need to exactly qualify what that MUA is to match the general expectation
we place on MTA's and MDA's: that they are connected and that they are
will verify the message within reasonable transit time, and store the 
*results*
of the verification for later use if necessary (ie, it for display 
purposes). If
they won't or can't do those things, then they aren't a 
DKIM-verification-capable
MUA.

Thus a DKIM-verification-capable MxA:

1) MUST receive email in a form whose transformations fall within the 
acceptable set of
    modifications as defined in -base-nn (eg, canon, l=)
2) MUST perform the verification within the "transport window", 
typically 7 days.
3) MUST store the results of the verification process if results of the 
verification process
    will be used for some later process

       Mike

---

From: Sandy Wills <[email-masked]>
Date: Fri, 21 Apr 2006 09:17:44 -0400

("Big Picture" - I lurk on this and other lists for an education, and
try to keep my mouth shut unless I have something to contribute, but
sometimes I gotta ask WTF?)

DKIM Chair wrote:
> recommending parsing Received lines, and such.  Resolution: Suggest 
> using received time "if reliably available", else current time.
> Arvel and Jim aren't sure, but accept it if it's "MAY". Stephen will
> propose text.

I apologize for going thru this _again_, but I simply don't understand 
the question, so the answers aren't helping much.  Here's a (made-up) 
example from real life, which I hope is close enough to use here.  While 
DKIM isn't about economic compensation like postage stamps are, the 
concept if "being authorized for a specific period, then being no longer 
useable" should cross over:

    Let's say that your grandmother, somewhere in the US, sent her 
daughter (your mother) a letter at her newlywed house sometime in late 
1941.  Something bad happened out in the Pacific, causing a hiccup in 
the mail-delivery system, and a lot of stuff was delayed, some of it so 
much that it was forgotten.
    A couple of years ago, you moved back into that old house you grew 
up in to take care of your parents, and your mother is still there at 
the same address.  These days, you have to do pretty much everything for 
her, including going thru her mail, throwing out all the ads for things 
that she no longer needs.  Your grandmother, unfortunately, is no longer 
with us.
    Yesterday, the USPS was closing down an old post office, and found a 
box of old letters that never got delivered.  Your grandmother's letter 
is in there.
    If I understand the expiration time question right, some people 
think that it's okay for a USPS drone to throw that letter out, because 
the 3 cent postage doesn't match current rates.  I think that it would 
be better if his supervisor said "No, that postage was valid when that 
letter entered the system -look at the postmark date, meathead- and we 
have to deliver it."
    Walking down the mail delivery system, each handler should say the 
same, including the postman who hands it to you, and you should give it 
to your mother.  Make sure she's up to date on her heart medicine, 
first.  I guess that's okay.

Am I out to lunch here, or am I making sense?

    To me, the only three reasons to _not_ accept that letter as still 
valid for delivery would be:
  - if it only had a 2 cent stamp on it, raising the "bogus" flag, 
because everyone knows that the rates went up 50% (inflation!) to 3 
cents, back in 1932, or if some other obvious sign of forgery 
(laser-printed address label, maybe) was found,
  - if the addressee could not be found,
  - if there was some reason to believe that the original receiving post 
office was controlled by mobsters, foreign agents, or evil spirits. 
Controlled by incompetent bureaucrats isn't enough.

    Getting back to DKIM, I thought that the discussion about which 
country had the longest vacation time was irrelevant, in the context of 
key expiration.  Am I making DKIM too unwieldy, here, asking for a key 
to be verified as good, not today, but when it was used?  There doesn't 
seem to be any added storage cost or processing cycles, since either 
way, you have to have the key to test it, just the question of which 
date to compare to.

-- 
Unable to locate coffee.
Operator halted.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 21 Apr 2006 07:21:11 -0700

Sandy Wills wrote:

> country had the longest vacation time was irrelevant, in the context 
> of key expiration.  Am I making DKIM too unwieldy, here, asking for a 
> key to be verified as good, not today, but when it was used?  There 
> doesn't seem to be any added storage cost or processing cycles, since 
> either way, you have to have the key to test it, just the question of 
> which date to compare to.
>
An interesting analogy (cf mail, postage, box of 50 year old mail), but 
as with many
analogies it's an imperfect fit. Let's start with the stamp and the 
analogous DKIM-signature.
A stamp instigates a financial transaction: I put a stamp on a letter, 
and that enters me into
a contract that the post office will deliver the mail. They are 
*contract* bound to do so
since the service offered is "guaranteed delivery". A DKIM-signature on 
the other hand
is not even a contract between the originator and the signer -- they can 
be independent
entities through and through. Nor does a signature place any transport 
level responsibility
on MTA. As with all email, it's best effort even if the effort placed on 
delivery is pretty
substantial.

So signature expiration (or signatures with missing keys, etc) should 
not be thought
of in terms of "guaranteed delivery" of the post office, but instead the 
best effort of
internet mail. If the email doesn't get filed into a box and put into an 
attic, the signature
may be helpful in deciding its ultimate delivery disposition. If it 
does, well, you're
going have to revert back to other --older -- methods to determine that 
dispostion.

       Mike

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 21 Apr 2006 11:06:22 -0400

----- Original Message -----
From: "Sandy Wills" <[email-masked]>
To: "DKIM Mailing List" <[email-masked]>

> box of old letters that never got delivered.  Your grandmother's letter

There is an exactly a movie plot based on the similar premise :-) In this
case, a WW II soldier lost love letter and married proposal (with a ring in
letter) to his sweetheart going unanswered because it fell behind a shelf at
the post office. Although living in the same town,  the two bitter people
went their separate married lives for the next 30 years.  His son and her
daugther fell love but the bitter parent history kept them apart. During
remodeling of the old town post office, the lost letter/marriage proposal
(with ring) was found and delivers it resparking an old love. In this case,
the love between them never did expire but both recognized it was too late.
However, their kids were blessed to marry now. :-)

> first.  I guess that's okay.

Well, IMV, the main issue or analogy would be if the user aware that it even
existed?

Maybe it was delivered.  Maybe it wasn't lost.  Maybe it was just a matter
of not checking your mail box frequently.    The love story could be an
American soldier in Iraq and his sweentheart using hotmail.com as a central
place to send love emails.  But for some reason, she doesn't go to
hotmail.com offer enough to login and read her new mail.  Hotmail.com I
think has 30 day inactive limit.    This is not unique.  For our own
software, one of our top support questions is how to purge old or inactive
user accounts.  So it is real possibility.

In fact, we have in our options:

    Days to keep received mail: ____ (default infinite)
    Days to keep unreceived mail: ____ (default infinite)

We will have to rethink about what DKIM expiration means here now. Could it
be used to accelerate the maintenance?   Certainly, DKIM is not going to
trump the 25+ years time engineered, existing operations.  DKIM or no DKIM,
mail can go unreceived and lost.

Also keep in my that USERS have no control of server policies. This concepts
and issues are well documented in RFC 2449 and RFC 1939.  In fact, in
Outlook, if you hit F1 on the "[X] Leave mail on server" option it will
clearly tell the user that this feature may not be honored by the backend
mail server.

Which bring up this point, Roaming users support is a feature, not a Right.
Imagine the user on vacation picking up his mail on one machine, but no
longer is able to pick it up from his mail work/home machine.  A real
possibility.

> Am I out to lunch here, or am I making sense?

In my view, in the end, when it is all said and done, people creativity will
take hold and will inevitably begin to see the expiration tag for various
applications, including possibly helping the aging process and/or Message
Expiration processes.

But overall, these are all implemention considerations.  I don't think the
specs should mandate it, but only to define it and suggest that an
expiration is onsidered invalid by the domain.

> way, you have to have the key to test it, just the question of which

Right.  Defining the timestamp is important.  I believe it should be
generically described as the transaction reception time - the time it
arrived at the host system, not the time it was actually verified or
received by the user.

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

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 21 Apr 2006 08:33:54 -0700

At 6:09 AM -0700 4/21/06, Michael Thomas wrote:
>a large rathole.

"can participate" and "can participate as well as MTAs" are very 
different things.

>There many structural impediments with them reliably
>unfriendly ways. Like sucking the attachments into a database and regenerating
>the mime on output to the MUA.

If this is true, then wouldn't most MUAs fail to work with OpenPGP 
and S/MIME messages? Or are you saying that the MDAs munge the 
headers particularly hard? We know that some MUAs are useless with 
OpenPGP and S/MIME, but that most work fine.

>For a pretty large class of MUA/MDA

Pointers to tables of these bad combinations would be really useful.

>On the DKIM side, however, if we define that MUA's can verify at all,

draft-ietf-dkim-base-01.txt very clearly defines that in many places.

>we
>will verify the message within reasonable transit time, and store 
>the *results*

Fully disagree. MUAs can do their best to validate well, and we can 
suggest how to do that, but we cannot mandate it.

>1) MUST receive email in a form whose transformations fall within 
>the acceptable set of

How could we measure that, much less enforce it? Some MxAs will work 
fine with one set of messages and break with a different set.

>2) MUST perform the verification within the "transport window", 

How could we enforce that with an MUA? Obviously, it would try to 
verify immediately on receipt, but an MUA cannot be forced to 
download mail when the computer is off. For that matter, an MTA 
cannot do it either. You are defining a system, not an MxA.

>3) MUST store the results of the verification process if results of 
>the verification process

How would the MxA know that the results would be used by a later 
process? Are we going to create a protocol for the later process to 
tell the upstream MxAs that they need the verification results? (The 
latter question is meant to be humorous....)
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Sandy Wills <[email-masked]>
Date: Fri, 21 Apr 2006 11:42:50 -0400

(previous notes snipped; this here is my point...)

Hector Santos wrote:
>  generically described as the transaction reception time - the time
> it arrived at the host system, not the time it was actually verified
> or received by the user.

    Exactly what I'm trying to say.  The discussion seems to have
condensed around deciding which "reception time" is relevant, which, to
me, misses the whole purpose of the task at hand.  Who cares, in
sender-authentication terms, when the email is received, tossed, read,
or replied to?  What is relevant, is when the post was _sent_, and
whether or not _that_ timestamp is before or after the expiration timestamp.

    Or am I missing the whole point?  Exactly what problem is DKIM
spostabe solving, here?  As I read it, the WG description on
www.ietf.org says that the WG is about helping people figure out where
an email came from.  For that, _only_ the timestamps around the
originator's initial transmission, and the originating domain's release
into the jungle, are relevant.

-- 
Unable to locate coffee.
Operator halted.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 21 Apr 2006 08:51:31 -0700

I think you've got this turned completely inside out. I'm not trying to 
say what an
MUA MUST do. I'm saying that we should define the conditions under which 
DKIM
signature verification is supposed to work. This may work for some 
MUA's, and it
may not. If an MUA can meet those conditions and find DKIM verification 
useful,
by all means. But please don't come back and say that DKIM is broken 
because it
requires temporal, and other conditions that DKIM was not designed to 
support.

more:

Paul Hoffman wrote:
At 6:09 AM -0700 4/21/06, Michael Thomas wrote:

> If this is true, then wouldn't most MUAs fail to work with OpenPGP and 
> S/MIME messages? Or are you saying that the MDAs munge the headers 
> particularly hard? We know that some MUAs are useless with OpenPGP and 
> S/MIME, but that most work fine.

No, as I understand the problem these message stores save the attachments in
a database and regenerate the message in the mapi/pop/imap stage to the MUA.
The relationship between the input and output may be completely dissimilar
which causes DKIM signatures to fail. PGP and SMIME work because they
are attachments and assumedly the message store doesn't change them.
AFAIK, both Exchange and Lotus Notes do this. There may be others.

> suggest how to do that, but we cannot mandate it.

I'm not mandating anything. Just describing the necessary pre-conditions 
for it
to work in an MUA.

> fine with one set of messages and break with a different set.

No enforcement. "if you want this to work, these are the preconditions 
you must
insure".

> verify immediately on receipt, but an MUA cannot be forced to download 
> mail when the computer is off. For that matter, an MTA cannot do it 
> either. You are defining a system, not an MxA.

No enforcement. "if you want this to work, these are the preconditions 
you must
insure".

> latter question is meant to be humorous....)

We've already been talking about the Auth-Results, but that's a specific 
instantiation of
that data. There are many more possibilities, some that don't require 
any standards work
at all, and some that might. For -base, we can be value about this and 
just couch it in
terms of "storing it locally" or somesuch and defer any of this talk to 
a later date.

       Mike

---

From: John Levine <[email-masked]>
Date: 21 Apr 2006 15:55:29 -0000

>IMO, the problem here saying that MUA's can participate in
>verification is a large rathole.

Maybe, but it's also a rather important usage model and we dismiss it
at our peril.  Partly that's because it'll slow down adoption, partly
it's because people will do it anyway regardless of what we say.

>acceptable set of modifications as defined in -base-nn (eg, canon, l=)

Right.  Fortunately, anything that picks up mail with POP or IMAP
should be OK.  And we don't have to spec that -- if the delivery
process smashes the mail, the signature will break regardless of where
in the chain the smashage happens.

>2) MUST perform the verification within the "transport window", 

Sorry, no, we're back to a previous argument.  If someone goes away
for two weeks, and comes back and picks up his mail, his MUA is going
to check the signatures regardless of how many MUST NOTs you try to
put in the spec.  

In the typical case where the user gets all his mail from a single
known-friendly POP server, it's easy enough to pick the delivery date
out of the top Received: header to see when it was delivered.  Even if
it's been a while, the incremental security risk of checking a two
week old signature versus a one week old signature is pretty puny
compared to the presumably large benefit of verifying that a message
was signed.

I still don't understand the point of trying to prevent people who
don't read their mail every day from using DKIM.

>verification process will be used for some later process

Honestly, that's none of our business.  Maybe they prefer to cache the
key and rerun the verification later, or something else we haven't
thought about.

So anyway, here's two concrete suggestions:

a) The spec should say that DKIM is intended for securing messages in
transit rather than messages in an archive, and leave it at that.  In
particular, I realize that a week is a practical limit for message
transit, but I haven't seen any cryptographic justification to limit
signature lifetimes to a week rather than an hour or a month.

b) It'd be a good idea to discourage people from reusing a selector
with a different key.  If you change the key, change the selector, and
don't just alternate two selectors every month with a new key every time.

R's,
John

---

From: Mark Delany <[email-masked]>
Date: Fri, 21 Apr 2006 16:04:18 +0000

> "can participate" and "can participate as well as MTAs" are very 

And what of the future? If DKIM is successful, I would expect that the
ability of MUAs to participate will increase over time as MTAs and
LDAs learn about DKIM.

Mark.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 21 Apr 2006 09:13:02 -0700

At 8:51 AM -0700 4/21/06, Michael Thomas wrote:
>I think you've got this turned completely inside out. I'm not trying 
>to say what an
>MUA MUST do. I'm saying that we should define the conditions under which DKIM
>may not. If an MUA can meet those conditions and find DKIM 
>verification useful,
>by all means.

Ah, good! Sorry for misunderstanding your earlier message.

>But please don't come back and say that DKIM is broken because it
>requires temporal, and other conditions that DKIM was not designed to support.

I promise I won't. :-)

---

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

On Apr 21, 2006, at 6:09 AM, Michael Thomas wrote:

>
> IMO, the problem here saying that MUA's can praticipate in  
> verification is a large rathole. There many structural impediments  
> with them reliably verifying signatures. For one, many MDA's  
> torture messages in very DKIM unfriendly ways. Like sucking the  
> attachments into a database and regenerating the mime on output to  
> the MUA. For a pretty large class of MUA/MDA mating, it's my  
> understanding that trying to get this to work is pretty much
> a fools errand.

While there are limitations to this approach, a subset of messages  
survive these rigors.  Transactional messages can still obtain  
differential handling at the email viewing application within a  
listed set of providers.  It would be foolish to expect all message  
types survive, or that all MDAs are DKIM friendly.  The goals for  
this approach are different.  Benefits can be found without  
deployment of DKIM related filtering at the providers.  Filtering  
also has limitations, as filtering tends to be reactive.  DKIM at the  
MDA has value.  DKIM when the message is first being viewed has  
value.  Each offer different advantages and disadvantages.

> On the DKIM side, however, if we define that MUA's can verify at  
> all, we need to exactly qualify what that MUA is to match the  
> general expectation we place on MTA's and MDA's: that they are  
> connected and that they are will verify the message within  
> reasonable transit time, and store the *results* of the  
> verification for later use if necessary (ie, it for display  
> purposes). If they won't or can't do those things, then they aren't  
> a DKIM-verification-capable MUA.
>
> the acceptable set of modifications as defined in -base-nn (eg,  
> canon, l=)

Of course.

> 2) MUST perform the verification within the "transport window",  

The desired change to the base draft was to move the key retention  
recommendation to a BCP.  Indicate within the base draft the key  
retention interval assures protection over the expected message  
transit period.  When the sender desires that this period allows  
verification when first viewed, this interval may need to consider  
typical variations seen over this transport.  In the fullness of  
time, global statistics will become available.

> the verification process will be used for some later process

A viewer may log these events, but should not predicate assurances on  
less trustworthy result notations.  Using untrustworthy results would  
be foolish as well.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Fri, 21 Apr 2006 10:05:46 -0700

> less trustworthy result notations.  Using untrustworthy results would  

Security is rarely a binary problem, and this is no different. 
Verification results that I put
in a log or a database --- where's the problem here? Markups in the 
message store like flags
and other such things -- where's the problem here? We don't need to drag 
in Auth-Res here
especially since it's not in scope.

       Mike

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 21 Apr 2006 13:13:17 -0400

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

>     Or am I missing the whole point?

Sent implies receive.

So overall, the debate is the design for where and who is going to validate
the message and knowing where tells you when.

    MUA1 --> MSA/MTA ---> MDA --> MFA ---> MUA2

User MUA1 sends mail this his ISP (MSA), and the ISP's router (MTA) sends it
to the recipient's host at MDA who receives it. The AVS checker at MFA
passes it and saves its for MUA2 to pick or read.

Where is the DKIM signer?  Where is the DKIM verifier?

DKIM is being modeled mostly for a MDA verification concept, but it could
also work at the MFA and/or MUA2.

You have three different times:

     MDA -  Transaction received at current time T1
     MFA -  Message Accepted, Queued and analyzed at current time T2
     MUA -  Message saved and picked up at current time T3

What's common between them is the timestamp in the required 2822.Received:
header added at the MDA.  All MDAs must add this.

This timestamp would be the current time T1.  T2 would be greater, and T3
will be greater.  So using T2 and T3 increases the potential false positive
expirations.

To make it work right, with lower false positives, the MFA and MUA should be
using the 2822.Received: timestamp.

I don't see it as a big deal, but some indicated that they might be trouble
reading or parsing the timestamp from the 2822.Received.

---
Hector

---

From: Michael Thomas <[email-masked]>
Date: Fri, 21 Apr 2006 10:43:58 -0700

John Levine wrote:

The model that I think is far more likely is a signing MUA. At least
that's the

model _I_ want for myself. Trusting DKIM verification to MUA's given

the vagueries of transit and unhelpful message stores seems... well...
not

a great idea to me, but if it works for some people great.

Right, this entire subject seems like it ought to be part of the BCP.
The -base

document should probably mention as tersely as possible that
verification in

MUA's may work in certain relatively narrow circumstances, and that
widening

the scope is a non-goal.

So what? Nobody's saying that they can't try. Nobody's saying that it
will be

guaranteed to work either. Nor will we be saying that.

Because the signatures and selectors are not intended to make long term

assertions. If I remove my selector from DNS before you get around to
verifying

your mail, tough. That's not the problem we're trying to solve for.
Have your

MDA or something else do it for you if you want reliability.

The only thing I'm trying to reinterate here is signatures/selectors
are here

today, gone tomorrow; store it or lose it.

I believe that's already in the normative language of the draft.

Mike

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 21 Apr 2006 13:50:22 -0400

----- Original Message -----
From: "Michael Thomas" <[email-masked]>
To: "DKIM Chair" <[email-masked]>

> verification is a large rathole.

+1.  The standalone DKIM-ready MUA authors have all the information they
need (2822.Received: to get the MDA reception time).

They will have to tell users to frequency mail checking makes their software
work better, and they will also have to be aware that the mail between MDA
and MUA could break signatures and/or be converted/transformed messages.

> There many structural impediments with them reliably verifying signatures.
> For one, many MDA's torture messages in very DKIM unfriendly ways. Like
> sucking the attachments into a database and regenerating the mime on
> output to the MUA. For a pretty large class of MUA/MDA mating, it's my
> understanding that trying to get this to work is pretty much a fools
errand.

+1.  We fall in this class. Users have Preserve MIME email options defining
how mail is converted into local format vs kept in raw MIME format.
Text/ANSI/VT100 (telnet) device users use the non-preserve format.  Web
users or POP3 users may use either/or, some turn it off to remove all HTML
based security issues, etc.

>From my standpoint, I might see a design consideration:

    [X] Preserve MIME
        [X] Always for DKIM signed messages

and we can do this even with our full DKIM support. Just alittle something
for the MUA maybe.

>    acceptable set of modifications as defined in -base-nn (eg, canon, l=)

+1. This is basically saying if a DKIM-Signature: exist, then it needs to
comply.  No signature, it doesn't matter.

> 2) MUST perform the verification within the "transport window",

If not considering MUAs, this part of the retention time is ok since it
covers SMTP retry strategy recommendations.   But if time for MUA is going
to be considered, then 7 days is probably too short.

>    verification process will be used for some later process

+1.

---
Hector

---

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

----- Original Message -----
From: "John Levine" <[email-masked]>

> to check the signatures regardless of how many MUST NOTs you try to

Any MUA DKIM-Ready software using the current time is going to quickly
slammed and classified as buggy, broken software.  The authors will figure
out in their alpha 0.00a version that the top 2822.Received: timestamp from
the ISP is the proper time to use. Not the current time.  Then it wouldn't
matter how long their non-pickup stay is.

---
Hector

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 21 Apr 2006 11:52:45 -0700

At 2:08 PM -0400 4/21/06, Hector Santos wrote:
>slammed and classified as buggy, broken software.

You are free to do such slamming. Others won't.

>Stephen will propose text.

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

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 21 Apr 2006 17:02:40 -0400

----- Original Message -----
From: "Paul Hoffman" <[email-masked]>

> You are free to do such slamming. Others won't.

Actually its not my style, but you darn know well who would be the first to
use, non-stop, cliches such as "Fix your Software".

I'm pretty confidence it won't get to that point though. Authors will
clearly see the issue once they run into their first false positive.

> Seems pretty clear to me...

What is clear Paul?  MAY is your path of the least resistance?  You know, I
am not convince you understand this issue in its entirety, atleast I don't
see you do.

Anyway, the goal was accomplished. The current time only semantics was
functionally and technically incorrect and that was changed to allow a more
reliable time that would benefits all verifiers.  Job was done.

Proof:

    If the current time presumed to be correct at point 1, it
    would therefore be fundamentally incorrect to use a newer
    current time at point 2 and expect to always get the same
    result in a time comparison logic.

Paul,

The current time is fine for instant dynamic, on the spot, verification
concepts, AKA hooks, plugins, shims, callouts, whatever you prefer to call
it.  By dynamic, it means the moment you get the transaction from the
outside world.

But once you move away from instant dynamics concepts, there is only one
current RFC 2821 SMTP standard to pass the near current time/reception time
with an exact non-ambiguous ABNF Received: header.

>From RFC 2821:

4.4 Trace Information
    ...

   Time-stamp-line = "Received:" FWS Stamp <CRLF>
   Stamp = From-domain By-domain Opt-info ";"  FWS date-time

      ; where "date-time" is as defined in [32]
      ; but the "obs-" forms, especially two-digit
      ; years, are prohibited in SMTP and MUST NOT be used.

Unless you wish to propose a new 2822 header to pass a easy to parse
timestamp, which seems to me to only objective, it seems pretty clear to me
the logical  timestamp to use is the network trace reception header.  For
SMTP, that's the
Received header:

---

From: Eliot Lear <[email-masked]>
Date: Sat, 22 Apr 2006 06:13:38 +0200

Sandy Wills wrote:
> 1941.  

I love analogies, so let's extend this one a bit.  If her daughter
received thousands upon thousands of pieces of junk mail, some of which
used fake postmarks to gain attention, others of which use her
grandmothers' name, how would her daughter even know that the letter was
real or worth her time?  If someone thought she would open it, then
they'd mimic that behavior as best they could so that their junk could
get read.

On the other hand, I think only experience is going to dictate good
practice here.  I doubt I would want to yank my keys for a message only
seven days after transit.  I suspect I'd want people to be able to
verify my messages for several months, if possible.

And one of the reasons I say this is that I'm not comfortable with a
secure means of communication between then POP/IMAP server and the MUA,
and so again I think some experience is needed, as well as some
additional extensions.  Many of the schemes used require stripping of
headers on "final delivery" or upon entry into the recipients'
administrative domain.  I'm not a fan.  An MUA needs something more
concrete.

Anyway, I think we'll get there based on our experiences.

Eliot

---

From: John Levine <[email-masked]>
Date: 22 Apr 2006 06:08:24 -0000

>verify my messages for several months, if possible.

What Eliot said.  At this point, we have only hunches about signature
and key lifetimes and anything else related to the pragmatics of using
DKIM.  So the only sensible approach is to leave the hunches out of
the spec, and write some BCPs once we have enough experience to tell a
BCP from a WCP.

R's,
John

---

From: Sandy Wills <[email-masked]>
Date: Sat, 22 Apr 2006 08:31:29 -0400

(Thanks to you, John, Hector, and the others for helping.  I think I 
understand a little better where you are going, now.  I'll let you know 
when I know everything and have solved all the world's problems.)

> they'd mimic that behavior as best they could so that their junk could

Well, yeah, that's the reason that the WG was formed - to build one of 
the links in a chain of verifiability.  65 years ago, a letter cost too 
much for undirected mass mailings.  I'm willing to pay a penny a post 
for email, (maybe it could pay for IETF meetings?), if it means that 
spam is no longer economically viable.  Again, what you guys are trying 
to do is a necessary step in _that_ direction, too.  Something to think 
about, if you have religious problems with making all people pay for email.

> verify my messages for several months, if possible.

    That makes sense.  If you post a message today, it should be 
verifiable for several months, at least.  Years would be nice, if key 
storage isn't a problem (Don't think so, as data storage costs seem 
determined to keep going down.  If that trend is linear, the HD 
companies will be paying me to take their drives, in a couple of years).
    At the same time, the key should also expire such that _new_ mail 
should not use it after [some as-yet-undetermined time].  The "Best if 
used by" milk carton analogy (credit to whoever that was, sorry!) seems 
to fit very well, to me, although it's more like "We put a time-release 
poison in this stuff.  REALLY don't drink it after this date."  Which 
way it goes depends upon how painful key generation and propagation are, 
I guess.

-- 
Unable to locate coffee.
Operator halted.

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 22 Apr 2006 09:20:41 -0400

The Milk Carton Analogy was good, but there is a slight difference when it
comes to (DKIM) mail.

The problem with the milk analogy is that the expiration date is a shelf
life concept. To the store, it is the date it must remove the cartons from
the store shelves. To the consumer, who brought it days or weeks before, it
is probably not a good idea to keep and use the milk on or after this date.

However, when the MILK was used, opened by the user it is the same as the
message being read and already verified as good (milk) at the moment he
first opened it to read (drink) it.

That is what is most important. Is the milk good when you first open it?

So if MAIL was read or received by the user, the concept of expiration
really should not apply anymore. This was like Dave Crocker's excellent "Car
in Intersection, Light Changing to red" analogy.  Are you support to stop
driving because the light change red when you are already crossing it?

A signer might want you to avoid the meaning of the message, but it was
already received, verified and validated.

In other words, the mail presentation software can show this:

      Today Date: April 22, 2006
      This message was received and validated on April 16, 2006.
      However, it is now considered stale.

I have a hard time seeing a verifier at the MUA level going to continually
try to validate the signature, over and over again every time you want to
reread the message.

So it was a good analogy, but doesn't 100% apply to mail once the mail is
received and validated before it expired.  The mail is still readable. It
was safe the first time you read it.  Unless the message is a nuclear bomb
that will hurt you if you continue to read it, I just don't see how it
applies at the USER level.

That said, I already mentioned how I see it apply at the backend or system
level.  I can easily see how we might want to add a system option to use
expired DKIM messages as part our mail maintenance, archiving system
allowing the operator to use this additional piece of information to help
the backend software to purge the message from the system.

But while it is still alive and available, once you read it, at best, the
presentation software could or might be fancy enough to tell you that it has
already verified but now expired message.

Anyway, that's my view.

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 24 Apr 2006 07:28:41 -0400

----- Original Message -----
From: "Douglas Otis" <[email-masked]>
To: "Michael Thomas" <[email-masked]>

> time, global statistics will become available.

Doug,

SMTP is now and still going to be primary method of transport, and even if
there other non-SMTP transport methods, new or old,  the vendors are still
going to include SMTP.  Since SMTP has a recommended guideline of 4-5 days
to allow for a transport sending strategy that nearly all systems follow,
this means there is an inherent minimum key retention time for DKIM signers.
The DKIM-BASE recommended seven days is sufficient to safely cover the
transport and then some.

Besides, DKIM needs signing to work. Signers will be scratching their head,
"is this forever?" "Can I remove it without damaging messaes still in the
transport?"  "How long should stale keys remains?"  "Hmmm, it says 'expected
message transit period.  Well, we are only using SMTP and SMTP has a 4-5
days limit, so it has to be atleast 4-5 days plus some safe tolerance. Lets
go with lucky seven!!"

Its a chicken and egss situation.  You got have some base value to begin
with and if during practice, that proves to be too short and it needs to be
adjusted, then a BCP will help.   If we want to generalize it, then the BASE
should atleast have a Appendix table or something showing the "Minimum
Expected Message Transits Periods per Tranport Protocol."

hmmmmmm, lets try that:

Appendix XX

    Minimum Expected Message Transit Periods Per Protocol

    SMTP     4-5 Days
    HTTP     ???
    IMAP     ???
    OTHER    ???

---

From: Douglas Otis <[email-masked]>
Date: Mon, 24 Apr 2006 09:33:38 -0700

On Apr 24, 2006, at 4:28 AM, Hector Santos wrote:

> SMTP is now and still going to be primary method of transport, and  
> even if there other non-SMTP transport methods, new or old,  the  
> vendors are still going to include SMTP.

Protections afforded by DKIM include transports beyond SMTP that  
extend from the originator to the recipient, as noted in the charter,  
threat, and base draft.  While delivery failure retry within for SMTP  
is a component of a key retention requirement, a greater period of  
retention may be necessary to accommodate other transit latencies.   
There is no certainty where in the transport sequence a message is  
signed by the originator, or where in the sequence verification of  
the signature is important to the recipient.  Short key retention  
will not offer protection for common circumstances involving the  
transit from the originator to the recipient.  SMTP delivery failure  
retry is not the only circumstance that warrants consideration for  
key retention.  Is there a reason why key retention should not  
consider latencies related to originators and recipients over other  
transports?

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 24 Apr 2006 13:02:11 -0400

----- Original Message -----
From: "Douglas Otis" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: "DKIM Mailing List" <[email-masked]>
Sent: Monday, April 24, 2006 12:33 PM
Subject: Re: [ietf-dkim] DKIM verification actors

> retention may be necessary to accommodate other transit latencies.

I label these practical delays as:

    t1 - Transit (MTA -> MDA)
    t2 - Processing (MDA/MFA processing)
    t3 - Pickup (MUA pickup from backend msg database)

t1 is well defined for over 20+ years.

t2 depends on the big the receiver site is. Scalarability and message
queuing places a tremendous factor on how dynamic operations are
implemented.  I will venture this t2 delay is less than 1 day and approaches
zero the smaller the site is:

        size of receiver system ------>
        0 < t2 <  1 day (SWAG)

The only true variable is t3, which is the time that the mail was already
received and processed by the system, possibly transformed, posted for user
pick and the MUA finally picks it up and/or Logins into the host and reads
the mail on line.

I agree with you, t3, is an important consideration IFF there is no design
consideation at the backend.   How big that consideration is directly
proportional and largely dependent on a site's user base ergonomics and
behavior with mail pickup and/or login frequencies.   In my view, if you are
writing a DKIM-ready MUA, you have no choice but to make sure it also
supports a non-DKIM-aware backend.

> transit from the originator to the recipient.

So if a domain realizes this, why would they use a short retention time?

> SMTP delivery failure retry is not the only circumstance that
> warrants consideration for key retention.

It is the only absolute minimum we have based on SMTP standards, BCP and
legacy operations.   Why would a Key Management software writer ignore this
obvious 4-5 day (t1) transit delay?

> Is there a reason why key retention should not consider latencies
> related to originators and recipients over other  transports?

No, which why I think this seems to be a mountain out a mole hill issue.  If
a domain sees a problem with its signatures, then only he can decide how
long the key retention issue and if a ISP/ESP sees complains from the user,
there is not much he can do but to tell them:

             - Not our problem. We are not DKIM aware.
             - Check in more often.
             - Talk to your MUA vendor.

You are not going to cover ALL belated t3 period (MUA) situations unless
there are specific DKIM helper technology that specifically addresses this
issue.  But this also requires DKIM-awareness intelligence on the backend.

Here is a possible DKIM "Helper" solution I call:

            "Partial DKIM Verifier Support using a
                  DKIM-Received Trace Header"

http://isdg.net/public/ietf/drafts/draft-santos-dkim-rcvd-00.txt
http://isdg.net/public/ietf/drafts/draft-santos-dkim-rcvd-00.html

This is a possible solution that will help this particular issue and also
offer a migration path for DKIM implementation wishing to get started.

---

From: Jon Callas <[email-masked]>
Date: Tue, 25 Apr 2006 14:17:21 -0700

> same time slot. Any objections/thoughts?

I have an objection and a thought.

It's an ugly time for people on the left coast of the US who aren't  
morning people. Furthermore, there are several groups I work with who  
seem to think that approximately that time is a good time for a concall.

The reason we in the IETF do things by mailing lists is to be gentle  
on people in different time zones and so on. How about if we do that?

	Jon