Subject: RE: [ietf-dkim] Proposal: Do the semantics first, then straw poll

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 14 Apr 2006 06:41:35 -0700

> [mailto:[email-masked]] On Behalf Of Mark Delany

> On Thu, Apr 13, 2006 at 11:41:52PM -0400, Tony Hansen allegedly wrote:
> > Minor nit: #5 doesn't apply because it's explicitly 
> required to use up 
> > to 40 bits.
> 
> I'm actually a bit surprised that this is even talked about. 
> As a decimal representation, the relevance to 32bit unsigned 
> integers is a little tenuous.

Never underestimate the ability of people to screw up.

> In short, anyone who is still thinking 32bit in 2006 is 
> somewhat anti-diluvian.

Whats wrong with being opposed to floods? Or are you saying we should favor
global warming?

I think you mean ante-diluvian.

> Well, the days may be numbered for x= anyway, but if some 
> sort of timestamp is needed in the future, then maybe make it 
> millisecs or decisecs since 1970 and force the >32bit issue?

Yep, or do minutes.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: <[email-masked]>
Date: Mon, 17 Apr 2006 23:47:04 -0400

Responsibility is perhaps the wrong term. If a message is received past
the x=date it is stale and out of RFC impact. The sender is no more
responsible than sending a dkim sig without a public key, the message
becomes out of scope of the RFC and goes back to the verifying entity
for a policy decision on what to do about that particular message.
Thanks,

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jon Callas
Sent: Monday, April 17, 2006 9:21 PM
To: Paul Hoffman
Cc: ietf-dkim WG
Subject: Re: [ietf-dkim] Proposal: Do the semantics first, then straw
poll

On 17 Apr 2006, at 2:58 PM, Paul Hoffman wrote:

> At 12:11 PM -0700 4/17/06, Jon Callas wrote:
>> x= is a good thing because many, many people will change their  
>> DKIM keys every time they change what mail server they're using.  
>> This key will have a years-long, if not decades-long life. Using  
>> x= lets them blow off bit rot in messages that they are  
>> "responsible" for.
>
> Could you be a bit less folksy in your statement here? A message  
> that they have claimed to be responsible for has no bit rot  
> because, as we have mostly all agreed, the signature checking is  
> done once and the result is noted and possibly stored. By putting  
> the word "responsible" in quotes, are you saying that they are not  
> responsible for it in the future at some point?
>

I'm being folksy for a reason. One of the broader issues I'm talking  
about is what really happens. Semantics is inherently squishy.

I put "responsible" in quotes because it is an intentionally ill- 
defined term. A translation of that might be: responsible (whatever  
that means).

Now then, yes, x= is *precisely* a statement that time-bounds the  
responsibility (whatever that means). After time X, the signature is  
like produce past its use-by date. You throw it in the trash.

Let us suppose that I set my x= time to be 30 minutes. (And yes I  
know that it's an absolute time.) This means that most of the time,  
my messages will be properly signed by the time they get into your  
mailbox. Sometimes they won't, because email is like that. Much more  
often, though, your MUA will not be able to verify the signature  
because the expiry time on the message has passed.

This might be an obnoxious thing for me to do, but it's legal, and  
maybe even what I want. It's the way things work.

x= is *precisely* a statement that says, "after time X, my  
responsibility ends."

>> The issue, then, is what happens when I have my expiration being  
>> (e.g.) a month and I decide out of the blue to change keys.
>
> x= is an expiration for a particular statement of responsibility  
> for a message, not about key expiration. Key expiration is done in  
> the get-distribution part of the protocol.

I never said it was about key expiration. I don't believe keys  
expire; I believe keys either are in DNS or are not in DNS.

The issue I brought up is an implied responsibility to keep a key in  
DNS until the x= for any message sent has expired. At least I thought  
I read that some people think there is an implied responsibility to  
keep old keys around until the x= expires on any message you've sent.  
I think there's no such responsibility, there's merely the cause-and- 
effect of what happens.

There is no necessary connection between x= lifetime of a signature  
and key life or availability. If a key is not available, the message  
is not signed. If x= has expired, the message is not signed. That's it.

There is another semantic issue around all of this, which is the  
differences between the way an MTA and an MUA ought to behave when  
verifying DKIM signatures. MUAs have a much harder time because DKIM  
is an on-line protocol and there are many times that MUAs are off-line.

	Jon

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 17 Apr 2006 23:24:53 -0700

Expiry is a reason for bounfing mail??????

Which document are you reading there? Expired sig equals unsigned at worst.

Expired sig plus other factors might lead to bounce, for example. A transport layer verifier that sees a three week old message.... But a client app refusing access to an expired message is the type of idiocy we are trying to get away from.

 -----Original Message-----
From: 	Douglas Otis [mailto:[email-masked]]
Sent:	Mon Apr 17 16:33:19 2006
To:	Jon Callas
Cc:	ietf-dkim WG
Subject:	Re: [ietf-dkim] Proposal: Do the semantics first, then straw poll

On Apr 17, 2006, at 2:24 PM, Jon Callas wrote:
> On 17 Apr 2006, at 1:39 PM, Douglas Otis wrote:
>
> Nonetheless, your comments about bounce exploits are orthogonal to  
> my comments about limiting the scope of signatures in the paragraph  
> below.

When expiry becomes a reason for rejecting a message, as advocated in  
the SSP draft, then x= allows per second tuning of message expiry.   
This ability to time each message to the second enables a rather  
trivial bounce exploit.  A bad actor could easily ensure down stream  
rejection to induce message bounces.  DKIM says nothing about the  
validity of the bounce address, but nevertheless an x= may cause the  
message to be bounced to that location.  As such, this exploit is not  
orthogonal to how x= might be used, it is only orthogonal to how you  
would expect x= to be used.

> I never said anything about "replay exploits."  As I understand  
> what you mean about "replay exploits," they'll have to be something  
> else we have to agree to disagree on because I think they are  
> neither replays (as I would use the term as a cryptographer) nor  
> exploits. The opportunity for this situation exists without DKIM,  
> and in my opinion DKIM makes it less desirable for the malicious  
> user of this technique.

Exploitation of DKIM will not exist, provided a valid DKIM signature  
NEVER improves message acceptance.

The advantage afforded replaying a DKIM signed message only exists  
with a DKIM signature verifying.

Are you suggesting DKIM will never improve message acceptance?

>>>  But when it comes down to brass tacks, some weird combination of  
>>> SSP, BCP, receiver filtering/delivery policy and so on is going  
>>> to come into play, but *only* *when* *an* *abrupt* key change  
>>> takes place.
>>
>> This would only be true if x= were removed.
>
> No, it happens no matter what. Let's suppose my DKIM signer gets  
> owned. I'm going to yank that key out of the DNS. Some number of  
> messages, the ones in the cloud as it were, are not going to be  
> able to be verified. I'm going to eat the cost of that. I have to.

You are not describing a scenario where one system considers the same  
message rejected due to expiry, whereas an immediately preceding  
system considered the message not expired a few seconds earlier.

> Also, let's consider another case, where I have an x= of a week.  
> Let's suppose that I've been using a new key for 6 days and for  
> whatever reason, I want to pull the old key out of DNS. That's my  
> call, and whatever consequences there are to this action only  
> affect the messages that have been in the cloud for 6 days without  
> delivery.

Again, simple revocation of the key was not the concern, although  
blanking or pulling keys is not a good method to handle some pressing  
problems.  Whether the replay issue ever becomes a concern, DKIM  
should strive to ensure key management causes little message  
disruption.  There should be three states for keys, Active, Revoked,  
and Retired.  Active/Revoked is already defined.  The Retired key  
status could be used to ensure verification is not disrupted at the  
MUA, where timing is less certain.  If the private portion of the key  
has been compromised or misused, revocation would be desired.  A  
Revoked key would indicate to the recipient the sender desires the  
message to be silently discarded when first received at the MDA, and  
that all received messages with this key should be considered far  
less trustworthy.  A Key Retired state could cause the message to be  
refused at the MDA, and yet still afford additional weeks for the MUA  
to verify the message where the public portion of the key is still  
available.  Moving key status to the key, rather than at the message  
with x= is not growing hair.  It is simply placing the hair where it  
belongs.

> (I know you're going to bring up the issue of MUAs. I consider DKIM  
> to be an MTA-to-MTA system. MUAs are free to use it, too -- who's  
> going to stop them? But an MUA that has DKIM support has to deal  
> with a very different environment. I might on my MUA have no  
> connectivity. I might have pseudo-connectivity (for example, in a  
> wireless hotspot, but not authenticated to it). The MUA must cope.  
> It can't suddenly decide that messages are suspicious just because  
> t-mobile is blackholing its DNS requests.)

Where MUAs have DNS access, DKIM offers protection over this portion  
of the transport.  Until the message is reviewed by the recipient,  
DKIM protections remain relevant well beyond SMTP.  There seems  
little justification to discount the duration a key should remain  
available at the MUA.  A retirement flag added to a key could signal  
an MDA to reject these messages, without the need to pull the key  
entirely.

>>> In the normal, running environment, it doesn't matter whether we  
>>> have x= or not.
>>
>> For a safe running environment, not having x= causing exploits  
>> would be important.  The safe alternative would a retirement date  
>> published with the key.
>
> We have to disagree. I believe that it is a feature that this is a  
> key-centric system. Either the key is in DNS, or it's not. That's  
> simple.

The state of the verification should be at the key and not at the  
message.

> Additionally, as I said, every proposal I've heard for removing x=  
> creates more hair than there is with x=. If we just removed it, I'd  
> be in favor of it, but that's not what the suggestions have been.  
> So I voted for keeping the thing I understand rather than replace  
> it with something I don't.

How does one void the problems caused by a bounce exploit, except to  
say it will not happen?  What justification is there for not  
protecting the message path beyond the MDA?

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Tue, 18 Apr 2006 09:32:45 -0700

On Apr 17, 2006, at 11:24 PM, Hallam-Baker, Phillip wrote:

> Expiry is a reason for bouncing mail??????
>
> Expired sig plus other factors might lead to bounce, for example. A  
> transport layer verifier that sees a three week old message.... But  
> a client app refusing access to an expired message is the type of  
> idiocy we are trying to get away from.

Indeed.  A signing-domain may report all messages have a valid  
signature.  A verifier may act upon that information and reject all  
messages purported to be from _that_ domain without a valid  
signature.  An expired signature is defined as _not_ being valid.

As you suggested, there is the required message date, but purpose of  
the date is _not_ to change the validity of the signature.

base-01:
,---
| It is beyond the scope of this specification to describe what actions
| a verifier system should make...
|
| 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
'---

Explain the purpose of the expiry x= parameter in the signature  
header field.

If expiration is about the key, include this information within the  
key.   By having an expiry within the key, the key could remain  
available for post SMTP verifications, while also curtailing SMTP  
transport acceptance of "stale" messages.  Unlike the x= parameter  
within the signature, when the expiry is within the key, a continuous  
stream of "just-about-to-expire" messages would be far more difficult  
stage.

-Doug