On May 22, 2009, at 11:40 PM, John Levine wrote:
When the body of the message has an open-ended length, the number
of attempts to produce a collision might be within what now seems
like a small number of attempts.
If SHA256 is that weak, we have worse problems than spoofed DKIM
When the body of the message has an open-ended length, the number of
attempts to produce a collision might be within what now seems like a
small number of attempts.
If SHA256 is that weak, we have worse problems than spoofed DKIM messages.
Fortunately, nobody I know in the crypto community
On May 21, 2009, at 10:30 PM, Eliot Lear wrote:
My recollection of the debate about l= is that there were about as
many theories about the point of l= as there were people promoting
it. The main theory I remember was about hypothetical mailing
lists that were too incompetent to filter
My recollection of the debate about l= is that there were about as
many theories about the point of l= as there were people promoting it.
The main theory I remember was about hypothetical mailing lists that
were too incompetent to filter incoming spam so the list recipients
would do it based
One of the reasons l= came to be was that we wanted to have as many
valid signatures out there as quickly as possible, so as to provide a
reasonable alternative basis for reputation. There was the presumption
that the mailing list software would lag, and it has. Now we know that
one MAJOR
One of the reasons l= came to be was that we wanted to have as many valid
signatures out there as quickly as possible, so as to provide a reasonable
alternative basis for reputation. There was the presumption that the mailing
list software would lag, and it has. Now we know that one MAJOR
On Thu, 21 May 2009 17:08:12 +0100, Dave CROCKER d...@dcrocker.net wrote:
Eliot Lear wrote:
On 5/21/09 5:45 PM, Dave CROCKER wrote:
There is no concept of responsibility for information behond l=.
Sure there is. It is simply unsigned beyond the value of l=.
You appear to be confusing the
Surely you do not suppose that a signature which covers only the From
header (and that is a perfectly valis signature according to the
document) is to be accepted as equally valuable to a signature that
covers everything.
Probably not, but that's because a dimwit who puts on cruddy
signatures is
On May 22, 2009, at 5:31 PM, John Levine wrote:
Surely you do not suppose that a signature which covers only the
From header (and that is a perfectly valis signature according to
the document) is to be accepted as equally valuable to a signature
that covers everything.
Probably not,
On Wed, 20 May 2009 17:55:53 +0100, Dave CROCKER d...@dcrocker.net wrote:
Steve Atkins wrote:
It means that I can, for example, take one copy of a service notice
from my bank, leave the headers the same and replace the URLs
in the body of the message to links to my website, then send it
out
Steve,
I find your arguments largely unconvincing.
Firstly, one expressed use case for l= is l=0 - in other words, don't
sign any of the body. In that case I can put any body content in there
I like, and it'll still be validly signed.
There are specific applications for such a case,
On 5/20/09 11:42 PM, Murray S. Kucherawy wrote:
Indeed, Outlook will opt to render an HTML part over a text part whenever
given the choice. Thus, if you sign only the text/plain portion of a
message and an attacker appends a text/html part, the unsigned HTML
version will be rendered even if
Eliot Lear wrote:
The whole point of l= was to say that beyond it you should treat the
content as suspicious.
Eliot,
Since DKIM Signature does not make statements about the differential handling
of
content, signed or unsigned, I'm not clear what you base this assertion on.
Can
you
On 5/21/09 4:45 PM, Dave CROCKER wrote:
Eliot Lear wrote:
The whole point of l= was to say that beyond it you should treat the
content as suspicious.
Eliot,
Since DKIM Signature does not make statements about the differential
handling of content, signed or unsigned, I'm not clear what
Eliot Lear wrote:
On 5/21/09 4:45 PM, Dave CROCKER wrote:
I think the point is that you can't make assertions of responsibility
for the information beyond l=.
Eliot,
But with respect to assertions about a message, DKIM only has
valid-vs-unsigned.
There is no concept of responsibility
On 5/21/09 5:45 PM, Dave CROCKER wrote:
Eliot Lear wrote:
On 5/21/09 4:45 PM, Dave CROCKER wrote:
I think the point is that you can't make assertions of responsibility
for the information beyond l=.
Eliot,
But with respect to assertions about a message, DKIM only has
Eliot Lear wrote:
On 5/21/09 5:45 PM, Dave CROCKER wrote:
There is no concept of responsibility for information behond l=.
Sure there is. It is simply unsigned beyond the value of l=.
You appear to be confusing the difference between the internals of how DKIM
determines whether there is
Dave CROCKER wrote:
Eliot Lear wrote:
On 5/21/09 4:45 PM, Dave CROCKER wrote:
I think the point is that you can't make assertions of responsibility
for the information beyond l=.
Eliot,
But with respect to assertions about a message, DKIM only has
valid-vs-unsigned.
Dave CROCKER wrote:
And by the way, my original question was about who is using the feature and
finding it valuable. Not about theoretical scenarios, but experience based
on
two years of possible use.
The archives are your friends. This has been stated innumerable times
with real-life
Wietse Venema wrote:
signed and invalid
unsigned
This distinction helps the bad guys/gals, and hurts the good guys/gals.
Thats an opinion and not one based on any engineering proof.
The fact is, the value of DKIM will be realized on anonymous
transactions when you don't know
On 5/21/09 6:08 PM, Dave CROCKER wrote:
I believe this was explicitly stated elsewhere, like on this list.
But that's not in the spec.
That's because the topic of what a verifier does with a message was
probably viewed as out of scope. But that doesn't imply, as you agreed,
that the
On May 21, 2009, at 10:43 AM, Eliot Lear wrote:
And see my other message. I also question the value of l=. All I
was trying to say here was that the risks are well documented and
easily mitigated.
Agreed.
There are many areas beyond the scope of DKIM that might be of similar
+1
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On
Behalf Of Dave CROCKER
Sent: Thursday, May 21, 2009 10:45 AM
To: Eliot Lear
Cc: DKIM WG
Subject: Re: [ietf-dkim] Features that could be reconsidered as part of the bis
process
Eliot
Hector Santos:
Wietse Venema wrote:
signed and invalid
unsigned
This distinction helps the bad guys/gals, and hurts the good guys/gals.
Thats an opinion and not one based on any engineering proof.
The fact is, the value of DKIM will be realized on anonymous
Wietse Venema wrote:
To me, this is the REAL BIS material that should be reevaluated,
because to me, that is one of the barriers to adoption.
I rest my case.
DKIM's pathetic state is your case.
--
Sincerely
Hector Santos
http://www.santronics.com
I find your arguments largely unconvincing.
Firstly, one expressed use case for l= is l=0 - in other words, don't
sign any of the body. In that case I can put any body content in there
I like, and it'll still be validly signed.
There are specific applications for such a case, and most of them
On 5/22/09 12:40 AM, John Levine wrote:
I don't get it. Yes, if you don't care about the body of a message,
using l=0 is mostly (not entirely) harmless, but I don't see that it
solves any problem. What's the advantage of using l=0 versus signing
the message the usual way? The speed
Steve Atkins wrote:
If a signer uses l=0 (or, given MIME games that can
be played, any other l= value) then the only thing you can say
about any validly signed message from that sender is that
the subject line of the message is the same as the subject line
of a message that sender signed. I
On May 20, 2009, at 9:55 AM, Dave CROCKER wrote:
Steve Atkins wrote:
If a signer uses l=0 (or, given MIME games that can be played, any
other l= value) then the only thing you can say about any validly
signed message from that sender is that the subject line of the
message is the same
On May 20, 2009, at 12:10 PM, Douglas Otis wrote:
Since email must deal with large amounts of spam and abuse, it would
be good to have provisions in DKIM that allow secured attachments to
be excluded from the DKIM hash algorithm without causing the entire
message to be considered unsigned
Steve Atkins wrote:
Why would you want to sign email as something you vouched for,
while still enabling anyone to replace the content of the email
with something else without invalidating that signature?
You can't replace it; you can only append to it.
Mike
Steve Atkins wrote:
On May 20, 2009, at 12:10 PM, Douglas Otis wrote:
Since email must deal with large amounts of spam and abuse, it would
be good to have provisions in DKIM that allow secured attachments to
be excluded from the DKIM hash algorithm without causing the entire
message to be
On May 20, 2009, at 2:17 PM, Michael Thomas wrote:
Steve Atkins wrote:
Why would you want to sign email as something you vouched for,
while still enabling anyone to replace the content of the email
with something else without invalidating that signature?
You can't replace it; you can only
Steve Atkins wrote:
On May 20, 2009, at 2:17 PM, Michael Thomas wrote:
Steve Atkins wrote:
Why would you want to sign email as something you vouched for,
while still enabling anyone to replace the content of the email
with something else without invalidating that signature?
You can't
On Wed, 20 May 2009, Steve Atkins wrote:
Another use case is to use l= to sign a text part of an email, but not
to sign an attachment. In that case I can obviously replace the
attachment with my own content, but depending on the details of the
email structure I may well be able to replace
On May 20, 2009, at 2:53 PM, Michael Thomas wrote:
Steve Atkins wrote:
On May 20, 2009, at 2:17 PM, Michael Thomas wrote:
Steve Atkins wrote:
Why would you want to sign email as something you vouched for,
while still enabling anyone to replace the content of the email
with something else
Murray S. Kucherawy wrote:
Indeed, Outlook will opt to render an HTML part over a text part whenever
given the choice. Thus, if you sign only the text/plain portion [...]
Seriously: how signers and receivers use DKIM information is WAY
outside of the scope of this working group. To read the
Steve Atkins wrote:
Remember that we're considering the content of the message as
displayed to the end user here,
No we're not. That has never been in the scope of the DKIM effort.
(though the supposed benefit it offers is not clear)
You forgot to me.
Not really. I don't think the
On May 20, 2009, at 3:57 PM, Michael Thomas wrote:
Steve Atkins wrote:
Remember that we're considering the content of the message as
displayed to the end user here,
No we're not. That has never been in the scope of the DKIM effort.
Even if it weren't section 8.1 of the existing RFC,
Steve Atkins wrote:
On May 20, 2009, at 3:57 PM, Michael Thomas wrote:
Steve Atkins wrote:
Remember that we're considering the content of the message as
displayed to the end user here,
No we're not. That has never been in the scope of the DKIM effort.
Even if it weren't section 8.1
On May 20, 2009, at 4:31 PM, Michael Thomas wrote:
Steve Atkins wrote:
On May 20, 2009, at 3:57 PM, Michael Thomas wrote:
Steve Atkins wrote:
Remember that we're considering the content of the message as
displayed to the end user here,
No we're not. That has never been in the scope of
Steve Atkins wrote:
On May 20, 2009, at 4:31 PM, Michael Thomas wrote:
Steve Atkins wrote:
On May 20, 2009, at 3:57 PM, Michael Thomas wrote:
Steve Atkins wrote:
Remember that we're considering the content of the message as
displayed to the end user here,
No we're not. That has never
On May 20, 2009, at 2:42 PM, Murray S. Kucherawy wrote:
On Wed, 20 May 2009, Steve Atkins wrote:
Another use case is to use l= to sign a text part of an email, but
not to sign an attachment. In that case I can obviously replace the
attachment with my own content, but depending on the
Hi Steve,
At 15:41 20-05-2009, Steve Atkins wrote:
Remember that we're considering the content of the message as
displayed to the end user here, not the traffic on the wire. If I can
control the content of the message as it's displayed to the recipient,
then the fact that I only have limited
Steve Atkins wrote:
On May 20, 2009, at 4:31 PM, Michael Thomas wrote:
That's all DKIM guarantees. It's
not in DKIM's scope to tell mail receivers what to do with the
message, signed text or otherwise. Stupid receivers are free as
always
to do stupid things. Smart receivers are free
l: Body length count
Despite the warnings we've posted about it, at least one site has
contributed patches to our implementation that extends its basic utility.
That means there's at least a little demand for its use.
Any idea what they're doing with it? Having added some support for
DKIM
l: Body length count ...
Signing the body is not essential for the primary purpose of DKIM, which
is to expose phishers and the like. Malicious modification of a message
_after_ is has been posted is relatively rare.
Aw, come on. If the Bank of X were to send out mail with only the
On 5/11/09 5:09 PM, Steve Atkins wrote:
On May 11, 2009, at 3:55 AM, Charles Lindsey wrote:
On Sat, 09 May 2009 21:08:33 +0100, Steve Atkinsst...@wordtothewise.com
wrote:
l: Body length count
This opens up a whole host of security issues, related to being
On May 11, 2009, at 8:29 AM, Eliot Lear wrote:
On 5/11/09 5:09 PM, Steve Atkins wrote:
On May 11, 2009, at 3:55 AM, Charles Lindsey wrote:
I could conceivably see this being an issue on an acm.org style
forwarder,
if there were one that modified the content it forwarded, but not a
normal
Mark Delany wrote:
DKIM-Signature Header tags
x: Signature expiration
l: Body length count
Removal of these would be a show stopper for me. In fact, overall,
anything that is SECURITY related should be protected from removal
proposal.
Do you mean anything that is security
On Sat, 9 May 2009, Steve Atkins wrote:
q: List of query methods
I don't think q= is going to be controversial either, but I'm
mentioning it separately as it currently only has one value, the
default, it's unlikely to be extended, and if it were it would require
a whole new RFC to do
Murray S. Kucherawy wrote:
I'd rather leave an unused
but potentially useful hook in there versus removing it now only to have
it added back in later, possibly poorly.
Murray, this is an absolutely basic bit of philosophy in protocol design. It
drives lots of decisions.
On May 9, 2009, at 10:03 AM, Steve Atkins wrote:
On May 9, 2009, at 8:10 AM, Hector Santos wrote:
John Levine wrote:
with some editorial changes I guess. I've not seen anyone
suggest that we add features or remove a raft of features
or make other substantial changes.
I'm with Steve, I'd
Good starting point list.
Steve Atkins wrote:
Summary of features to consider dropping
DKIM-Signature Header tags
x: Signature expiration
l: Body length count
Removal of these would be a show stopper for me. In fact, overall,
DKIM-Signature Header tags
x: Signature expiration
l: Body length count
Removal of these would be a show stopper for me. In fact, overall,
anything that is SECURITY related should be protected from removal
proposal.
Do you mean anything that is security related or do you mean
55 matches
Mail list logo
