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

[Douglas Otis]

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