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

[Jon Callas]

On 17 Apr 2006, at 1:39 PM, Douglas Otis wrote:

>
> On Apr 17, 2006, at 12:11 PM, 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.
>
> 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.

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

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.

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

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

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

  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