Re: [ietf-dkim] Proposal: Do the semantics first, then straw poll
2006-04-17 14:35:58
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [ietf-dkim] Proposal: Do the semantics first, then straw poll, Hallam-Baker, Phillip
- Re: [ietf-dkim] Proposal: Do the semantics first, then straw poll, Stephen Farrell
- Re: [ietf-dkim] Proposal: Do the semantics first, then straw poll, Tony Hansen
- Re: [ietf-dkim] Proposal: Do the semantics first, then straw poll, Jon Callas
- Re: [ietf-dkim] Proposal: Do the semantics first, then straw poll, Paul Hoffman
- Re: [ietf-dkim] Proposal: Do the semantics first, then straw poll, Jon Callas
- Re: [ietf-dkim] Proposal: Do the semantics first, then straw poll, Paul Hoffman
Re: [ietf-dkim] Proposal: Do the semantics first, then straw poll, Jim Fenton
|
|
|