Re: [ietf-dkim] Proposal: Do the semantics first, then straw poll
2006-04-17 13:41:32
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.
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
_______________________________________________
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,
Douglas Otis <=
- 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
|
|
|