Subject: Re: [ietf-dkim] RFC4871bis - whether to drop -- x: Signature expiration

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 01 Jun 2009 11:24:10 +0100

On Sat, 30 May 2009 18:12:47 +0100, Dave CROCKER <[email-masked]> wrote:

> This note is intended to anchor a discussion thread for discusses one of  
> those
> features, namely:
>
>
>>    DKIM-Signature Header tags
>>
>>      x: Signature expiration
>>
>> Expiration is a fairly common feature in signing specifications. But
>> DK and DKIM are different in that the public key is not distributed to
>> others, it's always under the control of the signer. Does this add
>> anything that removing the DNS TXT record doesn't do? Is it used? Is
>> it necessary?

OTOH, there might well be other applications, built on top of DKIM for as  
yet totally unforeseen purposes, which might need to specify other (longer  
term) means of establishing the public key, and for such applications the  
x tag might well be needed.

There is nothing inherent in the basic DKIM protocol that would prevent  
such extensions in the future, so do not close them off prematurely.

I know of (at least) 3 different and mutually incompatible systems for  
signing headers in regular use, and DKIM is merely the latest of them. I  
would not like to see people to be forced to invent fourth and fifth  
systems, just because DKIM has painted itself into some unnecessary corner.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Steve Atkins <[email-masked]>
Date: Mon, 1 Jun 2009 05:56:15 -0700

> x tag might well be needed.

In which case it can be added by the RFC that extends DKIM to non-DNS
based key distribution. That RFC will be needed anyway, for anything  
other
than DNS-based distribution to be used.

> systems, just because DKIM has painted itself into some unnecessary  

Cheers,
   Steve

---

From: "Siegel, Ellen" <[email-masked]>
Date: Mon, 1 Jun 2009 11:33:54 -0400

> > anything that removing the DNS TXT record doesn't do? Is it used? Is

Unless there are implementations out there that cache the public key for extended periods of time, I don't see any benefit of the signature expiration tag that's not available by removing the DNS txt record. 

And if it's absolutely necessary to distinguish between the case of "there never was a record" and "this key has been expired/revoked", it seems like keeping the txt record and removing the key would cover the latter... although I'm not sure there's really a reason to make the distinction. 

Ellen

---

From: Jon Callas <[email-masked]>
Date: Mon, 1 Jun 2009 16:01:41 -0700

On Jun 1, 2009, at 8:33 AM, Siegel, Ellen wrote:

> Unless there are implementations out there that cache the public key  
> for extended periods of time, I don't see any benefit of the  
> signature expiration tag that's not available by removing the DNS  
> txt record.
>
> And if it's absolutely necessary to distinguish between the case of  
> "there never was a record" and "this key has been expired/revoked",  
> it seems like keeping the txt record and removing the key would  
> cover the latter... although I'm not sure there's really a reason to  
> make the distinction.

I agree with Ellen that there' hardly any use for signature expiration  
that can't be solved by yanking the key from the DNS.

DKIM is a short-term protocol. The signature on a message is supposed  
to protect it while it is in transit. The longer a message sits in a  
mailbox, the less value the DKIM signature has. Expiring the  
signatures has little value.

On the other hand -- it's already in there. The arguments we're making  
now are all good arguments for never having x=, and less good for  
taking it out. Despite it being an idea of limited use, someone might  
be using it, and someone might think of a good reason to have it in a  
few years. Murphy's law being what it is, someone will find a really  
good use for it if and only if we remove it.

My suggestion is to ask some implementers. If they think it made  
implementing DKIM hard, or they see value to removing it, then do so.  
If they are lukewarm or supportive, keep it in.

	Jon

---

From: John Levine <[email-masked]>
Date: 2 Jun 2009 11:04:29 -0000

>implementing DKIM hard, or they see value to removing it, then do so.  

The biggest problem with x= is that it mainly exists to support the
false belief that senders can tell recipients what to do.

If I sign a message with x= set to three years in the future, what's a
recipient supposed to do?  How about three months?  Three weeks?
Three days?  Three minutes?  I don't understand what is right thing
for a receiver to do with x= and I don't think anyone else does
either.

A reasonable verifier can completely ignore x= and still get the right
result in all non-silly cases, which tells me that x= should go.

R's,
John

PS: This is the same reason that l= should go.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 2 Jun 2009 09:39:43 -0700

> false belief that senders can tell recipients what to do.

The expiry is determined at the point of delivery. When expiry  
represents a fairly short interval, this would indicate a short  
delivery latency should be expected.

> If I sign a message with x= set to three years in the future, what's  
> a recipient supposed to do?  How about three months?  Three weeks?  

This feature is likely to become increasingly important once DKIM  
plays a larger role on acceptance.  This is likely to occur when IPv6  
email becomes more common.  At that point (not now),  DKIM replay  
abuse might need to be mitigated through the use of expiry feature.   
Without this feature, rapid key roll-overs would create havoc whenever  
these results are analyzed at some point beyond delivery, as is often  
the case.

> A reasonable verifier can completely ignore x= and still get the  
> right result in all non-silly cases, which tells me that x= should go.

This would be the wrong conclusion to draw, because this is based upon  
current usage which places little reliance upon DKIM, and as such,  
this means there is also less motivation to abuse this protocol.

The x= and the l= are both features aimed at improving DKIM robustness  
in the presence of less than ideal handling.

These features should remain.

-Doug

---

From: Murray Kucherawy <[email-masked]>
Date: Tue, 2 Jun 2009 10:56:37 -0700

> [...]

I think "l=" and "x=" both put more information into the hands of the verifiers.  It's true they can ignore such information, but they can also elect to observe things like "Hmmm, the verifier didn't intend for this to verify beyond time T.  Maybe I should treat it differently somehow."

Same goes for "l=".  And the opposite goes for "l=" as well; a verifier could decide it will not accept mail that has had more than a certain volume, or percentage, of additional text beyond what the signature covers.  I know of one such implementation already.

Just because one verifier (or even many) could decide to ignore "x=", doesn't mean all of them will want to do so.

I'm not sure I agree with the rhetoric that DKIM's base spec should include absolutely nothing other than the bare essentials.  I'm a fan of providing more information whenever possible.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 02 Jun 2009 11:37:58 -0700

> I'm not sure I agree with the rhetoric that DKIM's base spec should include absolutely nothing other than the bare essentials.  I'm a fan of providing more information whenever possible.

The motivation of x= was twofold:

1) life of the key and life of a message signature aren't the same thing. A key
    may be _very_ long lived, where you might want to throttle the signature validity
    to "transport time" (= ~ 2 weeks, say)
2) there seems to be some expectation DNS based key management is a trivial matter.
    Well, it's not. Half of the trouble of DKIM is mail admins getting keys into DNS
    in the first place. Expecting that you're going to have regular key rollover is
    a pipe dream for a lot of folks. We'll be lucky if they can manage things in a
    fire drill.

		Mike

---

From: "John R. Levine" <[email-masked]>
Date: Tue, 2 Jun 2009 20:00:56 +0100 (BST)

> I think "l=" and "x=" both put more information into the hands of the 
> verifiers.

Well, sure, but the question is whether that information is useful.  We 
could include the phase of the moon and the software author's middle name, 
too.

Both l= and x= are bad for interoperability, because it is utterly unclear 
what a recipient will do with them.  Whevever I ask, the answer is they 
might do this and they could do that.  If I put a really long x= into a 
signature, will recipient systems accept a stale message that otherwise 
they wouldn't?  If I sign the first 100 bytes of a 10K message, will 
recipient systems accept it, and if so, what will users see?  There's no 
way to tell, because everyone just makes something up.

I'm all in favor of standards communicating useful information, but if you 
don't have an agreed algorithm for what to do with it, you're just going 
to get more confusion, not better results.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 2 Jun 2009 12:11:15 -0700

> could include the phase of the moon and the software author's middle
> name, too.

Sure, if you want to be silly about it.  But I was being serious.

> I'm all in favor of standards communicating useful information, but if
> you don't have an agreed algorithm for what to do with it, you're just
> going to get more confusion, not better results.

DKIM and (Sender-ID and SPF while I'm at it) make recommendations about what to do with a signature that fails to verify, but receivers are still at liberty to do what they wish.  The open source implementations I developed have options to reject messages which fail verification even though the specs discourage that activity because users demanded it.

Thus, insisting on a solution which has only one possible outcome at a receiver is, to me, a non-starter.

-MSK

---

From: "John R. Levine" <[email-masked]>
Date: Tue, 2 Jun 2009 20:16:38 +0100 (BST)

> DKIM and (Sender-ID and SPF while I'm at it) make recommendations about 
> what to do with a signature that fails to verify

Right, but l= and x= make it unclear what it even means to verify.

R's,
John

---

From: Paul Russell <[email-masked]>
Date: Tue, 02 Jun 2009 16:07:19 -0400

> way to tell, because everyone just makes something up.

I would argue that your specification of l=100 when the actual message size is
10K is intentional breakage of your own signature.  Perhaps I am short on
imagination, but I cannot imagine why anyone would intentionally specify an
incorrect value for l=, knowing that this will invalidate the signature.  You
seem to be pushing the limits of credibility in an apparent attempt to justify
dropping l= from the spec.  If you don't want to use l= in your DKIM signature,
don't use it, but some of us believe it to be a useful attribute.

-- 
Paul Russell, Senior Systems Administrator
OIT Messaging Services Team
University of Notre Dame
[email-masked]
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 2 Jun 2009 20:56:31 -0000

>> Both l= and x= are bad for interoperability, because it is utterly
>> unclear what a recipient will do with them.  Whevever I ask, the
>> answer is they might do this and they could do that.  If I put a
>> really long x= into a signature, will recipient systems accept a
>> stale message that otherwise they wouldn't?  If I sign the first
>> 100 bytes of a 10K message, will recipient systems accept it, and
>> if so, what will users see?  There's no way to tell, because
>> everyone just makes something up.

>I would argue that your specification of l=100 when the actual
>message size is 10K is intentional breakage of your own signature.

I mean that the body hash covers the first 100 bytes of the body, and
doesn't cover the other 9900 bytes.

The question remains: given a message with such a signature, which is
entirely valid in the current DKIM, what will a recipient system do
with it?  What will users see?  Ask ten people, get ten answers, which
is about as far from interoperable as you can get.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 2 Jun 2009 14:02:42 -0700

> is about as far from interoperable as you can get.

I think the use of "interoperability" here is curious.  What qualifies as interoperable?  According to the DKIM spec, if sizeof(message) = 10k and l=100, then if the first 100 bytes were unchanged since signing, the signature is valid, and I think everyone would agree that the verifiers would all behave the same way.

You might get ten answers if you're asking about assessors, but I doubt you'd get ten answers when you're talking about verifiers.

---

From: John Levine <[email-masked]>
Date: Tue, 2 Jun 2009 17:09:01 -0400 (EDT)

> You might get ten answers if you're asking about assessors, but I doubt you'd get ten answers when you're talking about verifiers.

I thought you just said that you know people who reject signatures if the 
l= covers less than some percentage of the message.

R's,
John

---

From: Paul Russell <[email-masked]>
Date: Tue, 02 Jun 2009 17:10:19 -0400

> is about as far from interoperable as you can get.

Ah! I have a less-than-complete understanding of the current specification.
Why does the current specification allow the signer to specify an arbitrary
value for l=, rather than requiring the value of l= to be the actual length
of the message body at the time the message is signed?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 2 Jun 2009 14:21:16 -0700

> I thought you just said that you know people who reject signatures if
> the l= covers less than some percentage of the message.

I know of at least one implementation that offers that possibility, but it is clearly divided into an assessor portion and a verifier portion.  They happen to be packaged together.

The verifier reports a good signature if RFC4871 has been satisfied even if l= covers a tiny portion of the whole message.

The assessor is free to establish rules that stipulate a valid signature that covers a tiny portion of the message is not a valid signature.  The verifier, in this case, makes that additional data available to the assessor.

For that matter, the assessor is free to establish a rule that says Subject: header fields must be signed for the signature to be acceptable, even though RFC4871 makes no such stipulation.

Consumers of this implementation made specific requests to reject messages whose signatures didn't validate even though RFC4871 specifically advises against doing so.  It is also possible to make the assessor portion of that implementation consider a small "l=" case as an invalid signature, thus causing its rejection, even if the verifier portion gave the signature a thumbs-up.

I submit that RFC4871 can make assertions about the verifier, but not about the assessor.  I further submit that many assessor implementations will prefer the benefits of a verifier that provides more than just a Boolean output.

So where do you draw the "interoperability" line?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 2 Jun 2009 14:22:29 -0700

> of the message body at the time the message is signed?

How could a verifier tell any different, thus making non-compliance detectable?

The best we could do is say SHOULD there.  But maybe that's not a bad idea.

---

From: Doug Otis <[email-masked]>
Date: Tue, 2 Jun 2009 14:28:24 -0700

On Jun 2, 2009, at 2:10 PM, Paul Russell wrote:

> Ah! I have a less-than-complete understanding of the current  
> specification. Why does the current specification allow the signer  
> to specify an arbitrary value for l=, rather than requiring the  
> value of l= to be the actual length of the message body at the time  
> the message is signed?

There are cases where a receiving MTA or delivery agent will append a  
notification to incoming messages.  For example, when the DKIM  
signature is checked after being forwarded and the i= parameter has  
been used, appended notifications will not affect the signature  
verification process.  Appended portions of a message will need to be  
annotated differently, in the same manner unsigned headers should also  
be annotated differently.  Proper annotation may require greater  
annotation flexibility, or perhaps creation of message copies  
containing only signed information.  How messages are annotated is  
beyond the scope of the DKIM specifications.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Tue, 02 Jun 2009 14:47:33 -0700

> is about as far from interoperable as you can get.

What's it to you? The assessment of validly signed DKIM messages is
now and always has been out of the scope of this working group. The
problem here is the notion that you warrant an answer to this question.

		Mike

PS: will someone tell Levine to stop bouncing my messages? thx
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Tue, 02 Jun 2009 14:49:57 -0700

> You might get ten answers if you're asking about assessors, but I doubt you'd get ten answers when you're talking about verifiers.

Which is all that DKIM ever promised. This entire line of argument is highly
specious. Somebody's lack of imagination is not the gold standard.

		Mike

---

From: Jon Callas <[email-masked]>
Date: Tue, 2 Jun 2009 14:51:54 -0700

> false belief that senders can tell recipients what to do.

I agree. As a receiver, I laugh in the face of the very notion that am  
obligated to do anything with a message other than as I will.

	Jon

---

From: "John R. Levine" <[email-masked]>
Date: Tue, 2 Jun 2009 22:52:06 +0100 (BST)

> I submit that RFC4871 can make assertions about the verifier, but not 
> about the assessor.  I further submit that many assessor implementations 
> will prefer the benefits of a verifier that provides more than just a 
> Boolean output.

You're probably right, and that's the problem.

I don't have a legalistic definition of interoperability; I want 
implementations to, you know, interoperate.  When I sign and send a 
message, it'd be nice if I could expect recipients to interpret the 
signature consistently.  If assessors are likely to do inconsistent things 
with parts of the signature, if I want my mail to work, I'd better avoid 
those parts.

Your point about some assessors requring a signed subject is a good 
example. It tells me that 4871 section 5.4 is underspecified, and 4871bis 
should strengthen it to say that you MUST sign the headers that every 
message is supposed to have.

R's,
John

---

From: Jon Callas <[email-masked]>
Date: Tue, 2 Jun 2009 14:57:33 -0700

> is about as far from interoperable as you can get.

Well. I don't think it's quite that bad.

In the spec, we give non-normative guidance that the most correct  
thing would be to lop that extra 9900 bytes off.

There are a number of other questions that are important for product  
design that are unimportant at the protocol level. Should you tell the  
user that stuff was trimmed? Put the trimmed text in an attachment so  
they can see it?

If it were me -- I would treat all valid-signed messages of l=N to be  
precisely N bytes long and discard everything else. But gentlepersons  
can disagree.

	Jon

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 2 Jun 2009 15:04:08 -0700

> signature consistently.  If assessors are likely to do inconsistent
> things with parts of the signature, if I want my mail to work, I'd better
> avoid those parts.

So you are indeed trying to make predictions or assertions about assessors.  I don't think that's possible in any context.  The best you can do is make assertions about verifiers, because then you can at least claim that a deviant verifier is non-compliant.  There's no such thing as compliance when it comes to assessors since they don't have to follow any particular rules.

> example. It tells me that 4871 section 5.4 is underspecified, and
> 4871bis should strengthen it to say that you MUST sign the headers that every

Subject: isn't a mandatory header per RFC5322, if you're using that as a specific example.  I think Alt-N's implementation was the first to have as an option the ability to require that it be signed for a signature to be considered acceptable, and the basis for that was the notion that it's almost always a displayed header field.

So it depends on what you mean by "supposed to have".  If RFC4871bis says Subject: MUST be signed, we need to make sure we say why (i.e. "it's usually a display header") because it would otherwise appear to contradict RFC5322.

---

From: John Levine <[email-masked]>
Date: Tue, 2 Jun 2009 18:16:58 -0400 (EDT)

> So you are indeed trying to make predictions or assertions about assessors.
> I don't think that's possible in any context.

Then we're screwed, since it'll be impossible to do anything at all that 
makes it more likely to get your mail delivered.

>> 4871bis should strengthen it to say that you MUST sign the headers that 
>> every message is supposed to have.

> Subject: isn't a mandatory header per RFC5322, if you're using that as a 
> specific example.

Remember that a header doesn't have to be present to be signed. It'd be an 
egregious spamability hole to let people add signatures and replay without 
breaking the signature.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 2 Jun 2009 15:20:43 -0700

> obligated to do anything with a message other than as I will.

Which means you're also given the option to know what the signer's notion of the signature's validity time is.  And you're free to ignore it too.

If the signer doesn't provide it, the receiver has lost the choice to ignore it or use it.

I can't say for sure that anyone is or isn't using it, but I would prefer not to remove flexibility that's there now even if it was possibly a mistake for it to be there in the first place (unless of course it's clearly harmful).

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 2 Jun 2009 15:21:21 -0700

> Then we're screwed, since it'll be impossible to do anything at all
> that makes it more likely to get your mail delivered.

That's still blurring the line between a verifier and an assessor.  We can only make educated guesses about the latter, but we have substantial influence on the former.

> egregious spamability hole to let people add signatures and replay without

Oh, I haven't forgotten that.  It goes hand-in-hand with the "display header" idea.

---

From: Doug Otis <[email-masked]>
Date: Tue, 2 Jun 2009 15:21:40 -0700

On Jun 2, 2009, at 2:52 PM, John R. Levine wrote:
> 4871bis should strengthen it to say that you MUST sign the headers  
> that every message is supposed to have.

DKIM is not limited to just email.   Even ADSP failed to limit its  
assertions to just email.  As such, what should unspecified message  
formats contain?

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 2 Jun 2009 15:26:27 -0700

> assertions to just email.  As such, what should unspecified message

One would think the "unspecified message formats" would have defining documents someplace that identify header fields that are supposed to be present to be compliant.  So the generic language John suggested seems fine to me.

---

From: Jon Callas <[email-masked]>
Date: Tue, 2 Jun 2009 15:29:53 -0700

On Jun 2, 2009, at 3:20 PM, Murray S. Kucherawy wrote:

> Which means you're also given the option to know what the signer's  
> notion of the signature's validity time is.  And you're free to  
> ignore it too.
>
> I can't say for sure that anyone is or isn't using it, but I would  
> prefer not to remove flexibility that's there now even if it was  
> possibly a mistake for it to be there in the first place (unless of  
> course it's clearly harmful).

Noted. You are correct.

You bring up a good point, and I'm going to start a separate note.

	Jon

---

From: Michael Thomas <[email-masked]>
Date: Tue, 02 Jun 2009 15:39:23 -0700

Jon Callas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 

Jon, this is one of John's typical strawmen arguments. Putting an expiration
on a signature doesn't "obligate" the receiver to do anything any more than
putting a bh= does. The receiver is always free to do what it feels like
with that information including ignoring RFC4871. Everything in RFC4871 is
offered as information that a sender can provide receivers to make better
decisions, nothing more, nothing less.

		Mike

---

From: Douglas Otis <[email-masked]>
Date: Tue, 2 Jun 2009 15:53:04 -0700

On Jun 2, 2009, at 3:16 PM, John Levine wrote:

>> So you are indeed trying to make predictions or assertions about  
>> assessors. I don't think that's possible in any context.
>

The concern being raised is in regard to message annotation.  As Mike  
indicated, this parameter can be used can suppress false indications  
of invalid signatures.  The alternative of not having the l= feature  
results in MORE false indications of invalid signatures.  As such,  
removal of the feature is not justified by an effort seeking to  
improve interoperability!

>>> Your point about some assessors requring a signed subject is a  
>>> good example. It tells me that 4871 section 5.4 is underspecified,  
>>> and 4871bis should strengthen it to say that you MUST sign the  
>>> headers that every message is supposed to have.
>
>> Subject: isn't a mandatory header per RFC5322, if you're using that  
>> as a specific example.
>
> Remember that a header doesn't have to be present to be signed. It'd  
> be an egregious spamability hole to let people add signatures and  
> replay without breaking the signature.

This advise belongs in a BCP document and not in a document intended  
to define the general application of a signature.  Again, this is not  
about interoperability.  This is more about how messages might be  
better annotated.  Unsigned headers or message portions should either  
not be visible, or should be highlighted in a manner that indicates  
they were added after the signature or perhaps not signed.  In some  
cases, the separate annotation of appended notifications can better  
preserve the initial message's format.  Our company adds their legal  
foo at the end of every received message, without checking DKIM  
signatures.  In this case, only after forwarding, can these DKIM  
signatures be checked.  This is not much different from the mailing  
list issue that Mike confronts.

-Doug

---

From: John Levine <[email-masked]>
Date: 2 Jun 2009 23:03:31 -0000

>egregious spamability hole to let people add signatures and replay without 

Ahem, add a subject and replay ...

Time for bed.