Re: [ietf-dkim] detecting header mutations after signing

> What you are calling for would be good to have. It should be done. > Just not in the signing spec. Correct me if I'm wrong, but I hear you saying that if one creates or verifies the DKIM signature on a message, one should also do the double header check somewhere in the mail processing path,

Re: [ietf-dkim] removing the g= definition?

On 10/13/2010 6:36 PM, SM wrote: > At 13:03 13-10-10, Barry Leiba wrote: > >>To avoid second-guessing in a security context, and because >>DomainKeys is an obsolete protocol, DKIM verifiers MUST >>interpret this situation in DKIM terms, matching only >>empty "i="

Re: [ietf-dkim] detecting header mutations after signing

> Do Alpine or Thunderbird or whatever else do anything special now when a > message is signed, whether or not the signature(s) pass or fail? For S/MIME, maybe PGP. But of course neither does anything with message headers. > Current modules that don't do the kind of enforcement people are > d

Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records

At 17:31 13-10-10, Hector Santos wrote: >I know section 3.6.2.1 has this informative note: [snip] >This is just to jump start suggested text. Others can add/change >whether they think helps: > > The DKIM public key TXT record MUST not be mixed or merged > with other TXT records, i.e. S

Re: [ietf-dkim] "550 5.7.0 bad DKIM signature data"

Hi Steve, At 18:56 13-10-10, Steve Atkins wrote: >Anyone recognize "550 5.7.0 bad DKIM signature data"? dkim-filter and OpenDKIM can send such a response. >A couple of folks just got bounced off a mailing list due to their >MTAs doing that in response to some mail I sent, so I'm interested >in

Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments

On 10/13/10 4:32 PM, Murray S. Kucherawy wrote: > > It seems to me you're saying the same thing bis-02 is saying, but with > perhaps less terse language. In particular, bis-02 says "SHOULD NOT > validate" something that's malformed, while you're saying "SHOULD" validate > format before proces

Re: [ietf-dkim] detecting header mutations after signing

On 10/13/2010 8:56 PM, Mark Delany wrote: > If DKIM has any value it's that it ultimately affects the user mail > experience for the better. Consequently, to remain silent on matters > that we know will adversely affect that experience seems > contradictory. Similarly to not offer guidance to imp

Re: [ietf-dkim] detecting header mutations after signing

On 10/13/2010 4:59 PM, Mark Delany wrote: > I know we're not in the MUA business, but if DKIM makes no difference > to what an end-user finally sees, then it serves a very limited > purpose indeed. Well, yes. But that's a /good/ thing, as a core capability. More importantly, we are not in the

Re: [ietf-dkim] detecting header mutations after signing

On 10/13/2010 3:17 PM, John R. Levine wrote: > We put a bunch of stuff in DKIM to allow benign modifications of messages, > notably relaxed canoncalization. (We can argue about whether l= is > useful, but it's easy enough to ignore if one thinks it isn't.) I think > it's also reasonable to put

Re: [ietf-dkim] detecting header mutations after signing

On Wednesday, October 13, 2010 03:59:27 pm Jeff Macdonald wrote: > On Wed, Oct 13, 2010 at 2:47 PM, Scott Kitterman > > wrote: > > On Wednesday, October 13, 2010 02:27:29 pm Jeff Macdonald wrote: > >> And even if there was a DKIM signature, it is the BAD GUY'S signature, > >> which should cause i

[ietf-dkim] "550 5.7.0 bad DKIM signature data"

Anyone recognize "550 5.7.0 bad DKIM signature data"? A couple of folks just got bounced off a mailing list due to their MTAs doing that in response to some mail I sent, so I'm interested in what software might do that. Cheers, Steve ___ NOTE WELL

Re: [ietf-dkim] detecting header mutations after signing

+1, well said Mark. Its a real potential situation that is on par, IMTO, with what the DKIM technology was suppose to help with. It was unfortunate it fell through the cracks during the Threats Analysis RFC 5016 production. If it was realized back then, I don't think anyone would be debating w

Re: [ietf-dkim] detecting header mutations after signing

> > In that light, taking an additional step wrt duplicate headers (or > > malformed 2822 in general) is still in the same layer as the verifier. > > My objection isn't so much layering within the software, because I know that > gets mushy real quick, but layering among the protocol specification

[ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records

Folks, I know section 3.6.2.1 has this informative note: INFORMATIVE OPERATIONAL NOTE: Wildcard DNS records (e.g., *.bar._domainkey.example.com) do not make sense in this context and should not be used. Note also that wildcards within domains (e.g., s._domainkey.*.example

Re: [ietf-dkim] Collected data

Jim Fenton wrote: > It also adds more complexity to the specification and to > implementations. Besides, DK compatibility should become less of an > issue with time since it is a legacy protocol. +1 IMO, DKIM is already a "complex" technology to properly implement and integrate into a system

Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments

> -Original Message- > From: Jim Fenton [mailto:fen...@cisco.com] > Sent: Wednesday, October 13, 2010 3:22 PM > To: Murray S. Kucherawy > Cc: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments > > Here's some text I propose for section 8.14, in plac

Re: [ietf-dkim] Last call comment: Changing the g= definition

At 13:03 13-10-10, Barry Leiba wrote: > To avoid second-guessing in a security context, and because > DomainKeys is an obsolete protocol, DKIM verifiers MUST > interpret this situation in DKIM terms, matching only > empty "i=" values. Changing the g= definition takes advanc

Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments

+1. Barry, as the original issue submitter and I only provided suggested text to jump start WG input with better text, I am very happy with Jim Fenton's text. It doesn't lay blame and straight to the key points. Folks, this is really a simple solution and in my opinion, DKIM can gain from thi

Re: [ietf-dkim] Last call comment: Changing the g= definition

> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Barry Leiba > Sent: Wednesday, October 13, 2010 3:46 PM > To: IETF DKIM WG > Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition > > Everyone, please weigh

Re: [ietf-dkim] Last call comment: Changing the g= definition

>> A quick point of order here: This is based on errata #1532 which is >> "Held for Document Update".  Are we free to change the proposed >> semantics that are described there, which do allow for a back-compatibility >> interpretation? > > The errata are suggested changes; 4871 is silent on how to

Re: [ietf-dkim] detecting header mutations after signing

Murray S. Kucherawy wrote: >> -Original Message- > I don't understand how that follows. I'm talking about a dual-From: message > that wasn't signed at all. An MUA will still show the "wrong" one. So I > fail to see why a DKIM specification needs to make a normative requirement > abou

Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments

On 10/12/10 7:58 PM, Murray S. Kucherawy wrote: > You're right, it's not limited to From:, but 8.14 only uses that as an > example. It does also contain a more general description of the issue. > If the diff from RFC4871 doesn't say the right thing, can you propose > alternate text? Here's som

Re: [ietf-dkim] Last call comment: Changing the g= definition

> A quick point of order here: This is based on errata #1532 which is > "Held for Document Update".  Are we free to change the proposed > semantics that are described there, which do allow for a back-compatibility > interpretation? The errata are suggested changes; 4871 is silent on how to handle

Re: [ietf-dkim] detecting header mutations after signing

John R. Levine wrote: > I'm certainly not suggesting a full 5322 body cavity search, but I think > reasonable checks would include checking for duplicates of headers that > MUAs are likely to show, such as Subject, To, From, Sender, and Cc. +1. Personally, I think 5322.From is the main thing b

Re: [ietf-dkim] detecting header mutations after signing

On Oct 13, 2010, at 1:59 PM, Mark Delany wrote: > It strikes me that a DKIM verifier is already well into the business > of 2822 semantics as it knows about headers, header labels, > continuation syntax, header/body boundaries and so on. > > In that light, taking an additional step wrt duplicate

Re: [ietf-dkim] detecting header mutations after signing

> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Mark Delany > Sent: Wednesday, October 13, 2010 1:59 PM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] detecting header mutations after signing > > > I understand th

Re: [ietf-dkim] detecting header mutations after signing

On 10/13/2010 02:47 PM, John Levine wrote: > >> DKIM simply highlights an issue that's been there for a very long time now. > > No. No, no, no, no, no. Malformed messages only become an issue when > someone aserts that they're not malformed. In the absence of DKIM > signatures, the reasonable th

Re: [ietf-dkim] detecting header mutations after signing

> -Original Message- > From: John Levine [mailto:jo...@iecc.com] > Sent: Wednesday, October 13, 2010 2:47 PM > To: ietf-dkim@mipassoc.org > Cc: Murray S. Kucherawy > Subject: Re: [ietf-dkim] detecting header mutations after signing > > >DKIM simply highlights an issue that's been there for

Re: [ietf-dkim] detecting header mutations after signing

On Wed, Oct 13, 2010 at 04:09:34PM -0400, MH Michael Hammer (5304) allegedly wrote: > Having said that, if an MUA is going to present an indication of > "DKIM PASS" to the enduser, then a reasonable person would expect > some relationship between what is "passed" and what is presented to > the en

Re: [ietf-dkim] detecting header mutations after signing

>> I'm certainly not suggesting a full 5322 body cavity search, but I think >> reasonable checks would include checking for duplicates of headers that >> MUAs are likely to show, such as Subject, To, From, Sender, and Cc. >I'm concerned that if we name that specific check, that's all people >will

Re: [ietf-dkim] Last call comment: Changing the g= definition

> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Jim Fenton > Sent: Wednesday, October 13, 2010 2:34 PM > To: Barry Leiba > Cc: IETF DKIM WG > Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition > > >

Re: [ietf-dkim] Last call comment: Changing the g= definition

> Clarifying question:  What does "this situation" (in the last paragraph) > refer to:  the use of an empty "g=" value, or an empty "g=" value absent > a "v=" tag? The latter, the "can't tell" situation. We can tweak the text to make that clearer, if the WG wants this change. Barry On Wed, Oct

Re: [ietf-dkim] Last call comment: Changing the g= definition

On 10/13/10 1:03 PM, Barry Leiba wrote: > I thought we'd had this discussion before, and what's there was what > we decided to do. Search facilities are inadequate for easy checking. > I certainly think that pointing out the ambiguity issue is important, > so I, as a participant, wouldn't want

Re: [ietf-dkim] What DKIM provides, again

>> > Jeff, an identifier that's not bound to something is useless. It's >> > like "Mike" just bouncing around the aether. Until it binds to >> > something, it's not providing anything useful and certainly not >> > something you'd want to alter the message disposition. >> >> It is bound to 3 header

Re: [ietf-dkim] What DKIM provides, again

> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Jeff Macdonald > Sent: Wednesday, October 13, 2010 1:15 PM > To: DKIM WG > Subject: Re: [ietf-dkim] What DKIM provides, again > > On Wed, Oct 13, 2010 at 4:01 PM, Michael Tho

Re: [ietf-dkim] What DKIM provides, again

On Wed, Oct 13, 2010 at 4:01 PM, Michael Thomas wrote: >> >> But like I said, I was ranting. > > Jeff, an identifier that's not bound to something is useless. It's > like "Mike" just bouncing around the aether. Until it binds to > something, it's not providing anything useful and certainly not > s

Re: [ietf-dkim] detecting header mutations after signing

> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Jeff Macdonald > Sent: Wednesday, October 13, 2010 3:59 PM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] detecting header mutations after signing > > On Wed, Oct

Re: [ietf-dkim] Last call comment: Changing the g= definition

>>>     If a v= value is not found at the beginning of the DKIM key record, >>>     the key record MAY be interpreted as for DomainKeys [RFC4870].  The >>>     definition given here is upwardly compatible with what is used for >>>     DomainKeys, with the exception of the "g=" value.  In a DomainKe

Re: [ietf-dkim] What DKIM provides, again

On 10/13/2010 12:47 PM, Jeff Macdonald wrote: >> Then you send me a piece of signed mail, I change everything except the >> Message-ID and Date, and send it to someone else. And the verifier will >> green-light it, meaning you've taken responsibility for it. Are you OK with >> that? >> >> My w

Re: [ietf-dkim] detecting header mutations after signing

On Wed, Oct 13, 2010 at 2:47 PM, Scott Kitterman wrote: > On Wednesday, October 13, 2010 02:27:29 pm Jeff Macdonald wrote: >> And even if there was a DKIM signature, it is the BAD GUY'S signature, >> which should cause it to go into the SPAM folder, with a large >> phishing warning. > > No.  That

Re: [ietf-dkim] FW: An issue with DKIM reporting extensions

On 10/13/2010 11:25 AM, Scott Kitterman wrote: > On Wednesday, October 13, 2010 11:55:25 am Steve Atkins wrote: >> On Oct 13, 2010, at 8:07 AM, Rolf E. Sonneveld wrote: >>> or >>> a special selector (e.g. s=notifications), to identify the different >>> nature of this mail stream? >> >> No. Never do

Re: [ietf-dkim] What DKIM provides, again

On Wed, Oct 13, 2010 at 2:37 PM, Murray S. Kucherawy wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] >> On Behalf Of Jeff Macdonald >> Sent: Wednesday, October 13, 2010 11:27 AM >> To: DKIM >> Subject: Re: [ietf-dkim] detecting

Re: [ietf-dkim] detecting header mutations after signing

> -Original Message- > From: John R. Levine [mailto:jo...@iecc.com] > Sent: Wednesday, October 13, 2010 12:17 PM > To: Murray S. Kucherawy > Cc: DKIM > Subject: Re: [ietf-dkim] detecting header mutations after signing > > I'm certainly not suggesting a full 5322 body cavity search, but I t

Re: [ietf-dkim] detecting header mutations after signing

> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Scott Kitterman > Sent: Wednesday, October 13, 2010 11:46 AM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] detecting header mutations after signing > > > If we can

Re: [ietf-dkim] detecting header mutations after signing

On Wednesday, October 13, 2010 02:27:29 pm Jeff Macdonald wrote: > And even if there was a DKIM signature, it is the BAD GUY'S signature, > which should cause it to go into the SPAM folder, with a large > phishing warning. No. That misses the point entirely. The problem here is that one can take

Re: [ietf-dkim] detecting header mutations after signing

On Wednesday, October 13, 2010 12:54:23 pm 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: DKIM > > Subject: Re: [ietf-dk

Re: [ietf-dkim] detecting header mutations after signing

> If we can extract DKIM from the equation entirely and the problem > remains, how is it a DKIM problem? But it doesn't. Absent a DKIM signature, nobody's making any assertions about incoming messages, and there's no reason to treat duplicate headers as anything beyond a software bug. With a

Re: [ietf-dkim] detecting header mutations after signing

On Wed, Oct 13, 2010 at 2:40 PM, Dave CROCKER wrote: > > > On 10/13/2010 2:27 PM, Jeff Macdonald wrote: >> >> DKIM seems to make assurances to message integrity. But it >> doesn't. I think the reason why many think it does is because of the >> body hash. It is trying to do to much. It should just

Re: [ietf-dkim] Collected data

On 10/13/10 10:53 AM, Murray S. Kucherawy wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] >> On Behalf Of Jim Fenton >> Sent: Wednesday, October 13, 2010 10:42 AM >> To: ietf-dkim@mipassoc.org >> Subject: Re: [ietf-dkim] Collec

Re: [ietf-dkim] detecting header mutations after signing

On Oct 13, 2010, at 11:27 AM, Jeff Macdonald wrote: > > > And even if there was a DKIM signature, it is the BAD GUY'S signature, > which should cause it to go into the SPAM folder, with a large > phishing warning. > > > Count me as one of those who was confused early on about what DKIM > prov

Re: [ietf-dkim] detecting header mutations after signing

On 10/13/2010 2:27 PM, Jeff Macdonald wrote: > DKIM seems to make assurances to message integrity. But it > doesn't. I think the reason why many think it does is because of the > body hash. It is trying to do to much. It should just provide an > identifier that can be verified. Instead of using t

[ietf-dkim] What DKIM provides, again

> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Jeff Macdonald > Sent: Wednesday, October 13, 2010 11:27 AM > To: DKIM > Subject: Re: [ietf-dkim] detecting header mutations after signing > > > Count me as one of those who

Re: [ietf-dkim] FW: An issue with DKIM reporting extensions

On Oct 13, 2010, at 11:25 AM, Scott Kitterman wrote: > On Wednesday, October 13, 2010 11:55:25 am Steve Atkins wrote: >> On Oct 13, 2010, at 8:07 AM, Rolf E. Sonneveld wrote: >>> or >>> a special selector (e.g. s=notifications), to identify the different >>> nature of this mail stream? >> >> No.

Re: [ietf-dkim] detecting header mutations after signing

Murray S. Kucherawy wrote: > If we can extract DKIM from the equation entirely and the > problem remains, how is it a DKIM problem? Because DKIM raises the bar and begins to bind headers that it required to be *exclusively* correct - a new level of thinking and concept that is above and beyond

[ietf-dkim] rfc4871bis-02 version with diffs

Folks, will get you to the html,pdf,txt versions of the latest draft, including a link to the diff from 4871 that Murray computed. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NO

Re: [ietf-dkim] detecting header mutations after signing

On Wed, Oct 13, 2010 at 12:54 PM, 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: DKIM >> Subject: Re: [ietf-dkim] detectin

Re: [ietf-dkim] FW: An issue with DKIM reporting extensions

On Wednesday, October 13, 2010 11:55:25 am Steve Atkins wrote: > On Oct 13, 2010, at 8:07 AM, Rolf E. Sonneveld wrote: > > or > > a special selector (e.g. s=notifications), to identify the different > > nature of this mail stream? > > No. Never do this. > > Selectors are an operational convenienc

Re: [ietf-dkim] FW: An issue with DKIM reporting extensions

On 10/13/2010 2:03 PM, Jeff Macdonald wrote: > On Wed, Oct 13, 2010 at 11:55 AM, Steve Atkins > wrote: >>> or >>> a special selector (e.g. s=notifications), to identify the different >>> nature of this mail stream? >> >> No. Never do this. >> >> Selectors are an operational convenience for key

Re: [ietf-dkim] Policy interop data

Murray S. Kucherawy wrote: > One of the OpenDKIM data collectors also sent me some data about DKIM-related > DNS queries he saw in one day of traffic. It's not appropriate to add to the > interop report since it's policy-specific and not specific to DKIM base, but > I thought it might be interes

[ietf-dkim] Policy interop data

One of the OpenDKIM data collectors also sent me some data about DKIM-related DNS queries he saw in one day of traffic. It's not appropriate to add to the interop report since it's policy-specific and not specific to DKIM base, but I thought it might be interesting to share here. One day of tra

Re: [ietf-dkim] FW: An issue with DKIM reporting extensions

On Wed, Oct 13, 2010 at 11:55 AM, Steve Atkins wrote: > > On Oct 13, 2010, at 8:07 AM, Rolf E. Sonneveld wrote: > > >> or >> a special selector (e.g. s=notifications), to identify the different >> nature of this mail stream? > > No. Never do this. > > Selectors are an operational convenience for k

Re: [ietf-dkim] Collected data

> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Jim Fenton > Sent: Wednesday, October 13, 2010 10:42 AM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] Collected data > > [sticking with Murray's subject line so as

Re: [ietf-dkim] Last call comment: Changing the g= definition

On 10/13/10 9:53 AM, Barry Leiba wrote: >> If a v= value is not found at the beginning of the DKIM key record, >> the key record MAY be interpreted as for DomainKeys [RFC4870]. The >> definition given here is upwardly compatible with what is used for >> DomainKeys, with the excep

Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments

> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Jim Fenton > Sent: Wednesday, October 13, 2010 10:14 AM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments > > My inclination i

Re: [ietf-dkim] Collected data

[sticking with Murray's subject line so as not to create two thread breakages!] On 10/12/10 11:29 PM, Murray S. Kucherawy wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] >> On Behalf Of Jim Fenton >> Sent: Tuesday, October 12

Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments

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

Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments

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,

Re: [ietf-dkim] I-D ACTION:draft-ietf-dkim-rfc4871bis-02.txt

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 >>

Re: [ietf-dkim] I-D ACTION:draft-ietf-dkim-rfc4871bis-02.txt

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

Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments

On 10/13/10 8:04 AM, John Levine wrote: >> Subject: Buy fake watches at fakewatch.example.com! >> >> Will some clients display the second subject line? I suspect some >> will. Do we need to recommend that signers also add a protective second >> subject: to their h= value? Or do we need to requ

Re: [ietf-dkim] Example of DKIM bypasses RFC5322 Checking

> What happens if you do the same thing, but put the "To:" header above the > "From:" headers? What about when it's between the two "From:" headers? Actually, the chairs would rather take this off the DKIM mailing list, as out of the group's scope. If some folks want to go do some testing about w

Re: [ietf-dkim] detecting header mutations after signing

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 GUY'S DKIM SIGNATURE VERIFIED. >> >

Re: [ietf-dkim] detecting header mutations after signing

> -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: DKIM > Subject: Re: [ietf-dkim] detecting header mutations after signing > > The bad guy (the phisher) provi

Re: [ietf-dkim] Last call comment: Changing the g= definition

>    If a v= value is not found at the beginning of the DKIM key record, >    the key record MAY be interpreted as for DomainKeys [RFC4870].  The >    definition given here is upwardly compatible with what is used for >    DomainKeys, with the exception of the "g=" value.  In a DomainKeys >    key

Re: [ietf-dkim] detecting header mutations after signing

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 replay attacks at all. >> It >> inv

Re: [ietf-dkim] FW: An issue with DKIM reporting extensions

On Oct 13, 2010, at 8:07 AM, Rolf E. Sonneveld wrote: > or > a special selector (e.g. s=notifications), to identify the different > nature of this mail stream? No. Never do this. Selectors are an operational convenience for key rotation and ease of domain delegation. They have no semantics b

Re: [ietf-dkim] detecting header mutations after signing

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: > >

Re: [ietf-dkim] FW: An issue with DKIM reporting extensions

On 10/13/10 3:29 PM, John Levine wrote: >> - In order to make use of ADSP, Y needs to change which MTA it's >> using. This is almost certainly an expensive effort. >> >> - Y simply can't use ADSP. >> >> - The DKIM reporting extensions should have a flag that says DSNs

Re: [ietf-dkim] FW: An issue with DKIM reporting extensions

> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of John Levine > Sent: Wednesday, October 13, 2010 9:29 AM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] FW: An issue with DKIM reporting extensions > > >-

Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments

>Subject: Buy fake watches at fakewatch.example.com! > >Will some clients display the second subject line? I suspect some >will. Do we need to recommend that signers also add a protective second >subject: to their h= value? Or do we need to require that verifiers >make sure that any header fi

Re: [ietf-dkim] FW: An issue with DKIM reporting extensions

>- In order to make use of ADSP, Y needs to change which MTA it's >using. This is almost certainly an expensive effort. > >- Y simply can't use ADSP. > >- The DKIM reporting extensions should have a flag that says DSNs >should not cause generation of fraud reports. I'll

Re: [ietf-dkim] Last Call comments on draft-ietf-dkim-rfc4871bis-02

On Wed, Oct 13, 2010 at 12:50 AM, Jim Fenton wrote: > 6.3 paragraph 5 has changed "signing identity" to SDID.  The signing > identity really corresponds to the AUID.  As currently worded, the mail > system is advised to take pains to ensure that the SDID is displayed for > a message signed on beha

Re: [ietf-dkim] Example of DKIM bypasses RFC5322 Checking

--On 12 October 2010 13:02:41 -0400 Hector Santos wrote: > > Your mail to 'ietf-dkim' with the subject > > (no subject) > > Is being held until the list moderator can review it for approval. > > The reason it is being held: > > Message has implicit destination > > Either the message w