On 7/12/11 12:02 PM, Charles Lindsey wrote:
Essentially, my concern is that an implementor reading this section should
be able to infer the nature of the particular attack I have described (the
one where the signer is the BadGuy himself using a throwaway domain),
including spotting how and why
On Mon, 11 Jul 2011 05:53:58 +0100, Murray S. Kucherawy
m...@cloudmark.com wrote:
Actually, let me revise that a bit:
Agents that evaluate or apply DKIM output need to be aware that a DKIM
signer can sign messages that are malformed (e.g., violate RFC5322), or
become malformed in
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Charles Lindsey
Sent: Monday, July 11, 2011 3:52 AM
To: DKIM
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
Agents that evaluate or apply DKIM
On Jul 11, 2011, at 6:56 AM, Murray S. Kucherawy wrote:
Given that today's the deadline, we will have to go with something like this
or nothing at all (which in fact I would prefer because I think all of this
is adequately covered by existing text, and I believe consensus and the AD
On Fri, 08 Jul 2011 18:51:39 +0100, Pete Resnick presn...@qualcomm.com
wrote:
I want to try to be precise, which I don't think Charles is being with
his below two sets of facts. Let me try to clarify:
On 7/8/11 5:52 AM, Charles Lindsey wrote:
1. The fact that DKIM choose headers to sign
Why not just keep it simple, less confusing, less challenging on
competing mind games, that DKIM can't not fully protect again unsigned
Author Addresses and its highly recommendation that DKIM signers,
verifiers and Mail Readers to kick out, reject, destroy, do not pass
on these sort of
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Charles Lindsey
Sent: Sunday, July 10, 2011 6:00 AM
To: DKIM
Cc: Pete Resnick
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
Implementors
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Murray S. Kucherawy
Sent: Sunday, July 10, 2011 8:39 PM
To: Charles Lindsey; DKIM
Cc: Pete Resnick
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
On Thu, 07 Jul 2011 18:09:14 +0100, Pete Resnick presn...@qualcomm.com
wrote:
I am perfectly happy with Murray's original (and now, revised) text.
(Nits still being discussed are entirely up to the WG.) I am not happy
with Charles's text. Particularly:
On 7/7/11 5:08 AM, Charles Lindsey
On Thu, 07 Jul 2011 22:06:29 +0100, Murray S. Kucherawy
m...@cloudmark.com wrote:
My favourite counterexample, which I've used many times already, is
Mailman. It doesn't even check DKIM signatures, but you can still fake
your way through its authorization process such that a different
On 07/Jul/11 16:13, Dave CROCKER wrote:
On 7/7/2011 6:57 AM, Murray S. Kucherawy wrote:
I'd s/to be liberal/to be exceedingly liberal/ (we don't want to revise
Postel's statement, do we?)
You're either liberal in your application of the RFCs, or you're not. I
don't see how adding that word
-Original Message-
From: John Levine [mailto:jo...@iecc.com]
Sent: Thursday, July 07, 2011 6:22 PM
Will your assume one more From than listed in h= lead to failed
verifications on messages that actually follow the advice in the RFC to
list duplicate headers in their h= values?
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Charles Lindsey
Sent: Friday, July 08, 2011 3:59 AM
To: DKIM
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
My favourite counterexample, which
On 7/8/2011 6:48 AM, Murray S. Kucherawy wrote:
If DKIM is not intended to give added credance to messages, then what on
earth is its purpose at all.
That question is answered numerous times in the draft, namely the Abstract
and Sections 1, 1.2, 1.5, 2.5, 2.7, 3.9, 3.11, 6.3, and 8.15 (and
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Charles Lindsey
Sent: Friday, July 08, 2011 3:52 AM
To: DKIM
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
1. The fact that DKIM choose headers
On 7/8/2011 6:54 AM, Murray S. Kucherawy wrote:
That's not part of what DKIM tells an assessor, nor is the list of signed
header fields, so I don't see why that would be a useful thing to highlight.
For example, if a message contains two Subject: fields, the assessor doesn't
know which
On Fri, 08 Jul 2011 13:05:49 +0100, McDowell, Brett
bmcdow...@paypal-inc.com wrote:
John, this particular part of the discussion is not about changing the
RFC or DKIM implementations, only changing deployment configuration
practices.
Exactly so. All I am trying to do is to ensure that
On Fri, 08 Jul 2011 14:54:43 +0100, Murray S. Kucherawy
m...@cloudmark.com wrote:
-Original Message-
[mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey
Sent: Friday, July 08, 2011 3:52 AM
1. The fact that DKIM choose headers to sign from the bottom up (for
good
I want to try to be precise, which I don't think Charles is being with
his below two sets of facts. Let me try to clarify:
On 7/8/11 5:52 AM, Charles Lindsey wrote:
1. The fact that DKIM choose headers to sign from the bottom up (for good
reason) facilitates certain attacks (not against DKIM,
On Wed, 6 Jul 2011, Barry Leiba wrote:
As Pete has pointed out -- and has he's adamant about -- the signer
can't attack... that is, DKIM can't do anything about attacks by the
signer.
Under the double-From: exploit Otis is so concerned about, one signer can
(given favorable winds) trick an
On Wed, 06 Jul 2011 21:51:49 +0100, Hector Santos hsan...@isdg.net wrote:
My only comment is that we are making way too much out of this.
DKIM requires a From: hashing a minimum requirement and since RFC5322
only one there are two basic fundamentals rules, together called the
One From DKIM
On Wed, 06 Jul 2011 17:31:47 +0100, Barry Leiba barryle...@computer.org
wrote:
I actually like Charles's edits except for one paragraph, and, as a
participant, would be happy to change 8.15 accordingly. The one
problem paragraph is this one:
On Wed, Jul 6, 2011 at 7:17 AM, Charles Lindsey
On 06/Jul/11 20:34, Murray S. Kucherawy wrote:
Anyway, with a few nitty edits from me as well, here's the current
8.15 for -15 for everyone's consideration.
A few comments:
8.15. Attacks Involving Extra Header Fields
[...]
Many email components, including MTAs, MSAs, MUAs and
On 7/6/2011 10:59 PM, Michael Deutschmann wrote:
Under the double-From: exploit Otis is so concerned about, one signer can
(given favorable winds) trick an end-user into thinking his message was
signed properly *by someone else*. So indeed, a signer can attack.
A signer can attack a
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Charles Lindsey
Sent: Thursday, July 07, 2011 3:09 AM
To: DKIM
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
The signer most certainly CAN
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Alessandro Vesely
Sent: Thursday, July 07, 2011 4:56 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
I'd s
On Thursday, July 07, 2011 01:59:17 AM Michael Deutschmann wrote:
...
In real life, however, if you don't have the power to demand that a
recipient mail admin block incoming double-From: messages, then you don't
have the power to demand that they deploy DKIM at all.
...
I think you are
On 7/7/2011 6:57 AM, Murray S. Kucherawy wrote:
I'd s/to be liberal/to be exceedingly liberal/ (we don't want to revise
Postel's statement, do we?)
You're either liberal in your application of the RFCs, or you're not. I
don't see how adding that word improves things here.
well, it keeps
On 7/6/2011 10:59 PM, Michael Deutschmann wrote:
Under the double-From: exploit Otis is so concerned about, one signer can
(given favorable winds) trick an end-user into thinking his message was
signed properly *by someone else*. So indeed, a signer can attack.
A signer can attack a
On 7/7/2011 7:18 AM, John R. Levine wrote:
I would also be interested in seeing an example of a case where adding an
extra
From: line changles the d= in a DKIM signature.
no you wouldn't.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Scott Kitterman
Sent: Thursday, July 07, 2011 6:32 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
I'm working
-dkim] Final update to 4871bis for working group review
I'm working with someone on an implementation and I think we're going to
assume one more From than listed in h= when verifying to ensure nothing
has been added.
This intentionally causes the verifier to assume what the signer really
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Final update to 4871bis for working group
review
I'm working with someone on an implementation and I think we're
going to assume one more From than listed in h= when verifying to
ensure nothing has been added
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Scott Kitterman
Sent: Thursday, July 07, 2011 9:44 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
I agree it's
] On Behalf Of Scott Kitterman
Sent: Thursday, July 07, 2011 12:44 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
On Thursday, July 07, 2011 12:22:20 PM Murray S. Kucherawy wrote:
-Original Message-
From: ietf-dkim-boun
-dkim] Final update to 4871bis for working group review
I agree it's not exactly what is specified in the protocol, but this is
an implementation design issue. I think it's safe. If the DKIM
protocol says I can't do something like this, then I think we have a
problem with the current
I am perfectly happy with Murray's original (and now, revised) text.
(Nits still being discussed are entirely up to the WG.) I am not happy
with Charles's text. Particularly:
On 7/7/11 5:08 AM, Charles Lindsey wrote:
Recall that, when multiple instances of a given header field are
On Thu, 07 Jul 2011 15:28:09 +0100, Barry Leiba barryle...@computer.org
wrote:
The signer most certainly CAN attack, but what he is attacking is not
DKIM; rather it is the recipient, or Ebay, or lenient MTAs. DKIM is, in
fact, his weapon of attack.
Right, but the point is that, with DKIM
On 7/7/2011 12:41 PM, John R. Levine wrote:
Oh yes there is! Because identity assessors will undoubtedly give more
credence to messages where the signature domain is the same as the author
(i.e.From:) domain, ...
My spam filters don't do that.
as well they shouldn't.
Somehow, validating
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Charles Lindsey
Sent: Thursday, July 07, 2011 12:31 PM
To: DKIM
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
I think Murray is wrong
On 7/7/11 10:09 AM, Pete Resnick wrote:
DKIM can only be deployed to mount a
variety of attacks if the recipient has already made the fatal mistake
of assuming that the existence of a cryptographically valid signature
*means* that the message is reliable and from a known good sender.
Strongly
Will your assume one more From than listed in h= lead to failed
verifications on messages that actually follow the advice in the RFC
to list duplicate headers in their h= values?
The RFC also says you shouldn't sign messages that aren't RFC 2822. So
pick your poison.
I have to say it's a little
On Jul 7, 2011, at 3:21 PM, John Levine wrote:
Will your assume one more From than listed in h= lead to failed
verifications on messages that actually follow the advice in the RFC
to list duplicate headers in their h= values?
The RFC also says you shouldn't sign messages that aren't RFC
Pete Resnick wrote:
I am perfectly happy with Murray's original (and now, revised) text.
(Nits still being discussed are entirely up to the WG.) I am not happy
with Charles's text. Particularly:
On 7/7/11 5:08 AM, Charles Lindsey wrote:
Recall that, when multiple instances of a
On 7/7/11 3:21 PM, John Levine wrote:
Will your assume one more From than listed in h= lead to failed
verifications on messages that actually follow the advice in the RFC
to list duplicate headers in their h= values?
The RFC also says you shouldn't sign messages that aren't RFC 2822. So
pick
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Douglas Otis
Sent: Thursday, July 07, 2011 6:47 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
Unfortunately
On Sun, 03 Jul 2011 04:26:49 +0100, Barry Leiba barryle...@computer.org
wrote:
Because of the extent of the changes, though, the chair (I) thinks it
needs to come back to the working group for another review. So the
working group is now asked to look over the diffs, noting that in a
few
I actually like Charles's edits except for one paragraph, and, as a
participant, would be happy to change 8.15 accordingly. The one
problem paragraph is this one:
On Wed, Jul 6, 2011 at 7:17 AM, Charles Lindsey c...@clerew.man.ac.uk wrote:
...
Recall that, when multiple instances of a given
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Barry Leiba
Sent: Wednesday, July 06, 2011 9:32 AM
To: Charles Lindsey
Cc: DKIM
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
As Pete has
On 7/6/2011 11:34 AM, Murray S. Kucherawy wrote:
As Pete has pointed out -- and has he's adamant about -- the signer can't
attack... that is, DKIM can't do anything about attacks by the signer.
And that's as Charles's text itself points out. So I'd be
The signer can attack the receiver, of
Hi Charles,
At 04:17 06-07-2011, Charles Lindsey wrote:
Here, therefore, is my proposed revision of 8.15 (which still includes
most of Pete's new text).
The text looks good. If the AD finds the text appropriate, could
this chapter be closed?
Regards,
-sm
My only comment is that we are making way too much out of this.
DKIM requires a From: hashing a minimum requirement and since RFC5322
only one there are two basic fundamentals rules, together called the
One From DKIM Rule:
One From DKIM Rule:
Verify - DKIM must only see one From when
Murray S. Kucherawy wrote:
8.15. Attacks Involving Extra Header Fields
...
Many email components, including MTAs, MSAs, MUAs and filtering
modules, implement message format checks only loosely. This is done
out of years of industry pressure to be liberal in what is accepted
On 7/6/11 3:30 PM, John R. Levine wrote:
When DKIM signatures serve as a basis for acceptance, ...
Since they don't, can we skip the rest of the screed?
In other words, when DKIM signatures serve a basis for acceptance, this
would be an issue? The statement they don't contradicts preceding
When DKIM signatures serve as a basis for acceptance, ...
Since they don't, can we skip the rest of the screed?
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies,
Please consider the environment before reading this e-mail. http://jl.ly
On 7/6/2011 2:34 PM, Murray S. Kucherawy wrote:
. Anyway, with a few nitty edits from me as well, here's the current
8.15 for -15 for everyone's consideration.
WFM -- +1
Tony Hansen
___
NOTE WELL: This list operates according to
On Sat, Jul 2, 2011 at 11:26 PM, Barry Leiba barryle...@computer.org wrote:
snip
We have a week. Murray will be posting the update (-14) very soon.
Please review and comment by 11 July.
+1 to -14 update.
--
Jeff Macdonald
Ayer, MA
___
NOTE WELL:
On Jul 2, 2011, at 9:58 PM, John R. Levine wrote:
Please review and comment by 11 July.
I would have liked to strip even more of the cruft out of 4871bis, but
this is considerably better than the previous draft. Ship it.
Regardless of any remaining cruft, I'm glad to see this particular
On Jul 2, 2011, at 9:08 PM, Murray S. Kucherawy wrote:
We have a week. Murray will be posting the update (-14) very soon.
Please review and comment by 11 July.
The update has been posted. For your convenience:
http://datatracker.ietf.org/doc/draft-ietf-dkim-rfc4871bis/
You can also
Well, I don't wish to be the pessimistic one. The changes only makes
us happy. So we passed the buck to external processes to make sure a
message is RFC5322/4409 ready. Doesn't change the fact that
something, someone has to do it and depending on the implementor, they
will be proactive
The 4871bis draft was on this past Thursday's IESG telechat, and
mostly passed, but for a strongly held DISCUSS position from one AD,
Pete Resnick. Pete had particular complaints about sections 8.14 and
8.15, along with some other issues, and was willing to block the
document until they were
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Barry Leiba
Sent: Saturday, July 02, 2011 8:27 PM
To: DKIM Mailing List
Subject: [ietf-dkim] Final update to 4871bis for working group review
We have a week. Murray
62 matches
Mail list logo
