On Mon, 11 Jul 2011 14:56:26 +0100, Murray S. Kucherawy
wrote:
>> -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
>> > "Age
On Mon, 11 Jul 2011 05:53:58 +0100, Murray S. Kucherawy
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 transit, or contai
On Fri, 08 Jul 2011 18:51:39 +0100, Pete Resnick
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 DKI
On Fri, 08 Jul 2011 14:54:43 +0100, Murray S. Kucherawy
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
On Fri, 08 Jul 2011 13:05:49 +0100, McDowell, Brett
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 those who engage in
d
On Thu, 07 Jul 2011 22:06:29 +0100, Murray S. Kucherawy
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 From:
> is sho
On Thu, 07 Jul 2011 18:09:14 +0100, 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
On Thu, 07 Jul 2011 15:28:09 +0100, Barry Leiba
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 (as Murray says,
On Wed, 06 Jul 2011 17:31:47 +0100, Barry Leiba
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, Charle
On Wed, 06 Jul 2011 21:51:49 +0100, Hector Santos 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 Rule:
>
> One
On Sun, 03 Jul 2011 04:26:49 +0100, Barry Leiba
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 cases blocks of text w
On Wed, 29 Jun 2011 18:31:04 +0100, Murray S. Kucherawy
wrote:
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org
>> [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey
>> Sent: Wednesday, June 29, 2011 9:20 AM
>> To: D
On Wed, 29 Jun 2011 19:49:27 +0100, Pete Resnick
wrote:
> On 6/29/11 11:20 AM, Charles Lindsey wrote:
>> A phisher obtains a throwaway domain and creates a public/private key
>> pair
>> for
>> it. He then sends messages of the following form:
>>
>
On Wed, 29 Jun 2011 05:46:06 +0100, Pete Resnick
wrote:
> 32. Section 8.14: This is a complete mischaracterization of the problem.
> This is absolutely not an attack vector. If a signer wishes to prevent
> additional *known* header fields from being verified, it can simply use
> the technique o
On Fri, 24 Jun 2011 17:58:19 +0100, Dave CROCKER wrote:
> Let's simplify this discussion:
>
> Spammers do a variety of techniques to trick filters and users.
>
> We should have the DKIM signing specification normatively require
> checking
> for every known technique, since we cannot be
On Fri, 24 Jun 2011 22:43:27 +0100, Steve Atkins
wrote:
> Your current argument is of the form:
>
> Doug: X is bad, and could theoretically lead to end-user confusion
> in one particular obscure replay scenario, given a carefully chosen set
> of assumptions about MUA user interface desi
On Fri, 24 Jun 2011 05:55:38 +0100, John R. Levine wrote:
>> Assuming this is some other protocol layers problem; to ensure
>> consistency
>> between any possible display and DKIM validation, ...
>
> ... is, for about the hundredth time, not DKIM's job.
>
> Please chant "we have no idea how M
On Sat, 28 May 2011 17:29:23 +0100, Alessandro Vesely
wrote:
> IMHO, the "hard parts" of the code are (i) selecting a MIME parser,
> and (ii) finding a good way to structure experimental C14Ns and handle
> double (triple?) signatures in the existing code.
For a Mime Parser, see http://www.cs.m
On Wed, 25 May 2011 01:33:00 +0100, Dave CROCKER wrote:
> To make a canonicalization algorithm that is more robust -- such as
> having it
> based on canonical forms of data, independent of encoding -- makes some
> sense.
> Trying to create the ability to "reverse" changes strikes me as far to
On Mon, 23 May 2011 03:50:06 +0100, Hector Santos wrote:
> Case in point. Right now, I am looking at a gmail.com which I am
> pretty sure was not in Base64 MIME. However, it was submitted to IETF
> DISCUSS group and its showing up as base64 MIME. I don't know if the
> list did it one of the hop
On Tue, 10 May 2011 00:02:36 +0100, Barry Leiba
wrote:
> That was quick. I believe we already have enough objections to say
> that we do NOT have rough consensus for deprecating l= at this time.
> I'll close the issue in the tracker (issue #26), and we will leave it
> as it is.
>
> Of course,
On Sat, 07 May 2011 13:50:41 +0100, Alessandro Vesely
wrote:
> On 06/May/11 20:37, Murray S. Kucherawy wrote:
>Verifiers SHOULD ignore those signatures that produce a PERMFAIL
>result (see Section 7.1), acting as though they were not present
>in the message. ...
>>
Issued in behalf of myself, Doug Otis and Rolf Sonneveld
We were asked by Barry to provide an agreed text to resolve the
"multiple header" problem, for consideration by the WG.
The attack arises when some header (typically From:) which is supposed
to appear once in fact appears twice. DKIM is RE
On Thu, 05 May 2011 21:24:00 +0100, Barry Leiba
wrote:
> Doug says...
>> This can *only* be achieved by some mandatory test within the Verifier.
>
> Not at all; that's exactly Dave's point in discussing the difference
> between the protocol and the software system that wraps around it.
> The Ve
On Sun, 01 May 2011 05:10:06 +0100, Hector Santos wrote:
> So perhaps to help shut down this ambiguity we should add a DKIM
> terminology to clearly separate it from AUID.
>
>3.x Originating Domain Identity (ODID)
>
>The ODID is the domain part of the From: address. This identity
>M
On Fri, 29 Apr 2011 18:39:03 +0100, Murray S. Kucherawy
wrote:
> Right before Section 6:
> + Verifiers SHOULD ignore those signatures that produce a PERMFAIL
> + result (see Section 7.1), acting as though they were not present in
> + the message. ...
s/Verifiers SHOULD ignore/Identity
On Thu, 28 Apr 2011 18:52:19 +0100, John R. Levine wrote:
> Last paragraph of sec 5.2: " Verifiers SHOULD ignore failed signatures as
> though they were not present in the message."
Actually, that does not seem quite right. It is assessors who should do
that. Verifiers are explicitly asked to
On Thu, 28 Apr 2011 20:00:33 +0100, Rolf E. Sonneveld
wrote:
> On 4/28/11 7:38 PM, Murray S. Kucherawy wrote:
>> Thus it is with DKIM. DKIM sits on top of RFC5322 and related message
>> format specs, which in turn sit on top of SMTP, which sits on top of
>> TCP, which sits on top of IP, w
On Tue, 26 Apr 2011 05:29:35 +0100, Dave CROCKER wrote:
>> DKIM doesn't create any binding between the RFC5322.From domain and the
>> "d="
>> value as you're doing. What you're talking about here falls into the
>> realm
>> of ADSP or other policy-like assertions, not DKIM itself which is the
On Tue, 26 Apr 2011 02:33:11 +0100, Douglas Otis
wrote:
> Although DKIM is reviewed within IETF's security area, input validation
> by DKIM remains dangerously neglected. DKIM's Introduction indicates it
> can be implemented independent of clients. As such, few assumptions are
> safe in how u
On Tue, 26 Apr 2011 13:22:15 +0100, Alessandro Vesely
wrote:
> I guess Message-ID is among those "structural, not semantic" fields.
> I concur. However, we miss a field that says an MTA is _knowingly_
> breaking whatever signatures may be present.
The Message-ID gets copied into the Reference
On Thu, 21 Apr 2011 18:46:07 +0100, Barry Leiba
wrote:
>>> I asked my IDNA expert, who said that the definitive answer is "it
>>> depends". He suggests our chair ask our AD to check with the IESG.
>>
>> Our chair is asking our AD to check.
>
> We have the IESG's answer: we should change the re
On Tue, 19 Apr 2011 22:37:59 +0100, Murray S. Kucherawy
wrote:
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org
>> [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey
>> Sent: Tuesday, April 19, 2011 12:56 PM
>> To: DKIM
On Wed, 20 Apr 2011 23:15:52 +0100, Barry Leiba
wrote:
>> Yes indeed. We discussed lots of wording for all of this, and the one
>> that
>> has got into the document is about the worst.
>
> Your objection is noted.
>
>> Note that I have escalated this to as Issue. DKIM is broken if we do not
>
On Wed, 20 Apr 2011 09:24:26 +0100, Hector Santos wrote:
> Murray S. Kucherawy wrote:
>
>>> Oops, this is a separate issue. But I hope it's also not
>>> contentious.
>>> [...]
>>
>> Since I'm not exactly an EAI/IDNA expert...
>>
>>> The only thing that's not obvious to me is whether the hash fun
On Sun, 17 Apr 2011 16:23:31 +0100, Barry Leiba
wrote:
>> additional discussion and references. In addition, verifiers MUST
>> ensure the presence of multiple singleton originating header fields
>> do not provide a valid signature result.
>> ---
>>
>> Not including this additional requirement
On Sat, 16 Apr 2011 01:05:02 +0100, Douglas Otis
wrote:
> http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis-06#section-3.8
> ,---
> DKIM's design is predicated on valid input. Therefore, signers and
> verifiers SHOULD take reasonable steps to ensure that the messages
> they are processing a
On Mon, 11 Apr 2011 16:53:34 +0100, John R. Levine wrote:
>> 3. From = al...@example.com i=mal...@example.com d=example.com.
>
>> 3a. From = supp...@example.com i=al...@example.com d=example.com
>
> How in the world in an automaton supposed to guess that 3. is bogus and
> 3a. is not?
It isn't s
On Mon, 11 Apr 2011 18:45:22 +0100, Douglas Otis
wrote:
>
> Review the charter exclusions. There can be no deeper meaning defined
> for the i= field.
But undoubtedly individuals are going to use the field in ways that they
find useful to their purpose (with knowledge of their own situations
On Fri, 08 Apr 2011 19:55:09 +0100, Franck Martin
wrote:
> On 4/8/11 23:38 , "Charles Lindsey" wrote:
>> In practice, there are three usages which seem to be common; are there
>> others?
>>
>> 1. FROM = Alice@whatever i=sales.example.com d=example.com
&g
On Thu, 07 Apr 2011 16:44:56 +0100, Steve Atkins
wrote:
> On Apr 7, 2011, at 5:13 AM, Charles Lindsey wrote:
>> E.g. DKIM-Signature: v=1; d=corp.example.com; ;
>> tx="birthdate=1970-02-24"
>>
>> or DKIM-Signature: v=1; d=corp.exam
On Wed, 06 Apr 2011 17:29:49 +0100, Steve Atkins
wrote:
> As a concrete example, if I wanted to include the authenticated
> age of each email sender (something the gambling industry might
> be interested in) then I can do that within the DKIM signature:
>
> DKIM-Signature: v=1; d=corp.example.c
On Wed, 06 Apr 2011 21:18:11 +0100, Steve Atkins
wrote:
> The only safe way to add proprietary gunk into the dkim-signature
> header is to add it to the IANA DKIM-Signature tag registry
> (how does that happen? Presumably it requires an RFC?)
Do we currently have such an IANA DKIM-Signature ta
On Mon, 04 Apr 2011 21:24:29 +0100, Murray S. Kucherawy
wrote:
Not quite. For example if an st= tag is in the header and the signature
verifies, then you know that tag was put there (or at least was present)
when the signature was made, and was not inserted by some
scammer-in-the-middle.
On Tue, 05 Apr 2011 11:33:10 +0100, Rolf E. Sonneveld
wrote:
> Ad 2. To give some examples of use profiles:
>
> * of course, the first thing that comes to mind is to use DKIM as
> mechanism to build reputation services on. For this use profile
> not many restrictions will be re
Having just had a deluge of bogus messages from Twitter, all allegedly
DKIM-signed, I think I need a working DKIM checker (my ISP has not
implemented DKIM ckecking so far).
I have not the time to write my own, so can someone please point me to an
implementation that could be deployed as a pr
On Sat, 26 Feb 2011 15:27:03 -, John Levine wrote:
>> Therefore, a verifier SHOULD NOT validate a message that is not
>> compliant with [RFC5322, RFC2045 and RFC2047] specifications.
>>
>> IMHO, it is somewhat vague. That SHOULD-NOT could be "promoted" to a
>> MUST-NOT for a finite numbe
On Sat, 15 Jan 2011 17:17:01 -, Scott Kitterman
wrote:
> On Thursday, January 13, 2011 02:48:14 pm Barry Leiba wrote:
>> ... And at some point between now and then, please make it clear
>> where you stand on the question, so we can fairly judge consensus.
>
>
> -1 on splitting now.
Yes, I
On Thu, 13 Jan 2011 12:50:45 -, Eliot Lear wrote:
> While perhaps this is an entertaining idea (I was particularly
> entertained since it seems to take my notion of generalization far
> beyond where I might have taken it), absent an application I have a
> difficult time supporting it. And ev
On Thu, 13 Jan 2011 17:00:03 -, Steve Atkins
wrote:
> But if other ways of getting the public key are more suitable, what's
> left? The only thing DKIM does is allow a domain to assert responsibility
> for a message in a relatively cheap (if unreliable) way.
That is most certainly NOT the
On Wed, 12 Jan 2011 17:10:52 -, Dave CROCKER wrote:
> This raise a specific and interesting technical point. I haven't seen a
> response so far, so...
> The core of this technology has keys that are named and accessed in
> terms of
> domain names. It really is fundamental to this technic
On Tue, 11 Jan 2011 12:12:53 -, Eliot Lear wrote:
> 4. Rather than keep it in the back of my head, I'll state it outright:
> is a goal here to provide an alternative to SSL-based web page
> security? Conveniently, web content does take the form of header/body.
> If so, one reasonable questi
On Tue, 11 Jan 2011 18:09:53 -, Alessandro Vesely
wrote:
> On 07/Jan/11 21:58, Dave CROCKER wrote:
>> Here's the proposal that Barry just announced, for splitting the DKIM
>> specification into a DKIM-specific portion and an underlying, more
>> generic
>> portion that could be re-purposed
On Fri, 07 Jan 2011 20:58:02 -, Dave CROCKER wrote:
> Here's the proposal that Barry just announced, for splitting the DKIM
> specification into a DKIM-specific portion and an underlying, more
> generic
> portion that could be re-purposed for other services. It's current
> working
> acro
On Mon, 22 Nov 2010 22:32:41 -, Douglas Otis
wrote:
> Murray argued singleton header checks to qualify DKIM signatures
> violates protocol layering.
Which is why I want to fix this problem with normative wording that does
not violate protocol layering.
Quite simple:
Signers MUST/SHOULD
On Thu, 11 Nov 2010 17:55:55 -, Douglas Otis
wrote:
> Once one DKIM verification vendor includes these necessary checks that
> suppress DKIM PASS, and another vendor does not, DKIM implementations
> are no longer compatible. IMHO, this represents a DKIM protocol failure
> to properly defin
On Mon, 08 Nov 2010 09:20:19 -, Barry Leiba
wrote:
> I have a chair statement to start with, and then the rest of this
> message will be as a participant.
>
> As chair:
> We have gone off in the weeds on the "double header" issue, and are
> fighting with ourselves. The chairs need everyone
On Fri, 05 Nov 2010 18:46:37 -, Douglas Otis
wrote:
> Append to Section 6 Verifier Actions:
>
> It is not reasonable to assume a message is in compliance with RFC5322.
> To mitigate trivial exploitation of trust established by DKIM
> signatures, messages having multiple header fields for "o
On Tue, 02 Nov 2010 18:47:23 -, Alessandro Vesely
wrote:
> On 01/Nov/10 22:56, Douglas Otis wrote:
>> On 10/30/10 3:05 AM, Alessandro Vesely wrote:
>>> On 28/Oct/10 03:36, Douglas Otis wrote:
I'll repeat the example given previously. The multiple listing of a
header in the h=
On Thu, 21 Oct 2010 16:17:18 +0100, Alessandro Vesely
wrote:
> DKIM-Signature: d=Big-IPS.com; h=from; (supposedly)...
>> From accou...@big-bank.com
>> From some...@big-ips.com
>> Subject: Audit notification
>>
>>
> In my hypothesis, a verifier would discard the 2nd "From
> accou...@b
On Wed, 20 Oct 2010 18:32:44 +0100, John R. Levine wrote:
>> A reputation service can only say that a domain is
>>BAD
>>GOOD
>> or NO EVIDENCE AVAILABLE EITHER WAY.
>>
>> I think the last case has to be treated pretty much like GOOD, otherwise
>> newcomers to the internet will never even
On Wed, 20 Oct 2010 15:27:16 +0100, Alessandro Vesely
wrote:
> On 20/Oct/10 13:23, Charles Lindsey wrote:
>> The scam I have described involves the use, by the phisher, of a
>> DKIM-signed (by himself) email with two From: headers, which is intended
>> to fool verifiers i
On Mon, 18 Oct 2010 20:18:16 +0100, Murray S. Kucherawy
wrote:
>> This is no more presumptuous than expecting that MUAs will adapt to
>> consume the output of DKIM as it stands now.
>
> In another message I indicated that I don't presume either, but assert
> that there's no middle ground; the
On Tue, 19 Oct 2010 01:32:29 +0100, Hector Santos wrote:
> John R. Levine wrote:
>
>> So, uh, can we agree that Jim's SHOULD language to tell people to do
>> this is a good idea?
>
> Yes. +1. I think I was the first to agree with Jim's input and didn't
> see much follow up except you and maybe a
On Tue, 19 Oct 2010 14:18:45 +0100, Wietse Venema
wrote:
> My preference would be to enforce this within the existing protocol
> (that is: send h=from:from:subject:subject...),
But that only copes with some of the scams that are possible; for full
protection you need
> ... but I could live
On Tue, 19 Oct 2010 16:23:39 +0100, John R. Levine wrote:
>> good signature -> good message.
>>
>> Don't you mean
>>
>> Good signature -> authenticated message (that is, someone
>> accepts responsibility)
I think it needs to mean
Good signature -> authenticated message (that is, someone
On Mon, 18 Oct 2010 18:06:14 +0100, Murray S. Kucherawy
wrote:
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org
>> [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of John Levine
>> Sent: Friday, October 15, 2010 7:14 PM
>> To: ietf-dkim@mipassoc.org
>> Cc: dcroc...@bbiw
On Mon, 18 Oct 2010 21:19:18 +0100, Murray S. Kucherawy
wrote:
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org
>> [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey
>> Sent: Monday, October 18, 2010 4:24 AM
>> To: DKIM
>
On Fri, 15 Oct 2010 18:04:22 +0100, Murray S. Kucherawy
wrote:
> This to me says you still believe DKIM's ultimate payload is something
> other than a validated identifier, in this case a domain name. We're
> thus not on the same page.
>
> If instead we do agree that that's its sole intend
On Fri, 15 Oct 2010 17:45:22 +0100, Michael Thomas wrote:
> On 10/15/2010 06:51 AM, Charles Lindsey wrote:
>> And yet the current protocol will allow an evil mail _apparently_ from
>> Ebay to appear, with no means for the recipient to detect the
>> difference.
>
>
On Sat, 16 Oct 2010 05:09:53 +0100, Hector Santos wrote:
> This probably means that it should clarified what that 5.4 sentence
> means and also the next section 5.5
>
> 5.5. Recommended Signature Content
>
> ..
>
> The following header fields SHOULD be included in the signature, if
>
On Fri, 15 Oct 2010 17:47:24 +0100, Jim Fenton wrote:
> On 10/15/10 6:06 AM, Charles Lindsey wrote:
>> I don't quite see what an attacker can usefully do by modifying messages
>> in transit. If they message was already signed (say by ebay), then the
>> attacker must
On Fri, 15 Oct 2010 17:50:33 +0100, Murray S. Kucherawy
wrote:
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org
>> [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey
>> Sent: Friday, October 15, 2010 7:30 AM
>> To: D
On Fri, 15 Oct 2010 15:48:05 +0100, Ian Eiloart wrote:
> Here's a more interesting attack:
>
> Compose an email apparently from eBay, and send it to yourself. Get a
> valid
> DKIM signature, then add a From: header containing an eBay address, and
> use
> the replay to send that message to thi
On Thu, 14 Oct 2010 17:30:42 +0100, Murray S. Kucherawy
wrote:
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org
>> [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey
>> Sent: Thursday, October 14, 2010 7:32 AM
>> To: D
On Thu, 14 Oct 2010 19:01:17 +0100, Alessandro Vesely
wrote:
> On 13/Oct/10 20:45, Scott Kitterman wrote:
>> On Wednesday, October 13, 2010 12:54:23 pm Murray S. Kucherawy wrote:
>>> If we can extract DKIM from the equation entirely and the problem
>>> remains,
>>> how is it a DKIM problem?
On Thu, 14 Oct 2010 18:30:38 +0100, Murray S. Kucherawy
wrote:
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org
>> [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of John R. Levine
>> Sent: Thursday, October 14, 2010 10:15 AM
>> To: DKIM List
>> Subject: Re: [ietf-dkim]
On Thu, 14 Oct 2010 18:23:21 +0100, Michael Thomas wrote:
> I would hope so because this would be a really stupid thing to do.
> Without the next line of defense -- virus, malware, spam, phishing --
> you'd be setting your users up for big problems. Just because it's
> DKIM signed from a good sou
On Thu, 14 Oct 2010 18:01:25 +0100, Michael Thomas wrote:
> Because the audience who ought to be dealing with the larger problem has
> little to
> nothing to do with the audience that would have to deal with that
> MUST/SHOULD.
> It's a useless requirement to put on DKIM.
So which two audien
On Thu, 14 Oct 2010 17:45:39 +0100, John R. Levine wrote:
> Well, yeah. That's why I don't understand why people are so opposed to a
> SHOULD saying they should.
Or even a MUST saying they must.
--
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 43
On Thu, 14 Oct 2010 15:17:15 +0100, John R. Levine wrote:
> We seem to be talking past each other here.
>
> I don't see anyone proposing a deep dive into 5322 validation. But 4871
> already says you MUST sign the From: header. Why is that OK, but saying
> you MUST NOT sign or validate something
On Wed, 13 Oct 2010 23:22:07 +0100, Jim Fenton wrote:
> Here's some text I propose for section 8.14, in place of the current
> text. Bear in mind that this is in the context of the Security
> Considerations section of the spec, so it is really a discussion of the
> threat and how it is dealt with
On Wed, 13 Oct 2010 18:13:43 +0100, Jim Fenton wrote:
> My inclination is that the spec should say something like:
>
> - The verifier SHOULD consider the signature invalid if a signed header
> field occurs an inappropriate number of times in the message header
> according to section 3.6 of RFC 53
On Wed, 13 Oct 2010 19:27:29 +0100, Jeff Macdonald
wrote:
>> If we can extract DKIM from the equation entirely and the problem
>> remains, how is it a DKIM problem?
>
>
> I agree with this.
>
> And even if there was a DKIM signature, it is the BAD GUY'S signature,
> which should cause it to g
On Wed, 13 Oct 2010 17:54:23 +0100, Murray S. Kucherawy
wrote:
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org
>> [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey
>> Sent: Wednesday, October 13, 2010 9:12 AM
>> To: D
On Wed, 13 Oct 2010 17:34:32 +0100, Charles Lindsey
wrote:
> But full 100% RFC5322 checking is extremely tedious, and is more that we
> actually need.
>
> What we want is more like
> CHECK DKIM && CHECK RFC5322 headers included in h= tag -->
> ACCE
On Tue, 12 Oct 2010 14:21:31 +0100, Hector Santos wrote:
> In the new section 8.14, I believe there is many statements that are
> hardly true, but subjective and written by someone begging to pass the
> buck with conflictive arguments.
>
> DKIM is part of the SYSTEM, DKIM is NOT the SYSTEM. Lets
On Tue, 12 Oct 2010 21:41:18 +0100, Scott Kitterman
wrote:
> DKIM also attempts to provide assurance that content is unmodified.
> Without that the identity assurance is meaningless.
+1
And also assurance that other headers than From are unmodified.
--
Charles H. Lindsey -At Home,
On Tue, 12 Oct 2010 14:00:19 +0100, Dave CROCKER wrote:
> Oh boy. Very sorry folks.
>
> The full text reads:
>
>> Similarly, a message not compliant with RFC5322, RFC2045
>> and
>>RFC2047, can be subject to attempts by intermediaries to
>> correct
>>
On Tue, 12 Oct 2010 07:46:42 +0100, Barry Leiba
wrote:
> There are only two significant changes between -01 and -02 ... most of
> the changes are just updating the references. The substantive changes
> are:
> 1. The addition of the paragraph that begins "Similarly, a message
> that is not comp
On Mon, 11 Oct 2010 23:05:13 +0100, Wietse Venema
wrote:
> Charles Lindsey:
>> > When the bad guy sends mail with (multiple) forged headers, the
>> > best they can get is that naive mail programs render their forged
>> > header with an indication that THE BAD
On Mon, 11 Oct 2010 14:07:03 +0100, Wietse Venema
wrote:
> Charles Lindsey:
>> All you have ensured is that any message signed (say by ebay) is proof
>> against reply attacks that add additional headers.
>>
>> But the scam we are considering does not involve rep
On Tue, 12 Oct 2010 14:36:42 +0100, Hector Santos wrote:
> What it means for most systems that they need to change a model based
> on this:
>
> CHECK DKIM PASS --> ACCEPT
> CHECK RFC5322 BAD --> REJECT
> BREAK
> RESIGN
> DISTRIBUTE
>
> To this:
>
>
On Fri, 08 Oct 2010 18:25:40 +0100, Wietse Venema
wrote:
> If I understand things correctly, the solution is already available
> in DKIM today. It involves signer configuration (sign for N+1
> instances of each header that is covered by the signature) and
> requires no change in protocol or se
On Thu, 07 Oct 2010 19:18:19 +0100, Michael Thomas wrote:
> The larger issue here is would anybody rush out to close this MUST.
> I think that it is highly unlikely that anybody is going to care at this
> point. That goes for *any* new MUST, IMO: unless it's really a serious
> protocol endangerin
On Thu, 07 Oct 2010 17:09:14 +0100, Michael Thomas wrote:
> I'm with Steve on this one. Forcing implementations of DKIM to
> determine whether a message is compliant is a pretty high bar. ...
How can you claim it is a "high bar" when clearly it isn't.? All that the
implementor of a verifier has
On Wed, 06 Oct 2010 13:00:25 +0100, Steve Atkins
wrote:
> On Oct 6, 2010, at 1:47 AM, Mark Delany wrote:
>> Right. We could attempt to enumerate the 1,000 edge-cases we know
>> today and then re-bis 4871 for the additional 1,000 edge-cases we
>> learn tomorrow, or we could simply say that inva
On Wed, 06 Oct 2010 13:25:28 +0100, Murray S. Kucherawy
wrote:
>> -Original Message-
>> From: ietf-dkim-boun...@mipassoc.org
>> [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey
>> Sent: Wednesday, October 06, 2010 3:47 AM
>> To: D
On Wed, 06 Oct 2010 18:57:10 +0100, MH Michael Hammer (5304)
wrote:
> If the consensus is that it is a problem but not really a 4871 problem
> then do we just walk away from it and leave it at that - "not our
> problem"? Should we perhaps look for the place where the 5322 people
> roost (
On Wed, 06 Oct 2010 13:01:29 +0100, Wietse Venema
wrote:
> Mark Delany:
>> Right. We could attempt to enumerate the 1,000 edge-cases we know
>> today and then re-bis 4871 for the additional 1,000 edge-cases we
>> learn tomorrow, or we could simply say that invalid 2822 messages
>> MUST never ver
1 - 100 of 400 matches
Mail list logo
