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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 13 Apr 2006 11:22:20 -0700

It seems to me that several people who are arguing to kill = ae essentially
aguing that it has the same semantics that I beleive are the strongest that
can be attached to x= and conclude that these semantics are not suficient to
justify inclusion. Others argue that the semantics are ambiguous and it
should go which is not so far from saying the semantics are clear, just
different to the ones presented.
 
I suggest then that we take a quaker poll type approach and put in the full
range of options rather than require people to commit now to a yes/no vote.
The range of options I see is:
 
1) Keep x=, signers should be able to limit the time period in which the
accept resonsibility
 
2) Keep x=, signers should be able to state in the signature that they won't
support the key retrieval indefinitely.
 
3) Delete x=, the semantics are ambiguous, people think of it as message
revocation, they should not
 
4) Delete x=, signers can state the key support interval in SSP
 
5) Delete x=, time in seconds since 1970s invites 32 bit Y2K type issues
 
6) Other reasons
 
My prefered options are 2 and 4 equally. I reject 1. I can live with 3 or 5.

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Apr 2006 19:58:41 +0100

Phill,

Let's do one thing at a time. After we see if there's a strong
consensus with the current straw poll, then we can see what's
next, and that might involve some of the more detailed options
you outline.

You all still have until Tuesday to express an opinion (or
another one),

Stephen.

(Apologies if you get two of these.)

Hallam-Baker, Phillip wrote:
> It seems to me that several people who are arguing to kill = ae 
> essentially aguing that it has the same semantics that I beleive are the 
> strongest that can be attached to x= and conclude that these semantics 
> are not suficient to justify inclusion. Others argue that the semantics 
> are ambiguous and it should go which is not so far from saying the 
> semantics are clear, just different to the ones presented.
>  
> I suggest then that we take a quaker poll type approach and put in the 
> full range of options rather than require people to commit now to a 
> yes/no vote. The range of options I see is:
>  
> 2) Keep x=, signers should be able to state in the signature that they 
> won't support the key retrieval indefinitely.
>  
> ------------------------------------------------------------------------
>

---

From: Tony Hansen <[email-masked]>
Date: Thu, 13 Apr 2006 23:41:52 -0400

Minor nit: #5 doesn't apply because it's explicitly required to use up
to 40 bits.

	Tony Hansen
	[email-masked]

---

From: Mark Delany <[email-masked]>
Date: Fri, 14 Apr 2006 04:32:23 +0000

> Minor nit: #5 doesn't apply because it's explicitly required to use up

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.

It might be my bias as much of what I do doesn't fit into 32bits, but
at most I would expect non-normative text alerting implementors to the
fact that conversion to binary should be cognizant of the fact that
the value will likely exceed the capacity of a 32bit int.

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

> > 5) Delete x=, time in seconds since 1970s invites 32 bit Y2K type issues

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?

Alternatively, if it's a fuzzy value, make it fractional: x=12345.678
to similarly force the issue.

Apropos the subject line; I think that's precisely the problem with x=
and t=. They're a solution looking for a problem as is obvious from
the variety of interpretations on how they *might* be used. Defining
the problem first should be apple pie.

Mark.

---

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

----- Original Message -----
From: "Mark Delany" <[email-masked]>

> to similarly force the issue.

How about date format like?

    x=yyyymm[dd[hh[ss]]]

Minimum 4 characters, year and month.  Day, hour, seconds, optional.   Most
likely most expirations will be to the day or hour, so x=yyyymmddhh would be
sufficient for most needs.

This will also be easier to read for diagnostics when eyeballing.

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

---

From: Jon Callas <[email-masked]>
Date: Mon, 17 Apr 2006 12:11:18 -0700

I'm somewhat similar to you, Phill, as I can equally support keeping  
or removing x=. I think that x= is basically a Good Thing. On the  
other hand, removing it wouldn't be so bad, either. I voted to keep  
in the straw poll primarily because it seems that we can't *just*  
remove it, we have to remove it and then add in other stuff. That  
other stuff makes my head hurt.

I think that one underlying semantic issue we're dealing with is the  
desire some people have to turn this all into a huge Internet-wide  
finite state automaton, and that's neither a good idea nor possible.

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. I also  
believe that it is a Good Thing that DKIM is not an archival  
signature system for many privacy-related reasons that are tangential  
to this discussion, and x= kinda sorta helps.

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. The  
answer is that some messages now won't verify, which means they are  
"suspicious" which interacts with SSP and other things to make it so  
that some message might be flagged, filed, rejected or whatever in  
ways that they would not have had I left the key there. This is  
merely reality. It's not a big deal. It can be described in BCP  
documents, HowTos, and so on.

Getting rid of x= is a good thing because getting rid of it doesn't  
change the squishiness, it just makes it more obvious. There are  
going to be some keys that will be around essentially forever, and  
some that will be somewhat ephemeral. (Ironically, the signatures you  
least care about -- like the ones coming from my personal domain --  
are going to be the ones most stable.) 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. In the normal, running  
environment, it doesn't matter whether we have x= or not.

And this is why I both don't care whether we have it or not and think  
we should keep it. When push comes to shove, it's going to be the  
practices around edge situations that matter. x= has goodness, and  
the proposals to remove it have more hair and seem to be more complex  
than keeping it.

	Jon

---

From: Douglas Otis <[email-masked]>
Date: Mon, 17 Apr 2006 13:39:01 -0700

On Apr 17, 2006, at 12:11 PM, Jon Callas wrote:

> keys every time they change what mail server they're using. This  
> key will have a years-long, if not decades-long life.

x= is a bad thing, as it allows bounce exploit timing to be tuned per  
message.  Those that find themselves handling messages they accepted,  
but then can not deliver due to the down-stream system not accepting  
messages with too little remaining expiry time, may then lead to an  
ever escalating amount of time being required for acceptance.

> Using x= lets them blow off bit rot in messages that they are  
> "responsible" for. I also believe that it is a Good Thing that DKIM  
> is not an archival signature system for many privacy-related  
> reasons that are tangential to this discussion, and x= kinda sorta  
> helps.

The x= will not offer a significant reduction in replay exploits.   
The x= time window will need to be large enough to ensure delivery,  
which does not impose a substantial burden for bad actors who burn  
accounts as their cost of doing business.  Handling that rejects a  
message 1 second past expiration will induce a worse problem than  
would a replay exploit.  Bounced expirations from reputable sources  
will require a secondary reputation be ascertained (after the DATA)  
phase by checking unsigned message Received headers.  How does expiry  
reduce the burden or limit the accountably?

It would be better to have a mechanism that can be used to silently  
discard messages when so identified by the sender as having been  
revoked.  There should be a separate status for retired keys  
however.   If the desire is to have lazy key management, then have  
keys marked as being retired at some time.  Stopping using these keys  
some number of weeks before this retirement date.  Publish enough  
keys to handle the next few years of email signing, and simply change  
the selector on a schedule.

>  It can be described in BCP documents, HowTos, and so on.

How is this problem avoided by special handling, when a finely tuned  
per message expiration is a basis for rejection by some servers?

>  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.

> 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.

-Doug

---

From: Jon Callas <[email-masked]>
Date: Mon, 17 Apr 2006 14:24:19 -0700

On 17 Apr 2006, at 1:39 PM, Douglas Otis 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.
>
> x= is a bad thing, as it allows bounce exploit timing to be tuned  
> per message.  Those that find themselves handling messages they  
> accepted, but then can not deliver due to the down-stream system  
> not accepting messages with too little remaining expiry time, may  
> then lead to an ever escalating amount of time being required for  
> acceptance.
>

We're going to have to agree to disagree on this, Doug. I believe I  
must apologize because I started into an exposition of balancing  
sides of this. It's an "on the one hand A, on the other B"  
presentation. I wasn't explicit. I'm sorry.

Nonetheless, your comments about bounce exploits are orthogonal to my  
comments about limiting the scope of signatures in the paragraph below.

>> "responsible" for. I also believe that it is a Good Thing that  
>> DKIM is not an archival signature system for many privacy-related  
> phase by checking unsigned message Received headers.  How does  
> expiry reduce the burden or limit the accountably?
>
> keys marked as being retired at some time.  Stopping using these  
> keys some number of weeks before this retirement date.  Publish  
> enough keys to handle the next few years of email signing, and  
> simply change the selector on a schedule.
>

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.

> How is this problem avoided by special handling, when a finely  
> tuned per message expiration is a basis for rejection by some servers?
>
>

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.

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.

(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.)

> 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.

  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.

	Jon

---

From: Dave Crocker <[email-masked]>
Date: Mon, 17 Apr 2006 16:05:51 -0700

Paul Hoffman wrote:
>> (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,

No, it is not.

It is strictly about the availability of the public key.

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: Mon, 17 Apr 2006 14:58:40 -0700

At 12:11 PM -0700 4/17/06, Jon Callas wrote:
>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?

>(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.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Mon, 17 Apr 2006 16:18:40 -0700

On Apr 17, 2006, at 2:24 PM, Jon Callas 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?

>>> SSP, BCP, receiver filtering/delivery policy and so on is going  
>>> to come into play, but *only* *when* *an* *abrupt* key change  
>>> takes place.
>>
> 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.

> 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.

> 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.

> key-centric system. Either the key is in DNS, or it's not. That's  

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

> 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: Paul Hoffman <[email-masked]>
Date: Mon, 17 Apr 2006 16:21:15 -0700

At 4:05 PM -0700 4/17/06, Dave Crocker wrote:
>>x= is an expiration for a particular statement of responsibility 
>>for a message,
>
>
>No, it is not.
>

Where in the document does it say that? The semantics in the document 
are "Signatures MUST NOT be considered valid if the current time at 
the verifier is past the expiration date."
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jon Callas <[email-masked]>
Date: Mon, 17 Apr 2006 18:21:04 -0700

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

>> 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."

> 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: Paul Hoffman <[email-masked]>
Date: Mon, 17 Apr 2006 19:12:38 -0700

At 6:21 PM -0700 4/17/06, Jon Callas wrote:
>responsibility (whatever that means).

What the heck does it mean to be responsible for sending a message at 
this time, then five minutes later (and then forevermore) to not be 
responsible? What external condition could cause this chain of 
events? I ask this because I'm seriously not getting it.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Tue, 18 Apr 2006 08:49:29 -0700

Jon Callas wrote:
> (e.g.) a month and I decide out of the blue to change keys. The answer
> is that some messages now won't verify, which means they are
> ways that they would not have had I left the key there.
Just to keep the use of the term focused, "suspicious" is a possible
result of the SSP check.  The way we have been using the term, a message
would become suspicious if the signature that won't verify causes the
SSP check to fail (e.g., the originating address's domain says it signs
all messages).

I'm not trying to start an SSP discussion here -- merely trying to
reserve the term "suspicious" for when we do.

-Jim