Subject: [ietf-dkim] Proposal: get rid of x=

From: Paul Hoffman <[email-masked]>
Date: Thu, 6 Apr 2006 17:12:22 -0700

Greetings again.

---------------------
Summary:
Remove the x= tag from the base spec because it conflicts with some 
of the purpose of DKIM and adds unneeded semantics.

---------------------
Rationale:
DKIM permits a signing domain to assert responsibility for a message. 
Saying "I only take responsibility for sending the message until this 
time, and then I don't take responsibility even though I previously 
took responsibility" makes little sense in the real world. Note that 
the informative note only says what x= is not. Leaving x= in can also 
lead to silly states.

---------------------
Changes:

In section 3.5, remove the x= section. Also in section 3.5, remove 
"x=1118006938;" from the example for z=.

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

---

From: Michael Thomas <[email-masked]>
Date: Thu, 06 Apr 2006 17:27:12 -0700

Paul Hoffman wrote:
> Greetings again.
> 
> ---------------------
> Summary:
> Remove the x= tag from the base spec because it conflicts with some of 
> the purpose of DKIM and adds unneeded semantics.
> 
> ---------------------
> Rationale:
> time, and then I don't take responsibility even though I previously took 
> responsibility" makes little sense in the real world. 

Is there *any* signature by way of its underlying credential that
doesn't have a lifetime?

DKIM is intended to have a transport duration lifetime, eg about
2 weeks. It is not intended to be used for archival purposes or
anything else like that. Like it or not, rolling keys is hard for
a significant set of people who might benefit from DKIM. Saying
that the only way that they can limit their exposure from otherwise
immortal signatures is by revisiting their DNS every few weeks is
unnecesarily burdensome on those operators. x= is a cheap way to
achieve that goal.

> Note that the 
> informative note only says what x= is not. Leaving x= in can also lead 
> to silly states.

What states might those be?

		Mike

---

From: John Levine <[email-masked]>
Date: 7 Apr 2006 01:04:58 -0000

>Is there *any* signature by way of its underlying credential that

No, but I don't see any reason that a sender has any great insight
into the likely transit time of a message or the useful lifetime of a
message signature.

>2 weeks.

Quite right.  So we should ditch x= and add a sentence saying that
recipients should ignore signatures older than the longest likely
transit time of a message, typically two weeks.

>What states might those be?

Let's say message A has a signature that uses x= to set a lifetime of
five seconds, and message B has a signature that has a lifetime of
five years.  Have we learned anything useful about either message
other than that the people who signed them don't understand mail
transport very well?  What if the signature time and the expiration
time are equal, or it expires before it was signed?  Do either of
those mean anything?  What should a recipient do?

I can see why someone might want a feature analogous to the usenet
Expires: header to say that the contents of a message aren't
interesting past a given time, but that's not the semantics of x=.

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 07 Apr 2006 02:08:01 +0100

(A message from the in-two-minds department:-)

Michael Thomas wrote:
> Paul Hoffman wrote:
>> Note that the informative note only says what x= is not. Leaving x= in 
>> can also lead to silly states.
> 

I was also wondering about that. I guess that "x=" is a way to make
it crystal clear that this signature is (probably, potentially)
totally worthless in some court case in 5 years time - a v. good
feature (*). It would also help if someone wanted to auto-generate
new signing key-pairs at about the latency with which their DNS
stuff becomes available (but I don't know if that info's available
to the verifier via DNS - is it?). Were we to ask verifiers to
interpret "x=" as guidance, and not as a way in which it MUST
fail a signature, then its optional inclusion may well help some
layer above DKIM.

However, on Paul's side of the argument, it is true that many, if
not most, people recognize that insisting upon X.509 certificates
having to have a notAfter date was a mistake. So, there is a bit of
prima-fasciae evidence that signed-things-with-stupid-expiry-values
are problematic in some cases, though that analogy really holds much
better against the key record and not the signature. To be concrete
about problems-ensuing: I guess if an MUA were DKIM-aware then "x="
creates a dilemma for the MUA programmer in cases where the mail
isn't read until after the relevant time. I also remember trying
to shoe-horn a Kerberos thing into being usable on an extranet - the
clock skew was such a killer that we had to open the window to
ridiculous levels.

Basically, YMMV!

But, facts outweigh opinions: are there specific verifier uses
cases that act upon the "x=" value?

Stephen.

(*) <rant now="y"> If "x=" survives and becomes practically used
by verifiers then I would encourage DKIM implementers who *really*
want their signatures to be worthless at some point in the future
to agree to publish their old private keys a little while after they
are finished with using those private keys. Giving everyone the
means to repudiate old transactions is IMO an excellent way to
prevent a lawyer/<<thing>> from pretending that you meant a
signature to be some kind of pseudo-non-repudiable thing!
</rant>

---

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

Stephen Farrell wrote:
>> Paul Hoffman wrote:
>>
>>> Note that the informative note only says what x= is not. Leaving x= 
>>> in can also lead to silly states.
>>
>>
> to the verifier via DNS - is it?). 

 > Were we to ask verifiers to

I've struggled with that too... for DKIM purposes, it really does
fail to "verify", but so do other situations where you could conceivably
apply some heuristics to glean interesting information despite
"failure". As with the last round, I don't think they belong in the
spec though -- it's not our job to discover or even evangelize
these uses, especially at this point. If we were ever to say anything
about these kinds of things, I'd think that it ought to be part
of a BCP after we've had a fair amount of experience and evidence.

> better against the key record and not the signature. 

Can you expand here? And espcially as it relates to DKIM? And
"stupid"?

 > To be concrete
> isn't read until after the relevant time. 

Yes, but this was a non-goal. We've said all along that it could
be done in an MUA, but not that it was generally a good idea to
put in an MUA since DKIM is intended to have a transport lifetime
relevance. This is just as true with removing selectors. The right
thing here is for a transport agent of some kind to verify the
signatures on the MUA's behalf at transport time and annotate the
message for later MUA rendering operations (hi Murray!).

 > I also remember trying

As the author of rfc 4430, I'm well aware of skew :) What seems
different here is that the affects of opening the window so to speak
don't really seem all that bad. It's not like we're trying to achieve
tight windows so that you can limit your inability to expicitly revoke
(as with Kerberos). Indeed, we already have that ability modulo DNS
TTL's. So the skew only needs to hit the broad side of a barn -- if
you want 2 weeks, then set it to 4 weeks. The gaol here is to not
accrete entropy.

> cases that act upon the "x=" value?

My software checks the x= value and treats an expired message
as a verification failure... nothing complicated.

> signature to be some kind of pseudo-non-repudiable thing!

Isn't this approach patented though?

		Mike

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 07 Apr 2006 15:50:39 +0100

> of a BCP after we've had a fair amount of experience and evidence.

I agree. Does that weaken the argument for keeping "x=" in the
base though? Not sure myself.

> Can you expand here? And espcially as it relates to DKIM? And

Many ca-certs are set to expire in 20+ years which is nonsense.
You can't (easily) put X.509 certs on phones and similar because
the device might stop doing something if the cert expires. What
would have been better would be to make notAfter optional since
there are situations where you don't have any good value to put
there.

But "x=" is currently RECOMMENDED (I assume it means RECOMMENDED
to use, and not RECOMMENDED to implement?) so we're not as bad as
X.509 here.

> relevance. 

True. Maybe the wording on "x=" could make that clearer if it
said that the value is "how long I expect the message to be
in transit" rather than "signature expiration"?

> As the author of rfc 4430, I'm well aware of skew :)

At least the latency on that was less than with pk-init :-)

 > ...
> So the skew only needs to hit the broad side of a barn -- if

True again. But it'll still be a source of validation failure simply
because some verifiers won't have good clocks. I guess its fair to
say that that'll be a small number of badly managed MTAs though.

> as a verification failure... nothing complicated.

You're an extremist then:-)

> Isn't this approach patented though?

Hope not. I really do. 'Cause that'd mean I'd have to pay a
license to show someone the factors of a number:-(

S.

---

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

> base though? Not sure myself.

   I don't think so.

> there are situations where you don't have any good value to put

   Right, but the situation here is not even remotely the same.
   We *want* these signatures to stop working after some period.
   We *don't* want them to be valid in perpetuity. That's certainly
   not the case with a phone certificate.

> to use, and not RECOMMENDED to implement?) so we're not as bad as

   I think it's recommended to use.

> in transit" rather than "signature expiration"?

   You could, but the semantic is more of a "I don't want this
   to be in transit after X". You mentioned NNTP Expires, and
   I think that's a pretty good analogy, though not exact.

> say that that'll be a small number of badly managed MTAs though.

   Right. Kerberos and its clock skew woes largely predate easy access to
   [S]NTP. For mail infrastructure -- not MUA's -- I don't think this is
   a terribly hard problem these days, and screwed up clocks on MTA's
   most likely cause all kinds of other problems for admins -- like
   trying to diagnose why mail at X'oclock didn't get through.

> You're an extremist then:-)

   Heavens, not again.

		Mike

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 07 Apr 2006 16:28:48 +0100

Michael Thomas wrote:
>   to be in transit after X". 

I kind of like that description actually.

And it makes me wonder if the MUST NOT accept is a good idea since
I'm worried that MTA admins won't know what to put there and will
all end up using 2038 which is kind of pointless.

Do MTA admins know what they'd put in there?

>> You're an extremist then:-)
Only kidding!

To be clear: I'm still snugly on the fence on this whole issue.

S.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 07 Apr 2006 08:33:39 -0700

> I kind of like that description actually.

DKIM is about signatures, not transit.

Having a parameter in an RFC2822 header field attempt to specify something 
relevant to RFC2821 transit does not make sense and, at best, won't have any 
effect on transit.

d/
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 7 Apr 2006 08:43:15 -0700

>DKIM is intended to have a transport duration lifetime, eg about

Yep.

>It is not intended to be used for archival purposes or
>anything else like that.

Yep.

So what is the value to giving the signer a tool that can change 
either of those statements? We should, instead say those two things 
in the definition of DKIM, if the WG agrees that these two statements.

>Like it or not, rolling keys is hard for
>unnecesarily burdensome on those operators.

Fully agree.

>x= is a cheap way to

Simply specifying the length of a signature's life in the document 
that defines the signature is much cheaper, and less prone to 
misinterpretation.

>What states might those be?

For example:

The signer has measured the transit time to location A, and it is 
always less than ten seconds. The signing system sets x= to a day to 
be safe. Location A's SMTP server, becomes unavailable due to a 
backhoe incident. The outgoing mail sits on the signer's system for a 
day and a half before connectivity to A is restored. The message 
arrives with an non-verifiable signature, even though the signer made 
a reasonable assumption when signing.

If what the WG wants is signatures whose life is the time of transit, 
we should say that in the protocol definition, not optionally in each 
message.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 7 Apr 2006 08:57:37 -0700

At 8:33 AM -0700 4/7/06, Dave Crocker wrote:
>Having a parameter in an RFC2822 header field attempt to specify 
>something relevant to RFC2821 transit does not make sense and, at 
>best, won't have any effect on transit.

Fully agree.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 7 Apr 2006 09:07:19 -0700

On Apr 7, 2006, at 8:20 AM, Michael Thomas wrote:

>> True. Maybe the wording on "x=" could make that clearer if it said  
>> that the value is "how long I expect the message to be in transit"  
>> rather than "signature expiration"?
>
> You could, but the semantic is more of a "I don't want this to be  
> in transit after X". You mentioned NNTP Expires, and I think that's  
> a pretty good analogy, though not exact.

Unlike a news article, there is some danger this expiry time might  
generate a message bounce when it establishes a basis for refusal in  
a rule-set.  Although these would not be the rules you and others  
would create, a provider may bounce a message as it passes an  
expiration while within their AU.  With an expiry in place, disabling  
the account could be seen as a adequate response to a replay issue.   
A strategy where the signer relies upon message expiration to curtail  
abuse reports will also likely lead to expired messages then being  
refused.

If x= is retained, there needs to be some cautions added about  
handling messages within the AU.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Fri, 07 Apr 2006 12:01:28 -0700

> we should say that in the protocol definition, not optionally in each 

The alternative is to just put normative guidance in the document to the 
effect
that x= MUST be greater than t=+2weeks, and less than t=+2 months or 
something,
and that it SHOULD be set to t=+4 weeks.

I guess I worry a little about codifying an _exact_ number.

       Mike

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 7 Apr 2006 12:09:10 -0700 (PDT)

On Fri, 7 Apr 2006, Michael Thomas wrote:

> effect that x= MUST be greater than t=+2weeks, and less than t=+2 months 
> or something, and that it SHOULD be set to t=+4 weeks.
>

You could make "x" optional and specify defai;t va;ies one may assume
if its not present, but allow sender to override it by actually 
specifying "x" value in the signature.

---
William Leibzon
Elan Networks
[email-masked]

---

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

At 12:01 PM -0700 4/7/06, Michael Thomas wrote:
>Paul Hoffman wrote:
>>If what the WG wants is signatures whose life is the time of 
>>transit, we should say that in the protocol definition, not 
>>optionally in each message.
>
>The alternative is to just put normative guidance in the document to 
>the effect

That is an alternative, but I would ask "why use that alternative". 
Unless x= is compelling, and compelling enough to overcome its 
faults, why even put it in with these suggested knob-settings? I 
claim that it is not compelling, particularly if the document says 
what the purpose of DKIM signatures are.

>I guess I worry a little about codifying an _exact_ number.

As well you should. :-)

---

From: Michael Thomas <[email-masked]>
Date: Fri, 07 Apr 2006 13:18:08 -0700

Paul Hoffman wrote:

> Unless x= is compelling, and compelling enough to overcome its faults, 
> why even put it in with these suggested knob-settings? I claim that it 
> is not compelling, particularly if the document says what the purpose 
> of DKIM signatures are.

I'm confused. If we added the text you initially suggested, the result 
would be
that a receiver would honor the signature forever. Are you saying now that
your original text needs to be amended to have a spec mandated lifetime?

>> I guess I worry a little about codifying an _exact_ number.

Assuming your answer is "yes" above, then that's really what's at issue 
right?
I guess I generally like to hedge against unknown eventualities.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Fri, 7 Apr 2006 13:38:43 -0700

On Apr 7, 2006, at 12:52 PM, Paul Hoffman wrote:

>> The alternative is to just put normative guidance in the document  
>> to the effect that x= MUST be greater than t=+2weeks, and less  
>> than t=+2 months or something, and that it SHOULD be set to t=+4  
>> weeks.
>

Those interested in assuring acceptance of their messages will allow  
an adequate delivery time.  There should be no need to make  
recommendations for the delivery period.

The x= parameter becomes problematic when it allows less than a  
nominal processing time for possible downstream systems, for whatever  
valid reason.  If an MTA is forwarding messages, and these forwarding  
agents are known, then bad actors sending messages to forwarded  
accounts may be delighted to find their messages are subsequently  
rejected due to an expired signature by some down stream MTA. : (

Bounced messages due to an expiry might create a problem worse than a  
replay issue, as the bounce sources would otherwise be considered  
reputable. : (

One protective strategy for the forwarding agent would be to not  
accept messages with less than some period of time remaining.  Of  
course, the downstream system might be doing the same thing,  
thwarting this strategy for avoiding down stream rejections.  The  
converse of not rejecting until some period after the expiration  
suffers the same syndrome.  There does not seem to be a safe  
solution.  Is there a strategy that would be safe?

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 07 Apr 2006 21:53:49 +0100

Doug,

Douglas Otis wrote:
> If an MTA is forwarding messages, and these forwarding agents 
> are known, then bad actors sending messages to forwarded accounts may be 
> delighted to find their messages are subsequently rejected due to an 
> expired signature by some down stream MTA. : (

Is that right? Isn't it rather the case that a bad "x=" value causes
signature validation to fail, which is the same as the message not
having been signed. So a signature expiry failure doesn't mean
message rejection, same as if the signature check failed because
the message was mangled.

Stephen.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 7 Apr 2006 13:29:26 -0700

At 1:18 PM -0700 4/7/06, Michael Thomas wrote:
>>>to the effect
>>>that x= MUST be greater than t=+2weeks, and less than t=+2 months 
>>>or something,
>I'm confused. If we added the text you initially suggested, the 
>result would be
>that a receiver would honor the signature forever.

The receiver *could* honor the signature forever, just as they can 
with an x= tag. But, in doing so, they would be going against the 
semantics of the DKIM signature.

>Are you saying now that

Not at all: I'm saying my original text needs to be amended to add 
the WG's intention of what DKIM signatures are for. (I thought it was 
already there but, after reading the thread and then going back to 
the document, couldn't find it. It must be ingrained in our beliefs, 
but not in our text.)

>Assuming your answer is "yes" above, then that's really what's at issue right?

Correct assumption, but incorrect conclusion. What's "really" at 
issue is whether to have a unneeded tag that can cause problems when 
removing the tag (and replacing it with text about what the protocol 
is for) is better.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Fri, 7 Apr 2006 15:14:13 -0700

On Apr 7, 2006, at 1:53 PM, Stephen Farrell wrote:
>
> Douglas Otis wrote:
>> If an MTA is forwarding messages, and these forwarding agents are  
>> known, then bad actors sending messages to forwarded accounts may  
>> be delighted to find their messages are subsequently rejected due  
>> to an expired signature by some down stream MTA. : (
>
> Is that right? Isn't it rather the case that a bad "x=" value  
> causes signature validation to fail, which is the same as the  
> message not having been signed. So a signature expiry failure  
> doesn't mean message rejection, same as if the signature check  
> failed because the message was mangled.

Signatures may fail for many reasons.  While the desire may be to  
classify all signature failures as no signature, this strategy may be  
altered when confronting the effects of abuse.  An administrator  
might report some percentage reduction in abuse when rejecting  
messages with an expired first-hand signature and note few complaints  
subsequent to adopting this strategy.   A bad actor holding many  
signed messages would be able to continue a sequence of replays until  
the key is removed, long after they lost the account used to generate  
the sequence.  If the signing domain changed keys 2 times a year,  
then an expiry period could affect this abusive activity.  When there  
are few other valid reasons for the expiration of this type of  
signature, this specific failure may receive a high spam score.  The  
spam filter rule-set may cause rejection nevertheless, where  
practical empirical considerations could have greater weight than  
ideals espoused in the draft.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Fri, 07 Apr 2006 15:17:41 -0700

> semantics of the DKIM signature.

What semantics are those? There aren't any others in the draft that I'm 
aware of.
IIRC, the lack of a x= means that there is no expiration.

> Not at all: I'm saying my original text needs to be amended to add the 
> WG's intention of what DKIM signatures are for. (I thought it was 
> already there but, after reading the thread and then going back to the 
> document, couldn't find it. It must be ingrained in our beliefs, but 
> not in our text.)

It's not there because with x= it's configurable by the signer.

> Correct assumption, but incorrect conclusion. What's "really" at issue 
> is whether to have a unneeded tag that can cause problems when 

I'm sorry, just saying that the protocol is for "transport time" is not 
going
to help developers, and is likely to lead to the inconsistencies and 
incompatibility
that you are trying to get rid of. x= leaves it as a decision of the 
signer to determine
what it wants. Letting a receiver just pick a number out of thin air is 
definitely not
what we want -- especially when some dumb receivers would find it 
oh-so-suspicious
that mail didn't get to them in the normal 20 minutes and declare the 
signature
dead.

But I'm still confused: are you saying that your original proposal needs 
work, or
that it's still what you want?

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Fri, 7 Apr 2006 16:56:50 -0700

On Apr 7, 2006, at 1:53 PM, Stephen Farrell wrote:

> So a signature expiry failure doesn't mean message rejection, same  
> as if the signature check failed because the message was mangled.

The bane of DSNs are minimized when MTAs follow consistent rule-sets,  
as SMTP is a store and forward protocol.  Bad actors are notorious  
for exploiting MTAs changing rule-sets.  The DKIM draft unfortunately  
is lax in this respect, where this is especially true with respect  
the implementation of policy.  The DKIM draft has not ensured a  
consistent basis for rejection.  Just the opposite.  The per message  
per second timing of a message expiry appears to be a gift to the bad  
actors, although this exploit could be accomplished employing trick  
DNS servers tracking messages via their key-selectors and returning  
no keys upon a subsequent query from a different address space.

DKIM is an excellent tool for identifying which domain has handled  
the message.  DKIM may also be an excellent tool for exploiting the  
store and forward nature of email.

Delayed acceptance, reporting, and self-revocations causing deletions  
are safer strategies.

--- Optional Reject

3.4.5  Body Length Limits
...
Note that verifiers MAY choose to reject or truncate messages that
have body content beyond that specified by the body length count.

--- Optional Reject

3.5  The DKIM-Signature header field
...
d= The domain of the signing entity (plain-text; REQUIRED).  This
    is the domain that will be queried for the public key.  This
    domain MUST be the same as or a parent domain of the "i=" tag.
    When presented with a signature that does not meet this
    requirement, verifiers MUST either ignore the signature or reject
    the message.

--- What is the prime purpose for expiry?  To act as a fuse?

x= Signature Expiration (plain-text; RECOMMENDED, default is no
    expiration).  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.  The value is expressed as
    an unsigned integer in decimal ASCII.

    INFORMATIVE NOTE:  The x= tag is not intended as an anti-replay
    defense.

--- Treat invalid signatures with suspicion?

6.2  Extract the Signature from the Message

Since there can be multiple signatures in a message, a verifier
SHOULD ignore an invalid signature (regardless if caused by a
syntactic or semantic problem) and try other signatures.  A verifier
MAY choose to treat a message with one or more invalid signatures
with more suspicion than a message with no signature at all.

---  Clearly an invalid signature is to be rejected.

6.6  Interpret Results/Apply Local Policy
...
If the verifying MTA is capable of verifying the public key of the
signer and check the signature on the message synchronously with the
SMTP session and such signature is missing or does not verify the MTA
MAY reject the message with an error such as:

    550 5.7.1 Unsigned messages not accepted

    550 5.7.5 Message signature incorrect

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 7 Apr 2006 20:15:32 -0400

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

> going to help developers, and is likely to lead to the 
> inconsistencies and incompatibility that you are trying to get 
> rid of. x= leaves it as a decision of the signer to determine
> what it wants. Letting a receiver just pick a number out of 
> thin air is definitely not what we want -- especially when 
? some dumb receivers would find it oh-so-suspicious
> signature dead.

The x=tag is the less of DKIM worries.  See the t=y tag:

    // Local Policy:
    // - Watch for Perpetual Testing (t=y) Abusers 
    // - 6 months Default

    if (IsTesting() && TestingDays() > LocalPolicy.MaxTestingDays) {
        WasteBasket()
        return 551;
    }

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

---

From: <[email-masked]>
Date: Sat, 8 Apr 2006 10:07:30 -0400

-----Original Message-----
From: [email-masked] on behalf of Douglas Otis
Sent: Fri 4/7/2006 7:56 PM
To: Stephen Farrell
Cc: [email-masked]
Subject: Re: [ietf-dkim] Proposal: get rid of x=

> as if the signature check failed because the message was mangled.

Policy of the receiving domain is out of scope for what we are doing here.
I may choose to ignore DKIM, reject all unsigned or failed signings or a mixture of both. The document should clearly state that
xs=blah
r=bleh
dkim=string
and what each piece means, no more no less.

thanks,
Bill Oxley

---

From: Eliot Lear <[email-masked]>
Date: Sat, 08 Apr 2006 17:33:25 +0200

Mike,

What's the practical advantage of having x=?  What do I get that I
wouldn't get with simply assuming that verifying a message 2 weeks past
the last received header is probably not such a hot idea?

Eliot

---

From: Douglas Otis <[email-masked]>
Date: Sat, 08 Apr 2006 09:17:35 -0700

> Policy of the receiving domain is out of scope for what we are doing here.

The effect of differing policies is the concern.  Sewer pipes increase
in size to avoid clogs.  The expiry of the message permits a bad actor
to light a precision fuse before dropping their message into the
flushing toilet. The effect of the expiry is that the pipe (allowance)
granted the message reduces at it travels.  When this becomes a problem,
each MTA will want to ensure more than some amount of time remains prior
to expiration.  It will be unpleasant up stream of the clog created by
the different and ever decreasing size pipes.

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 8 Apr 2006 09:53:50 -0700

Greetings again. The following is similar to the earlier proposal but 
adds normative text to the document that obviates the need for x=.

---------------------
Summary:
Remove the x= tag from the base spec because it conflicts with some 
of the purpose of DKIM and adds unneeded semantics; add text to say 
what DKIM signature lifetimes are supposed to be.

---------------------
Rationale:
DKIM permits a signing domain to assert responsibility for a message. 
Saying "I only take responsibility for sending the message until this 
time, and then I don't take responsibility even though I previously 
took responsibility" makes little sense in the real world.

---------------------
Changes:

Add a new paragraph at the end of section 1.1:

A DKIM signature is intended to be verifiable for about the length of 
time of that it would take to transport the message in SMTP; this is 
almost always less than two weeks. The signature is  not intended to 
be used for archival purposes, and verification of the signature 
after this period is not an intended or desired feature of the DKIM 
protocol.

---

From: Arvel Hathcock <[email-masked]>
Date: Sat, 08 Apr 2006 18:06:31 -0500

> wouldn't get with simply assuming that verifying a message 2 weeks
 > past the last received header is probably not such a hot idea?

Parsing and dealing with the value in x= is probably easier code than 
doing the same with a date-stamp from a Received header.

-- 
Arvel

---

From: Michael Thomas <[email-masked]>
Date: Sat, 08 Apr 2006 16:14:51 -0700

> be used for archival purposes, and verification of the signature after 
> this period is not an intended or desired feature of the DKIM protocol.

This text doesn't seem to be able to make up its mind if it's informational
or  normative. It needs to be normative. Which is why x= is better since
we can recommend something squishy like around 2 weeks, but be able
change it in the future if needed.

       Mike

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 8 Apr 2006 16:27:22 -0700

At 4:14 PM -0700 4/8/06, Michael Thomas wrote:
>>A DKIM signature is intended to be verifiable for about the length 
>>of time of that it would take to transport the message in SMTP; 
>>this is almost always less than two weeks. The signature is  not 
>>intended to be used for archival purposes, and verification of the 
>>signature after this period is not an intended or desired feature 
>>of the DKIM protocol.
>
>
>or  normative.

I have no idea what you mean. It is normative.

>It needs to be normative.

Fully agree.

---

From: Michael Thomas <[email-masked]>
Date: Sat, 08 Apr 2006 16:32:27 -0700

Paul Hoffman wrote:

>>> of time of that it would take to transport the message in SMTP; this 
>>> is almost always less than two weeks. The signature is  not intended 
>>> to be used for archival purposes, and verification of the signature 

"for about" and "almost always" are normative? This is not implementable 
or testable
as written.

       Mike

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 8 Apr 2006 17:48:37 -0700

At 4:32 PM -0700 4/8/06, Michael Thomas wrote:
>>>>A DKIM signature is intended to be verifiable for about the 
>>>>length of time of that it would take to transport the message in 
>>>>SMTP; this is almost always less than two weeks. The signature is 
>>>>not intended to be used for archival purposes, and verification 
>>>>of the signature after this period is not an intended or desired 
>>>>feature of the DKIM protocol.
>>>
>>>
>>>
>"for about" and "almost always" are normative?

Yes. They specify the semantics of DKIM signatures in a way to which 
implementers are fully expected to adhere. They are not informative 
or optional. They are prescriptive.

We cannot remove the "for about" because that would lead to a silly 
state, namely that the verifier would have to verify the signature 
before the length of time it took to deliver the message. I say "for 
about" to indicate that our intention is that it will be verified 
soon after delivery.

We cannot remove "almost always" because someone will come up with a 
pathological example of mail that was held more than two weeks (I 
think I heard that some systems did this after the devastating 
tsunami of 2004).

Yet the semantics are clear: the intention is that the protocol will 
be used this particular way.

>This is not implementable or testable
>as written.

True, but "testable" is not the same as normative, at least in the 
IETF sense (which I fully admit is not defined in any RFC I could 
find). Having said that, if anyone has a suggestion of how to tighten 
the wording to make it seem more definitive without forcing policy on 
the verifier, that would be great.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Sat, 08 Apr 2006 18:00:31 -0700

> the last received header is probably not such a hot idea?

Derivative question:

    What's the practical advantage of having x=?

If the parameter is not present, then a validation might be attempted after the 
key is no longer valid.  So what?  Either way, after that time, the validation 
fails.

So what is the important, incremental benefit of this parameter?

d/
-- 

Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Sat, 08 Apr 2006 18:06:23 -0700

Paul Hoffman wrote:

> implementers are fully expected to adhere. They are not informative or 
> optional. They are prescriptive.

As a developer, I haven't a clue as to what would satisfy this kind of
normative requirement.

> the verifier, that would be great.

Normative text that leads to different --and nearly arbitrary -- 
implementation
decisions is not my idea of good normative text.  The problem here isn't the
wording, it's the intent of trying to be normative with informative text.

       Mike

---

From: John Levine <[email-masked]>
Date: 9 Apr 2006 04:03:13 -0000

>doing the same with a date-stamp from a Received header.

I think we all agree that t= is useful to have an easily parsed version
of the time the message was signed.

R's,
John

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 9 Apr 2006 05:35:47 -0400

----- Original Message -----
From: "Dave Crocker" <[email-masked]>

> So what is the important, incremental benefit of this parameter?

Although I personally don't see any compelling need, other than maybe
assisting verifiers to further minimize unwanted/undesireable mail at the
transport level, I see a few things, incrementally (future) wise at the
"service" level.

1) Contributing to the AU mail maintenance, archiving policy.

For example, we can probably add a new option to our mail
maintenance/archiving policy offerings that says:

    [_] Delete/Archive if DKIM signature expired
        AND message as been received.

We already have an similar mail packing options such as:

    Days to keep READ Private Mail: ____
    Days to keep UNREAD Private Mail: ____

So I can see a valid consideration to adding more options based on the value
of the message itself, including and especially one that says:

    Days to keep INVALID DKIM messages: _____

2) Server provided Users Options

Online Servers may offer the user mail reading control options:

   [X] Do not accept invalid DKIM-based mail
       [X] Move to folder: ____Junk folder_____

   [X] Do not accept/show expired DKIM-based mail
       [X] Only after reading it once.
       [X] Move to folder: ____Expired folder_____

3) Commercialization/Venture Aspects

ESP/ISP sells domain space with an optional DKIM signing subscription based
add-on service.  Although, the biggest control would be to remove/stop DKIM
signing (and remove keys from domains DNS record) for the domain when the
service expires (fixed annual certificates?), this might hurt downlinks
suddenly seeing was good valid mail suddenly becoming invalid.  With the
expiration descriptor,  much like a Browser does day, the Mail Reader can
show an Valid by Expired "certified" message.

If anything, I think #1 and #2 probably is more realistic that an future
implementation may wish to offer if only to distinguish itself from the next
guy.  I probably said more than I wanted too already, but overall, if you
have an x= tag or any other extra piece of information the domain wish to
expose, someone will use it one way or another.  The question is, I think,
is this a candidate for consistent usage i.e. mandating all verifiers to
honor it for whatever purpose.  If you don't think you can accomplish that,
then maybe it doesn't have any value.

---

From: Mark Delany <[email-masked]>
Date: Sun, 9 Apr 2006 14:28:53 +0000

> 3) Commercialization/Venture Aspects

There are two issues here. 1) Are these useful pieces of
functionality, and 2) should they be embedded in a transit-time email
authentication system.

Hector, are you advocating both of these?

Mark.

---

From: Jim Fenton <[email-masked]>
Date: Mon, 10 Apr 2006 11:38:40 -0700

> of the time the message was signed.
I have a lot more trouble understanding why t= needs to be kept than why
x= needs to be kept.  As a signer, I would much rather specify an
expiration time for the signature than to specify the time at which it
was signed than to have the verifier add a fudge factor to the signing
time and use that as the expiration.  On this list, I have already heard
numbers between 1 and 2 weeks for the fudge factor, so the signer would
really have no idea how long the signatures are valid.

In addition to Arvel's comment about the relative difficulty of parsing
date/time out of Received headers, it's a really bad idea to do that
because they're not signed.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Mon, 10 Apr 2006 19:30:58 -0700

On Apr 10, 2006, at 11:38 AM, Jim Fenton wrote:

> John Levine wrote:
>>> Parsing and dealing with the value in x= is probably easier code  
>>> than doing the same with a date-stamp from a Received header.
>>
>> I think we all agree that t= is useful to have an easily parsed  
>> version of the time the message was signed.
>
> I have a lot more trouble understanding why t= needs to be kept  
> than why x= needs to be kept.

An expiry would be easier to exploit when attempting to induce down- 
stream bounces.  In the case of a bounce, the signature would be  
expected to be invalid, the source could be reputable, although the  
message may contain abuse now less easily blocked.

The t= is an optional signature parameter, where the Date header  
field is required per RFC2822 (3.6/3.6.1) to indicate when the  
message was ready for transport.

> As a signer, I would much rather specify an expiration time for the  
> signature than to specify the time at which it was signed than to  
> have the verifier add a fudge factor to the signing time and use  
> that as the expiration.

A bad actor would also prefer to specify an expiration.  This expiry  
parameter will not provide a safe basis for rejection without a risk  
of inducing bounces.  The Date header remains a viable alternative.

> On this list, I have already heard numbers between 1 and 2 weeks  
> for the fudge factor, so the signer would really have no idea how  
> long the signatures are valid.

Message signatures can be verified for as long as the signer keeps  
the keys available.  As an eventual alternative, a revocation  
mechanism assures affected message can be safely deleted which avoids  
a bounce exploit or response delays.  Revocation, checked when the  
message is transmitted from a system not associated with the signer,  
does not prolong an opportunity for various exploits, as would a  
fixed expiry.

> In addition to Arvel's comment about the relative difficulty of  
> parsing date/time out of Received headers, it's a really bad idea  
> to do that because they're not signed.

It is not a good idea to reject messages based upon a per-second  
expiry setting.  Rejection on this basis will be easily exploited.   
The current strategy of simply using the Date header per requirements  
established by the receiver remains a safer choice.  The t= and x=  
parameters are already optional.  Both t and x can be dropped by  
simply depending upon the required Date header.

-Doug

---

From: "John R Levine" <[email-masked]>
Date: 10 Apr 2006 23:52:27 -0400

> x= needs to be kept.

Without t= we have no idea when a message was signed, since there's no
particular reason that the Date: header has to contain the current date,
or even that there be one.

> that as the expiration.  On this list, I have already heard numbers
> between 1 and 2 weeks for the fudge factor, so the signer would

But the signer is likely to have little idea of what the transit time
to the recipient will be.  The basic justification for x= is that the
sender knows the transit time and the recipient doesn't.  I've never
seen any justification for that, and it's easy to think of scenarios
where it's just wrong.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"A book is a sneeze." - E.B. White, on the writing of Charlotte's Web
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Apr 2006 21:11:53 -0700

> or even that there be one.

And -- just to quibble a bit, but in a *nice* way -- it would not matter even if 
it did contain the "current" date.

The Date field specifies the time of posting.

Signing might take place at any time after that (or even before that.)

d/
-- 

Dave Crocker

---

From: Mark Delany <[email-masked]>
Date: Tue, 11 Apr 2006 05:07:04 +0000

On Mon, Apr 10, 2006 at 09:11:53PM -0700, Dave Crocker allegedly wrote:
> And -- just to quibble a bit, but in a *nice* way -- it would not matter 
> even if it did contain the "current" date.
> 

So, color me slow. We know for sure that signing happened in the
past. What specific value do we place on how far in the past that
signing occurred? What code do I write to test that specific value and
what do you recommend that a verifier do with such knowledge?

Mark.

---

From: Jim Fenton <[email-masked]>
Date: Mon, 10 Apr 2006 22:52:26 -0700

> or even that there be one.
Sure; I haven't been clear on why we care when the message was signed,
except as it affects the expiration of the signature (which x= expresses
more directly).
> seen any justification for that, and it's easy to think of scenarios
I don't see why the recipient would have any better idea than the sender
on whether the transit time is acceptable.

I prefer x= over extrapolation of t= because it gives the verifier a
simple, objective test to see whether the signature is "stale".

-Jim

---

From: John L <[email-masked]>
Date: Tue, 11 Apr 2006 09:22:57 -0400 (EDT)

> on whether the transit time is acceptable.

Because a recipient has the message after the transit has actually 
happened, and knows about the way his mail gets delivered and read.

Assume, for example, someone who uses a verifier in his MUA and only reads 
his mail once a week.  A sender signs and sends a message on Monday with a 
one-day x= value, it's delivered ten seconds later and spends four days 
sitting in his mailbox.  When our user reads his mail on Friday, is he 
allowed to verify it?  To me the answer is obviously yes.  How do you 
handle that with x= ?  Do you interpret the x= value as of some past time 
when the mail was placed in a stable place?  Tell him tough luck, he's not 
allowed to use DKIM unless he reads his mail more often?  I don't know how 
to write rules that would handle every possible recipient scenario, and 
neither does anyone else, so it's nuts to try.  It's the same reason that 
the SMTP RFCs don't try and set fixed retry or timeout values, only 
guidelines.

> simple, objective test to see whether the signature is "stale".

This is the confusion of precision and accuracy.  Just because a sender 
can set a x= value doesn't make it meaningful.  If you want a simple, 
objective test, t= plus 603763 seconds is just as objective, but perhaps 
more obviously not useful.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 11 Apr 2006 06:26:43 -0700 (PDT)

> what do you recommend that a verifier do with such knowledge?

You don't need to make an extra dns (or preferaly non-dns) query
if you know signature is no longer valid based on x.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 11 Apr 2006 06:38:42 -0700

> Assume, for example, someone who uses a verifier in his MUA and only
 > reads his mail once a week.  A sender signs and sends a message on
 > Monday with a one-day x= value, it's delivered ten seconds later and
 > spends four days sitting in his mailbox.  When our user reads his mail
 > on Friday, is he allowed to verify it?

If by some miracle people actually rolled their keys over every
week -- as Mark is to be suggesting as the alternative to x=
-- then your use case would not work either.

> To me the answer is obviously 
> yes.  How do you handle that with x= ?  

This is a false dilemma because you are requiring dkim to work in
situations that it was explicitly not intended to work for.

		Mike

---

From: "John R Levine" <[email-masked]>
Date: 11 Apr 2006 09:48:44 -0400

> -- then your use case would not work either.

Quite true.  So what?

> situations that it was explicitly not intended to work for.

Uh, what situations are those?  If DKIM isn't useful for mail sent to
humans with MUAs, why are we wasting our time?

If your issue is that the time was a week, change the x= time to 15
minutes, the mail still lands in the recipient's mailbox in 10 seconds,
and the user reads mail once an hour.  Same problem.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Tue, 11 Apr 2006 06:55:08 -0700

>>-- then your use case would not work either.

It means that your corner cases are not valid uses of DKIM.

> humans with MUAs, why are we wasting our time?

A nice strawman.

> and the user reads mail once an hour.  Same problem.

Then you're not giving x= a value that is in line with the spec either.
DKIM is intended to work over the normal transport lifetime of a mail
message.

This is really not rocket science. You set x= to t= +2 weeks and you're
done.

		Mike

---

From: "John R Levine" <[email-masked]>
Date: 11 Apr 2006 10:03:35 -0400

> > humans with MUAs, why are we wasting our time?

No, it's an honest question.  Many real users read their mail a whole lot
less often than we weenies do.  I know people who read their mail once a
week.

> DKIM is intended to work over the normal transport lifetime of a mail

Now we're back to the original question.  How do you as a sender know what
is normal in my inbound mail system?  You don't.

Conversely, if senders are always supposed to set x= to t+1209600, what is
the point of x= ?  It contains no useful information.  Even worse, since
there is no reason to assume that a sender will set an x= that is
appropriate for a receiver's situation, it is likely to contain
disinformation that a sensible receiver should ignore.

R's,
John

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 11 Apr 2006 07:33:54 -0700

>situations that it was explicitly not intended to work for.

If MUAs are not supposed to be validating messages, then we need to 
change the -base spec in many places.

Is that what this WG wants?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Tue, 11 Apr 2006 07:46:58 -0700

> change the -base spec in many places.

You can't have both ways: either signatures are valid essentially
forever -- which is what would be required for MUA's to reliably
validate signatures -- or they aren't. MUA's that happen to be
able to read the message within "transport" time are perfectly at
liberty to validate messages -- no restrictions at all. But that's
a much different proposition than saying that they will be able to
validate them whenever they get around to reading them. That is not
the problem we set off trying to solve.

		Mike

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 11 Apr 2006 11:24:20 -0400

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

>> If MUAs are not supposed to be validating messages, then we 
>> need to change the -base spec in many places.
> 

You can have it both ways with the proposed change to 
use the message reception time:

  dynamic verification -> msg reception time = current time
  delayed verification -> msg reception time = 2822.Received: time

This resolves the question on whether the expiration tag may be used to
invalidate an already stored message based on the current time.

See 

http://mipassoc.org/pipermail/ietf-dkim/2006q2/003134.html

---

From: Douglas Otis <[email-masked]>
Date: Tue, 11 Apr 2006 10:07:04 -0700

On Apr 11, 2006, at 7:46 AM, Michael Thomas wrote:

> Paul Hoffman wrote:
>>
>> If MUAs are not supposed to be validating messages, then we need  
>> to change the -base spec in many places.
>
> validate signatures -- or they aren't.

Signatures can be verified for as long as keys remain available.   
That period must be long enough for recipients to examine their  
messages.  DKIM evaluation can occur at the MDA _and_ the MUA.   
Ensuring verification at the MUA expedites use of DKIM.  Otherwise,  
DKIM is little better than some header claiming a message is okay.   
No MUA can trust such headers without perhaps burdensome out-of-band  
assurances about the MDA.

> MUA's that happen to be able to read the message within "transport"  
> time are perfectly at liberty to validate messages -- no  
> restrictions at all.
> But that's a much different proposition than saying that they will  
> be able to validate them whenever they get around to reading them.

Verification takes place at the MUA as part of the transport period.

Per the threat draft:
,---
| The transmission of messages via SMTP, defined in RFC 2821 [RFC2821],
| and such elements as the envelope-from and envelope-to addresses and
| the HELO domain are not relevant to DKIM verification.  This is an
| intentional decision made to allow verification of messages via
| protocols other than SMTP, such as POP [RFC1939] and IMAP [RFC3501]
| which an MUA acting as a verifier might use.
'___

The transport could be to an ocean going vessel connecting via a slow  
radio link where communication requires clear weather.  DKIM should  
operate even with longer transport times, including the transport to  
the MUA.  Hector suggested expiry evaluation at the MUA should be a  
comparison with the Received header time.

> That is not the problem we set off trying to solve.

What problems are created by the solution?

Should message acceptance be refused when expired and signed by an  
domain that signs all messages?

How does the receiving system ensure a flood of DSNs is not created  
up stream as a result of adhering to this policy?

How would an upstream system ensure a down-stream induced flood of  
DSNs is not created?

What expiry time should remain before accepting a message, assuming  
there may be down-stream handling?

-Doug

---

From: Mark Delany <[email-masked]>
Date: Tue, 11 Apr 2006 19:32:16 +0000

> if you know signature is no longer valid based on x.

So the purpose of x= is to optimize corner-case DNS queries?

Mark.

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 11 Apr 2006 12:42:18 -0700 (PDT)

> So the purpose of x= is to optimize corner-case DNS queries?

That is just one of the cases where they can be of use, you after all 
asked for "specific value".

It would also be good to have when you want to do more refined security 
setup between two hosts.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 11 Apr 2006 13:55:00 -0700

On Apr 11, 2006, at 12:42 PM, william(at)elan.net wrote:
> That is just one of the cases where they can be of use, you after  
> all asked for "specific value".

This is not a compelling reason.  What percentage would this exclude  
from further examination?  .00001%?

> It would also be good to have when you want to do more refined  
> security setup between two hosts.

Although I am still publishing the public key, do not consider it to  
be from me?

For a security refinement, retire the key and achieve increased  
security.  Do not rely upon a message expiry parameter.

Even the informative note discounts a "security refinement" motive,  
which sounds like double-speak for an abusive message replay defense.

Security Refinement: One may receive message replay abuse for 2  
weeks, rather than for the period pending key retirement.  The expiry  
strategy offers little protection.  When used as protection  
(security), the problems a precision timed expiry may create increase.

Please don't consider DSNs someone else's concern.  If there is a  
problem, establish a mechanism to expunge the messages, and not have  
them fall into a category where they might be rejected post up stream  
acceptance.

x= base:
,---
| Signatures MUST NOT be considered valid if the current time at the
| verifier is past the expiration date.  The value is expressed as
| an unsigned integer in decimal ASCII.
|...
|  INFORMATIVE NOTE:  The x= tag is not intended as an anti-replay
|                     defense.
'___

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 11 Apr 2006 14:48:46 -0700

At 7:46 AM -0700 4/11/06, Michael Thomas wrote:
>But that's

If the WG agrees with that last sentence, then many parts of -base 
need to be rewritten. Currently, the protocol document puts no limit 
on quickly the recipient is expected to do the validation.

Further, section 6.4 makes no sense and has to be eliminated or 
seriously re-written. You can't put a header in a message for a fact 
that will become untrue in the future. The semantics of such a header 
will need to be changed to "This signature is valid when this header 
was created, but will become invalid at time xyz".

Further, section 6.5 will have to be re-written as well to say that 
when passing the signature validation information to higher-level 
processes, they will need to come with the time after which the 
signature is no longer valid.

There are probably more silly states related to x= in the document as 
well. They will need to be fixed before the document can be 
considered to be finished.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Tue, 11 Apr 2006 16:13:19 -0700

Paul Hoffman wrote:
> will need to be changed to "This signature is valid when this header was 
> created, but will become invalid at time xyz".

I'm having a hard time understanding the hand wringing here. This
can happen at _any_ time if you remove the selector from the DNS
too. So what?

As far as I can tell, the only thing that needs to be "rewritten"
is to mention x= in the step-by-step.

> Further, section 6.5 will have to be re-written as well to say that when 
> passing the signature validation information to higher-level processes, 
> they will need to come with the time after which the signature is no 
> longer valid.

Section 6.5 says in its entirety:

   "verifiers MUST consult the Sender Signing Policy as described in [ID-
    DKIM-SSP] and act accordingly.  The range of possibilities is up to
    the verifier, but it MAY include rejecting the email."

If there's a problem here it's that it doesn't enumerate all of the
outputs of the verification process. x= is only a small part of
those outputs.

> well. They will need to be fixed before the document can be considered 
> to be finished.

If there are "silly states", they apply equally to removing a selector
from the DNS. So removing x= from the spec does not relieve us of that
exercise.

		Mike

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 11 Apr 2006 16:37:05 -0700

At 4:13 PM -0700 4/11/06, Michael Thomas wrote:
>>seriously re-written. You can't put a header in a message for a 
>>fact that will become untrue in the future. The semantics of such a 
>>header will need to be changed to "This signature is valid when 
>>this header was created, but will become invalid at time xyz".
>

That is simply not true. If you don't have restrictions on how long a 
signature is valid, once it has been validated, it never expires. The 
fact that you cannot re-validate at some point in the future is 
completely unrelated to its validity.

Saying that a signature becomes invalid when the DNS record is 
removed is like saying that a paper contract becomes invalid when the 
person signing it becomes unavailable to sign again to prove the 
signature.

>is to mention x= in the step-by-step.

It needs more than a "mention". For example:
    Once the signature has been verified, that information MUST be
    conveyed to higher level systems (such as explicit allow/white lists
    and reputation systems) and/or to the end user.
With x= in the equation, that changes to:
    Once the signature has been verified, that information MUST be
    conveyed to higher level systems (such as explicit allow/white lists
    and reputation systems) and/or to the end user, and MUST include
    the validity period of the signature so that the higher level
    systems can change their actions based on the current time.
And so on.

>    the verifier, but it MAY include rejecting the email."

My copy of 6.5 is much longer than that.

>outputs of the verification process. x= is only a small part of

x= is the only "feature" so far that changes the validity of the 
signature based on the time, and is thus the only one that affects 
the verification process at a time other than at the moment the 
verification happens.

>>There are probably more silly states related to x= in the document 
>>as well. They will need to be fixed before the document can be 

Again, that is completely, and demonstratively, wrong. If you remove 
the selector from the DNS, verification fails predictably at the time 
the recipient tries. The x= semantics say that a signature can be 
valid at one moment and invalid at the next. Note the difference 
between those two.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Tue, 11 Apr 2006 16:44:18 -0700

Paul Hoffman wrote:
> Again, that is completely, and demonstratively, wrong. If you remove the 
> selector from the DNS, verification fails predictably at the time the 
> recipient tries. The x= semantics say that a signature can be valid at 
> one moment and invalid at the next. Note the difference between those two.

There is no difference in my code. Beyond the logging, they are
treated identically. What is your code doing differently?

		Mike

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 11 Apr 2006 19:51:22 -0400

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

> valid at one moment and invalid at the next. Note the difference 

This is solved by using the Message Reception Time, rather than the
current time. See my proposal on this change.

---

From: Jim Fenton <[email-masked]>
Date: Tue, 11 Apr 2006 17:08:47 -0700

John L wrote:
> on Friday, is he allowed to verify it?  To me the answer is obviously
> yes.  How do you handle that with x= ?  Do you interpret the x= value
> as of some past time when the mail was placed in a stable place?  Tell
> him tough luck, he's not allowed to use DKIM unless he reads his mail
> more often?  I don't know how to write rules that would handle every
> possible recipient scenario, and neither does anyone else, so it's
> nuts to try.  It's the same reason that the SMTP RFCs don't try and
> set fixed retry or timeout values, only guidelines.
This is why verification at the MDA or an MTA is preferred.  If you want
to really handle the case of an MUA verifying a signature when the user
returns from an "email vacation", the signature lifetimes need to be
much longer.

>From the DKIM WG charter:

> To prevent this task from becoming unwieldy, several related topics are
> considered out of scope for the DKIM working group. These topics
> include:
[...]
> * 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.
For me, x= expresses the intent of the signer as to how long the
signature should be valid.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Apr 2006 17:43:10 -0700

Paul Hoffman wrote:
> If the WG agrees with that last sentence, then many parts of -base need 
> to be rewritten. Currently, the protocol document puts no limit on 
> quickly the recipient is expected to do the validation.

The focus on transit-related validation -- as distinctly different from 
open-ended, long-term validation, has been fundamental for the entire life of 
this effort.

> that will become untrue in the future. 

The header simply says that the
message was validated.  Not that it can be validated at some point in the future.

> they will need to come with the time after which the signature is no 

huh?  why?

d/
-- 

Dave Crocker

---

From: John L <[email-masked]>
Date: Tue, 11 Apr 2006 21:11:03 -0400 (EDT)

>>   which is normally only a matter of a few days at most.

Right.  I'm not saying a recipient would check the signature ten years 
later, I'm saying he might check it ten days later, knowing that the 
message has been safely in his inbox for five of them.

> signature should be valid.

Yes, you've said this before, and I've pointed out that since the signer 
has no particular insight into what the transit time will be, there is no 
useful information for the recipient in the x= value.

Also, I see no consensus on what "valid" means in this context beyond an 
unhelpful "don't you dare check after this time even if you have a 
perfectly sensible reason to do so that I hadn't thought of."  You can't 
force people to be sensible by making unenforcable rules.

R's,
John

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 11 Apr 2006 18:47:19 -0700

At 5:43 PM -0700 4/11/06, Dave Crocker wrote:
>>need to be rewritten. Currently, the protocol document puts no 
>>limit on quickly the recipient is expected to do the validation.
>
>
>The focus on transit-related validation -- as distinctly different 
>from open-ended, long-term validation, has been fundamental for the 
>entire life of this effort.

Then that should be stated in the document, not just in the lore of 
the WG. If it is there and I missed it, I apologize, but I don't see 
it. Further, nothing in the discussions of MUAs doing validation seem 
to talk about the obvious case that an MUA might do first validation 
long after "transit".

>>fact that will become untrue in the future.
>

There is a huge disconnect here. x= is *not* talking about the 
ability to validate at some point in the future; it talks about a 
message that is valid at one point becoming invalid at a later point.

The text in draft-kucherawy-sender-auth-header-03, which is a 
normative reference from dkim-base, gives the following semantics for 
the "pass" label:
         sending domain publishes an authentication policy of some kind,
         and the message passed the authentication tests
Note the past tense used: "passed the authentication tests". In a 
normal environment, that is sufficient for a MUA to give a sensible 
notice. But in an environment where a message can be valid at one 
moment and invalid at the next, that is not sufficient to tell the 
MUA what to display at any particular time.

Is this clearer?

>>signature is no longer valid.

So that the higher level process can determine when the signature on 
the message is no longer valid. Think of it this way: Two people look 
at a check. One says to you "this check written out to you is for 
$100", and the other person says "this check written out to you is 
for $100, but it is no longer valid after tomorrow". Both those 
statements are true, but the only the second statement is useful in 
making a policy decision about what you should do with the check.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Apr 2006 21:12:18 -0700

Paul Hoffman wrote:
> Then that should be stated in the document, not just in the lore of the 
> WG.

Yes it should.

> Further, nothing in the discussions of MUAs doing validation seem to 
> talk about the obvious case that an MUA might do first validation long 
> after "transit".

Yeah.  The discussion has raised an interest point about this, IMO.

> There is a huge disconnect here. x= is *not* talking about the ability 
> to validate at some point in the future; it talks about a message that 
> is valid at one point becoming invalid at a later point.

It should talk about being able to conduct a validation within a window of time, 
and not being able to do it after the window closes. And treating the message as 
having no signature, absent the ability to do a validation and absent any other 
validation information (like an authentication header.)

This is not about a "contract signature" becoming invalid.  It is more like a 
traffic light changing.  Transit is ephemeral, so it should not be surprising 
that a mechanism related to transit is ephemeral.

> The text in draft-kucherawy-sender-auth-header-03, which is a normative 
> reference from dkim-base, gives the following semantics for the "pass" 
> label:

I thought that it was (being) removed as a normative reference.

> Note the past tense used: "passed the authentication tests". In a normal 
> environment, that is sufficient for a MUA to give a sensible notice. But 
> in an environment where a message can be valid at one moment and invalid 
> at the next, that is not sufficient to tell the MUA what to display at 
> any particular time.
> 
> Is this clearer?

"passed the authentication tests" is an accurate description of what took place. 
  "Message valid at one moment and not at the next" is not.

> So that the higher level process can determine when the signature on the 
> message is no longer valid. Think of it this way: Two people look at a 
> check. One says to you "this check written out to you is for $100", and 
> the other person says "this check written out to you is for $100, but it 
> is no longer valid after tomorrow". 

A DKIM signature says that someone asserts that they are accountable for message 
transit.  You are confusing limitations in the ability to perform a validation 
check, with the continuation of the assertion's validity.

If you go through an intersection when the light is green (for your direction) 
it was valid for you to proceed.  The light changes.  The validity of your 
having transited the intersection does not.

d/
-- 

Dave Crocker

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 12 Apr 2006 09:16:54 -0700

At 9:12 PM -0700 4/11/06, Dave Crocker wrote:
>It should talk about being able to conduct a validation within a 
>window of time, and not being able to do it after the window closes.

If that's what the WG wants, great. But that is *not* what the document says:
        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.

>This is not about a "contract signature" becoming invalid.

"MUST NOT be considered valid" sure sounds like "becoming invalid" to me.

>   It is more like a traffic light changing.  Transit is ephemeral, 
>so it should not be surprising that a mechanism related to transit 
>is ephemeral.

This is a good analogy, one that it seems many people in the WG want. 
But it is not what is in the document.

>"passed the authentication tests" is an accurate description of what 
>took place.  "Message valid at one moment and not at the next" is 
>not.

We disagree, then. If the verifier checks the validity and it passes, 
and later checks the validity and it fails because of x=, then 
"Message valid at one moment and not at the next" seems to be a 
reasonable technical description of what happened.

>A DKIM signature says that someone asserts that they are accountable 
>for message transit.

And here we are fully agreeing again, although no such simple 
statement exists in the document. (Hint: search for the word 
"responsible".)

>You are confusing limitations in the ability to perform a validation 

No, I'm not. x= says *nothing* about "limitations in the ability to 
perform a validation check"; it *does* talk about "continuation of 
the assertion's validity".

>If you go through an intersection when the light is green (for your 
>direction) it was valid for you to proceed.  The light changes.  The 
>validity of your having transited the intersection does not.

And, again, we fully agree.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Wed, 12 Apr 2006 09:35:05 -0700

> If that's what the WG wants, great. But that is *not* what the document 

right.

i think we've well and truly established that the wording could and should be 
improved.

>>   It is more like a traffic light changing.  Transit is ephemeral, so 
>> it should not be surprising that a mechanism related to transit is 
>> ephemeral.
> 

see above.

>> took place.  "Message valid at one moment and not at the next" is not.
> 
> and later checks the validity and it fails because of x=, then "Message 
> valid at one moment and not at the next" seems to be a reasonable 
> technical description of what happened.

You utter a statement.  I am present.  Mark Delany is not.  I can validate what 
you said.  Mark cannot.

This is a temporally-dependent ability to "confirm" what you said.  (The traffic 
light analogy is merely another way of describing this time-dependent 
characteristic.)

Verifying that the signature was valid for transit, at one moment, and then 
being unable to repeat the verification at some point in the future, does not 
invalidate the original validation.

> And here we are fully agreeing again, although no such simple statement 
> exists in the document. (Hint: search for the word "responsible".)

See above.

d/
-- 

Dave Crocker

---

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

On Apr 11, 2006, at 9:12 PM, Dave Crocker wrote:

> window of time, and not being able to do it after the window  
> closes. And treating the message as having no signature, absent the  
> ability to do a validation and absent any other validation  
> information (like an authentication header.)
>
> This is not about a "contract signature" becoming invalid.  It is  
> more like a traffic light changing.  Transit is ephemeral, so it  
> should not be surprising that a mechanism related to transit is  
> ephemeral.

Should the transit time also cover the message being read and  
verified by the MUA, and not just the MTA?

The transit should include a reasonable time for the message to  
reviewed by the recipient.  This view is consistent with the Threat  
document that considers IMAP and POP part of the transport.

Adding just a simple header that the MDA considered the message valid  
at one point raises questions who added the header and removes the  
protection to be obtained by DKIM.  Until all MDAs strip such  
results, these headers offer a method to dupe recipients and  
seriously reduces protections being sought with DKIM.

If the desire is to have signatures remain valid only up to the MDA,  
then the MDA should replace these signatures with theirs, listing the  
domains that verified.  Define a tag in the signature that indicates  
MDA ownership.  This MDA tag should permit long lived signatures, as  
then these MDA signatures could not be used to send messages  
elsewhere.  This strategy would thwart abusive replay of a message  
when the signature is replaced.  After all, defending against abusive  
replay is the _only_ justifiable reason for including the x= tag.

Rejecting messages on the basis of expiry raises DSN concerns, as  
many MTAs are known to be up stream of other MTAs.  Avoiding DSNs  
would then result in an ever escalating 'minimum time remaining  
before expiration' requirement.  This strategy will eventually force  
abandonment of the use of expiry or perhaps refusal to accept  
messages signed with the x= tag.  It would be impossible to trust all  
down-stream MTAs will not reject messages based upon the amount of  
time remaining before expiration.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 12 Apr 2006 14:57:26 -0400

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

> verified by the MUA, and not just the MTA?

The practical application is to ignore such controls once the message has
been received.  The MUA verifier consideration doesn't not apply or fit well
with he current expiration semantics.  My proposal to use the Message
Reception Time rectifies this situation.

> document that considers IMAP and POP part of the transport.

There is a basic rule of thumb in sychronization designs -

        Do not use Sleeps, Delay or Time considerations
        with fuzzy "best guess" values to sychronize
        processes or threads. Inevitably, it will give
        you problems.  The only place this may work well
        is in a world of fixed "time" slicing where each
        process has fixed residence times.

The best way to design this mail authentication protocol is to eliminate all
fuzziness.  Zoom in on your control triggers and events. This make the
protocol interfacing sound and of high quality.

> seriously reduces protections being sought with DKIM.

This is a good point.

I actually think that once a verifier has processed a DKIM, it needs pass
this information along.

In addition, in the case our own decades old mail framework, we have two
mail storage modes:

  - MIME preservation (Raw RFC2822 "as received" format)

  - Conversion to local format (Pure Text, separate
    attachment(s) concept)

MUA based verification, whether online or offline will required MIME
preservation, which is a user preference.  Offline users usually set this.
Text-based Online users don't. Web-based online users like to set it too,
but also turn it off to avoid HTML based security exploits.

So, for us, DKIM best applies at the transport level, adding a new piece of
header or field information so that the results can be shown to online
users.  We would have difficulty to get this information passed to offline
MUAs without modifying them.

I would think this is general design issue for most systems, not just us.

> replay is the _only_ justifiable reason for including the x= tag.

Agree.  But we don't want to eliminate the entrepreneur (including
Intrapreneur, for company hot shots) ambitions to write DKIM plug-ins for
MUAs too. :-)

We might need two things then:

   - Some result header (Has this message been verified yet?)

   - Specify that the Message Reception Time is the
     time to use for expiration comparison.