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 communit
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.
>
> Proba
>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
On Thu, 21 May 2009 17:08:12 +0100, Dave CROCKER 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 di
> 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 MA
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 pie
>> 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
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
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 diffe
>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 m
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
_
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 anony
+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
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
conc
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
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 k
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
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.
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 t
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
> v
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 "responsibil
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 no
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 cl
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 i
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 cas
On Wed, 20 May 2009 17:55:53 +0100, Dave CROCKER 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 to a hun
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
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 co
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 t
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
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
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
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 R
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
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
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
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 replac
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?
>> Y
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 c
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
>> mess
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
_
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
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
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 signe
On May 11, 2009, at 3:55 AM, Charles Lindsey wrote:
> On Sat, 09 May 2009 21:08:33 +0100, Steve Atkins >
> wrote:
>
>>i: Additional information about the identity of the user or
>> agent for which this message was signed
>>
>> This one is more controversial. It adds an awful lot of complex
On Mon, 11 May 2009, J.D. Falk wrote:
> +1 to dropping these, though I'm willing to be convinced otherwise if
> there are verifiers actively using them to make policy decisions --
> particularly z=.
I can't imagine using "z=" as an input to a policy decision. I've only
found it useful when deb
Steve Atkins wrote:
> Summary of features to keep
+1 to keeping these.
> Summary of features to consider dropping
+1 to dropping these, though I'm willing to be convinced otherwise if there
are verifiers actively using them to make policy decisions -- particularly z=.
--
J.D. Falk
Return Pat
On Mon, 11 May 2009, John Levine wrote:
> Any idea what they're doing with it? Having added some support for DKIM
> to majordomo2, I am more convinced than ever that the motivation for l=,
> list recipients will filter list mail using the contributor's signature
> rather than the list signature
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 n
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 Atkins>
>>>
>> wrote:
>>
>>
>>> l: Body length count
>>>
>>> This opens up a whole host of security issues, related to being ab
On May 11, 2009, at 3:55 AM, Charles Lindsey wrote:
> On Sat, 09 May 2009 21:08:33 +0100, Steve Atkins >
> wrote:
>
>>
>> l: Body length count
>>
>> This opens up a whole host of security issues, related to being able
>> to change the rendered content of the message entirely after signing
>>
>> 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 th
On Sat, 09 May 2009 21:08:33 +0100, Steve Atkins
wrote:
> i: Additional information about the identity of the user or agent
> for which this message was signed
>
> This one is more controversial. It adds an awful lot of complexity and
> confusion about the semantics of what a signature is
>> 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
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.
Unfortunate
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 d
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 tha
>> 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
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,
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.
>>>
>
61 matches
Mail list logo
