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:dotis(_at_)mail-abuse(_dot_)org]
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html