Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On June 20, 2014 5:39:41 PM EDT, John Levine wrote: >>> I don't know anyone who's checked whether DKIM validators verify the >>> version number, but if it's an issue, there aren't that many widely >>> used DKIM engines so it wouldn't be hard to check. >> >>Just FYI, libdkim which all our products

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

Dave Crocker writes: > On 6/13/2014 12:46 AM, Stephen J. Turnbull wrote: > > Well, for Author Domains publishing "p=reject", we can certainly > > confuse the issue dramatically. Change the protocol to advocate > > "silent discard" > > Question to the group: Does silent discard help? Or

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On Fri, Jun 20, 2014 at 2:39 PM, John Levine wrote: > I looked at the code in Mail::DKIM which is what spamassassin and > probably every other perl DKIM application uses. It checks the > version number, and for some reason accepts "0.5" as well as "1", but > nothing else. > "0.5" was used durin

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

>> I don't know anyone who's checked whether DKIM validators verify the >> version number, but if it's an issue, there aren't that many widely >> used DKIM engines so it wouldn't be hard to check. > >Just FYI, libdkim which all our products use does check the v= and if >it's not "v=1" verification

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On Fri, Jun 20, 2014 at 1:47 PM, Arvel Hathcock wrote: > I don't know anyone who's checked whether DKIM validators verify the >> version number, but if it's an issue, there aren't that many widely >> used DKIM engines so it wouldn't be hard to check. >> > > Just FYI, libdkim which all our product

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

I don't know anyone who's checked whether DKIM validators verify the version number, but if it's an issue, there aren't that many widely used DKIM engines so it wouldn't be hard to check. Just FYI, libdkim which all our products use does check the v= and if it's not "v=1" verification "fails" w

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On 6/20/2014 11:43 AM, John Levine wrote: >> Question to the group: Does silent discard help? Or rather, do we have >> any indication that noisy "p=reject" does or can hurt? > > ADSP had silent discard. Sorry, I meant to indicate an interest in usage that was, well, you know, actually used...

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

>Question to the group: Does silent discard help? Or rather, do we have >any indication that noisy "p=reject" does or can hurt? ADSP had silent discard. It avoided the problem of people bouncing off lists, but made the "where did my mail go" problem even worse. DMARC has p=quarantine. In disc

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

Folks, G'day. I've now caught up on the list activity and am sending my combined comments in a single posting, especially since I think there's really a single organizing issue that's being missed... On 6/13/2014 12:46 AM, Stephen J. Turnbull wrote: > Well, for Author Domains publishing "p=reje

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

Brandon Long writes: > I like the "in-band optimizer" since it gives me more > confidence... but maybe that's being naive as well, if they > compromise a domain to get on our whitelist, are they really going > to be deterred in working around a weak signature? Once they've compromised a domai

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

Murray S. Kucherawy writes: > On Sat, Jun 14, 2014 at 11:53 PM, Stephen J. Turnbull > wrote: > > > > How about a new tag, "shf=" (special header fields). Ignored > > > by legacy verifiers, as required; otherwise, contains a > > > colon-separated list of fields that get special handling

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On Sat, Jun 14, 2014 at 11:53 PM, Stephen J. Turnbull wrote: > > How about a new tag, "shf=" (special header fields). Ignored by legacy > > verifiers, as required; otherwise, contains a colon-separated list of > > fields that get special handling by verifiers. "Special handling" > depends >

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On Sat, Jun 14, 2014 at 11:15 PM, Dave Crocker wrote: > > What I was suggesting was merely registering a new canonicalization > algorithm. Legacy DKIM implementations won't understand it. New ones > (presumably also modified to know about DMARC) will. > > The new canonicalization should have ac

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

Murray S. Kucherawy writes: > How about a new tag, "shf=" (special header fields). Ignored by legacy > verifiers, as required; otherwise, contains a colon-separated list of > fields that get special handling by verifiers. "Special handling" depends > on the header field and would need to be

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

John Levine writes: > >Can't both the version bump issue and the token signature issue be > >ameliorated by incorporating the token signature in the DKIM-Delegate > >field? > > Yes, you could do the equivalent of the version bump by changing the > name of the header, but I don't see the poi

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On 6/15/2014 8:01 AM, Murray S. Kucherawy wrote: > How about a new tag, "shf=" (special header fields). Ignored by legacy > verifiers, as required; otherwise, contains a colon-separated list of > fields that get special handling by verifiers. "Special handling" > depends on the header field and w

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On Sat, Jun 14, 2014 at 8:57 PM, Dave Crocker wrote: > It's an interesting idea, but does seem like some sort of layer > violation. (i wanted some phrase other than 'kludgy' just so i didn't > echo john...) > > Surely there are enough details we could vary in a header > canonicalization that are

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On 6/15/2014 4:08 AM, Murray S. Kucherawy wrote: > What about a new canonicalization, which is largely the same as the > existing ones but carries with it the additional semantic that "This can > only pass when accompanied by a Mediator signature"? > > Current verifiers don't know what this is and

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

I'm not sure I can completely characterize that problem, but it's something along the times of there need to be some way to state the intention behind this particular signature. Is this a signature tied to use by third parties? Whitelisting? Something else? What about a new canonicalization, whic

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On Sat, Jun 14, 2014 at 12:35 PM, wrote: > > Yes, you could do the equivalent of the version bump by changing the > > name of the header, but I don't see the point. > > If you're going to bump the version, you need to use the opportunity to > solve the more general underlying problem. > > I'm not

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On Sat, Jun 14, 2014 at 11:46 AM, John Levine wrote: > Perhaps there are DKIM validators that look at the signature to decide > how strong it is, but I don't think I've ever seen one. Either they > pass or they fail. > OpenDKIM has all sorts of hooks for doing that kind of thing, but I don't kn

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On Jun 14, 2014, at 3:35 PM, ned+dm...@mrochek.com wrote: If a signature has an rsf= tag, verifiers ignore it unless there's a matching signature from a domain the rsf= points to. This is not backward compatible, since verifiers that don't understand rsf= will often get

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

If a signature has an rsf= tag, verifiers ignore it unless there's a matching signature from a domain the rsf= points to. ... > If you're going to bump the version, you need to use the opportunity to > solve the more general underlying problem. > > I'm not sure I can completely charac

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

If a signature has an rsf= tag, verifiers ignore it unless there's a matching signature from a domain the rsf= points to. ... If you're going to bump the version, you need to use the opportunity to solve the more general underlying problem. I'm not sure I can completely characterize that probl

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

> > > If a signature has an rsf= tag, verifiers ignore it unless there's a > > > matching signature from a domain the rsf= points to. > > > > > > This is not backward compatible, since verifiers that don't understand > > > rsf= will often get the wrong answer, so it needs a version bump. > > > >Can

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

> > If a signature has an rsf= tag, verifiers ignore it unless there's a > > matching signature from a domain the rsf= points to. > > > > This is not backward compatible, since verifiers that don't understand > > rsf= will often get the wrong answer, so it needs a version bump. > >Can't both the

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

>When DKIM-Delegate is used, there are two, valid signatures for the same >domain. One is 'stronger'. > >The scenario being discussed is for a recipient who gets both signatures >when they are valid, but who does not know about DKIM-Delegate. They >only know about DKIM. That's not a problem -- i

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

John Sweet writes: > That's not an integration test. It's all automated. The answer you > want is, "Can I make money now?" This is how you get the > answer. The DMARC record is only part of the story, whether > recipients act on it or not is just as important. Well, for Author Domains publish

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On Jun 13, 2014, at 7:18 AM, "Stephen J. Turnbull" wrote: > In any case, now I wonder what they're really trying to do. They can > check for "p=reject" without sending *any* mail. That's not an integration test. It's all automated. The answer you want is, "Can I make money now?" This is how yo

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

Elizabeth Zwicky writes: > No, I mean to say that "never stopped" does not mean "never slowed > down", it means "never stopped". OK. I'll remember that. In any case, now I wonder what they're really trying to do. They can check for "p=reject" without sending *any* mail. (I know, you're not

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On 6/12/14, 3:59 PM, "Stephen J. Turnbull" wrote: >Elizabeth Zwicky writes: > > > I did not say that the levels were the same; I said the attackers > > have not gone away. They are not at high volume, but they're sure > > sitting there checking to see whether or not it's working. > >What you sa

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

Murray S. Kucherawy writes: > Interesting. So DKIM-Delegate is syntactically the same as DKIM-Signature, > but with augmented semantics? Or did you have something else in mind? That's what I had in mind. But the semantics are not merely augmented, they're conceptually different. DKIM-Delega

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On Thu, Jun 12, 2014 at 4:05 PM, Stephen J. Turnbull wrote: > Can't both the version bump issue and the token signature issue be > ameliorated by incorporating the token signature in the DKIM-Delegate > field? > > There's a protocol collision on the t= tag which would need to be > addressed, but

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

John R Levine writes: > > And humor aside, please state the technical changes to the existing DKIM > > specification that are being made with DKIM-Delegate. > > If a signature has an rsf= tag, verifiers ignore it unless there's a > matching signature from a domain the rsf= points to. > >

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

Elizabeth Zwicky writes: > I did not say that the levels were the same; I said the attackers > have not gone away. They are not at high volume, but they're sure > sitting there checking to see whether or not it's working. What you said, exactly, is But I do, in fact, have data, and that da

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

Dave Crocker writes: > On 6/12/2014 11:58 AM, Stephen J. Turnbull wrote: > > Dave Crocker writes: > > > > > The scenario being discussed is for a recipient who gets both signatures > > > when they are valid, but who does not know about DKIM-Delegate. > > > > I didn't understand that from

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On Thu, Jun 12, 2014 at 12:53 AM, Vlatko Salaj wrote: > > DKIM-Delegate does not need or use any externally-maintained list. > > please, solve this spoofing example: > Asked and answered already, here (and elsewhere): http://www.ietf.org/mail-archive/web/dmarc/current/msg01250.html There's no n

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

> DKIM-Delegate does not need or use any externally-maintained list. please, solve this spoofing example: 1. so, a sender sends DKIM-D with every email, regardless whether    it is meant for a mailing list or not, cause they maintain no    whitelist to make a difference, 2. sender sends an emai

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

Hi Murray, On Tue 10/Jun/2014 19:56:30 +0200 Murray S. Kucherawy wrote: > On Tue, Jun 10, 2014 at 8:14 AM, Alessandro Vesely wrote: > >> First, weak signatures which are not part of a chain should be ignored >> by verifiers. An authentication chain can be defined as a set of >> valid DKIM signa

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On 6/12/14, 3:10 AM, "Stephen J. Turnbull" wrote: >John R Levine writes: > > > For this application I don't see x= as much protection. If a bad guy > > subscribes to the list or gets messages via something like gmane, he > > can do the mutate and spam in close to real time. > >Is this a prac

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

And humor aside, please state the technical changes to the existing DKIM specification that are being made with DKIM-Delegate. If a signature has an rsf= tag, verifiers ignore it unless there's a matching signature from a domain the rsf= points to. This is not backward compatible, since verif

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

John R Levine writes: > For this application I don't see x= as much protection. If a bad guy > subscribes to the list or gets messages via something like gmane, he > can do the mutate and spam in close to real time. Is this a practical concern, though? The levels of spam etc that drove Yahoo

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On 6/12/2014 11:58 AM, Stephen J. Turnbull wrote: > Dave Crocker writes: > > > The scenario being discussed is for a recipient who gets both signatures > > when they are valid, but who does not know about DKIM-Delegate. > > I didn't understand that from previous posts. At least Hector seems >

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

Dave Crocker writes: > The scenario being discussed is for a recipient who gets both signatures > when they are valid, but who does not know about DKIM-Delegate. I didn't understand that from previous posts. At least Hector seems to be concerned (though not exclusively so) with the case I pres

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On 6/12/2014 10:32 AM, John R Levine wrote: > We disagree. Yup. But I don't mind your being wrong... And humor aside, please state the technical changes to the existing DKIM specification that are being made with DKIM-Delegate. Keep in mind the fact that TCP uses IP, and does not change it.

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

There is nothing about DKIM-Delegate that changes DKIM. We disagree. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. ___ dmarc mailing list dmarc@ietf.org https:/

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On 6/12/2014 10:12 AM, John R Levine wrote: > Adding a new tag doesn't need a version bump so long as it's OK for > verifiers that don't understand the tag to ignore it. This needs a > version bump since the intention is that the signature isn't interesting > unless it's paired with a forwarder's

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

Answering four messages at once: > Someone sends off a message to a mailing list with the two DKIM > signatures and DKIM-Delegate. Someone else, perhaps a list > subscriber, notes that the weaker signature doesn't cover the body, so > he replaces the body with nose enlargement spam and blasts i

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

Hector Santos writes: > > You would simply not use DKIM-Delegate if that's your policy. > > Again, the fault. Please define "fault". Also "lookup". I doubt I'm the only one who doesn't understand what you mean by these words. > The policy is X, but Y is seen. The payload can be > DKIM-

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On 6/12/2014 8:40 AM, Murray S. Kucherawy wrote: > On Wed, Jun 11, 2014 at 10:39 PM, Dave Crocker > wrote: > > The irony of your suggestion is that it requires having 'unupgraded' > software reliably use the version number, given that they haven't needed > t

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On 6/12/2014 8:37 AM, Stephen J. Turnbull wrote: > Dave Crocker writes: > > > Hence this is merely the case of two, competing signatures and deciding > > which to choose. > > An invalid DKIM signature should not be treated differently from the > absence of that signature. I wasn't referring t

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On Wed, Jun 11, 2014 at 10:39 PM, Dave Crocker wrote: > The irony of your suggestion is that it requires having 'unupgraded' > software reliably use the version number, given that they haven't needed > to do that before either... > Section 6.1.1 of DKIM makes it a MUST that unknown versions resu

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

Dave Crocker writes: > Hence this is merely the case of two, competing signatures and deciding > which to choose. An invalid DKIM signature should not be treated differently from the absence of that signature. I'm not sure about the intended precise technical interpretation of that clause, but

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On 6/12/2014 12:22 AM, John Levine wrote: > One could make an argument that it's not technically > a semantic change to DKIM (indeed, Dave just did), but in practical > terms, it is likely to interact poorly with existing unupgraded > software, so I'd want a version bump so that the old softw

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On 6/11/2014 11:52 PM, Vlatko Salaj wrote: > delegated domain inclusion in DKIM-D header is optional, This is a reading of the draft specification that appears to be incorrect: the DKIM-Delegate proposal always specifies target domain names for delegated operation. What is optional is the method

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On Wed, Jun 11, 2014 at 9:21 PM, Hector Santos wrote: > > - Signature Required, Exclusive 1st party only. >>> >> >> You would simply not use DKIM-Delegate if that's your policy. >> > > Again, the fault. The policy is X, but Y is seen. The payload can be > DKIM-Delegate compliant but the actual

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

Restrictive 1st Party (Author Domain) Signing Policies - No Mail Expected That's not in scope here. You could use draft-ietf-appsawg-nullmx for that if you really want. The NULLMX proposal only applies on the SMTP client, sending, callout side. This one can be folded with the others, but a

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On Wed, Jun 11, 2014 at 7:49 PM, Hector Santos wrote: > On 6/11/2014 4:58 PM, Murray S. Kucherawy wrote: > >> >> One thing that is missing (and there's a placeholder for it) is >> examples so you can see how it works. I'll make sure that's there for >> -01. >> > > Examples are good. Can we work

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On 6/11/2014 4:58 PM, Murray S. Kucherawy wrote: One thing that is missing (and there's a placeholder for it) is examples so you can see how it works. I'll make sure that's there for -01. Examples are good. Can we work it out here, a "software" walkthru? Save some drafting time. The m

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On Wed, Jun 11, 2014 at 3:47 PM, Murray S. Kucherawy wrote: > > >> This hasn't been a problem before. Although you've always been >> allowed to use weak signatures, there's been no advantage to doing so, >> so nobody did. Now you do, but with new semantics that you shouldn't >> pay much (any?)

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On Wed, Jun 11, 2014 at 3:22 PM, John Levine wrote: > Someone sends off a message to a mailing list with the two DKIM > signatures and DKIM-Delegate. Someone else, perhaps a list > subscriber, notes that the weaker signature doesn't cover the body, so > he replaces the body with nose enlargement

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On Wednesday, June 11, 2014 6:33 PM, Alessandro Vesely wrote: > Or am I missing something? delegated domain inclusion in DKIM-D header is optional, and considering it requires some kind of whitelist from which its to draw a list of domain it should include, compared 2 those it should not, it is

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

>On Wed, Jun 11, 2014 at 7:15 AM, John Levine wrote: > >> Right. So if you don't want people using unforwarded weak signatures >> for reputation management, you need to put something into them so that >> old clients don't accept them as signatures and ignore the t= tag. >> Either call them someth

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On Wed, Jun 11, 2014 at 7:15 AM, John Levine wrote: > Right. So if you don't want people using unforwarded weak signatures > for reputation management, you need to put something into them so that > old clients don't accept them as signatures and ignore the t= tag. > Either call them something ot

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On Wed, Jun 11, 2014 at 8:09 AM, Hector Santos wrote: > Preference should be given to the author domain explicitly authorized > resigners, how ever that black box functionality is achieved. Currently, > there are three DNS-based authorization proposals on the table. From > Murray's follow-up com

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

Preference should be given to the author domain explicitly authorized resigners, how ever that black box functionality is achieved. Currently, there are three DNS-based authorization proposals on the table. From Murray's follow-up comments, the DKIM-delegate is basically an optimizer to avoid

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On 6/11/2014 4:56 PM, John R Levine wrote: >> If a receiver cares about 'strength' (or perhaps robustness) of >> signatures, they should pay attention to that. > > It is my impression that the idea here is that a signature with t= isn't > interesting unless there's a matching signature with d=. O

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

If a receiver cares about 'strength' (or perhaps robustness) of signatures, they should pay attention to that. It is my impression that the idea here is that a signature with t= isn't interesting unless there's a matching signature with d=. Or did I misunderstand that. You are of course cor

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On 6/11/2014 4:15 PM, John Levine wrote: > So if you don't want people using unforwarded weak signatures > for reputation management, you need to put something into them so that > old clients don't accept them as signatures and ignore the t= tag. > Either call them something other than DKIM-Signatu

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

This looks like a cleaner version of my forwarding token proposal. >> You're constraining it to use by a specific, very small set of domains, >> and only for a limited time. > >Then again, let's note that this double-signed mail is going to show up >at some receivers that don't know about DKIM-del

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

Hi Alessandro, On Tue, Jun 10, 2014 at 8:14 AM, Alessandro Vesely wrote: > First, weak signatures which are not part of a chain should be ignored > by verifiers. An authentication chain can be defined as a set of > valid DKIM signatures and possibly an SPF authentication of delegated > domains

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On Tue, Jun 10, 2014 at 8:41 AM, Vlatko Salaj wrote: > > i'm still waiting for u to address the spoofing hole > u left wide open with this approach. > > no, i won't accept "short-lived" as a solution, cause that's > easy to circumvent. > > It means you have a limited time to reuse a delegation si

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On Tuesday, June 10, 2014 5:00 PM, Murray S. Kucherawy wrote: >> DKIM-Delegate suffers from replay attacks, and when not, > DKIM is already replayable. i'm not talking about DKIM, i'm talking about DKIM-D. i'm still waiting for u to address the spoofing hole u left wide open with this approac

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On Sat 07/Jun/2014 12:43:57 +0200 Dave Crocker wrote: > > I've been stewing on this idea for awhile and Murray pressed to get it > into writing, adding his usual, significant enhancements to the original > concept. We've gone a couple of rounds before releasing it, but it's > still nascent enough

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

Murray S. Kucherawy writes: > > It would require MLM to not drop DKIM headers... Still some > > configuration on MLM side, but less in the way messages are > > modified > > That's a much less visible and thus probably more tolerable change > for MLM operators. Mailman added an *optional* c

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

Franck Martin writes: > Sure but you have a strong DKIM signature and a weak DKIM > signature, using about the same domain, it is like the strong DKIM > signature did not exist... Of course, the strong signature exists for the forwarding third party. What the destination should do, is a quest

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On 6/10/2014 4:19 PM, Murray S. Kucherawy wrote: > Yes but are you assuming you only put the weak DKIM signature, when > you specifically know you are emailing a mailing list? > > Or what about a receiver which is not a mailing list? You are just > allowing better replay of the mes

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On Tue, Jun 10, 2014 at 7:13 AM, Franck Martin wrote: > -- > > On Tue, Jun 10, 2014 at 6:58 AM, Franck Martin > wrote: > >> -- >> >> On Mon, Jun 9, 2014 at 11:52 PM, Franck Martin >> wrote: >> >>> This is interesting, however it seems to m

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

- Original Message - > From: "Dave Crocker" > To: "Murray S. Kucherawy" , "Franck Martin" > > Cc: dmarc@ietf.org > Sent: Tuesday, June 10, 2014 4:06:13 PM > Subject: Re: [dmarc-ietf] Fwd: New Version Notification for > draft-kuche

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

- Original Message - > From: "Murray S. Kucherawy" > To: "Franck Martin" > Cc: "Dave Crocker" , dmarc@ietf.org > Sent: Tuesday, June 10, 2014 4:03:16 PM > Subject: Re: [dmarc-ietf] Fwd: New Version Notification for > draft-kucherawy-dkim

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On 6/10/2014 4:03 PM, Murray S. Kucherawy wrote: > Assuming by "strong DKIM signature" you mean the originator signature > that covers the whole message, then given the MLM is going to invalidate > it, it basically doesn't exist. If it happens to survive (such as to recpients of the original mess

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On Tue, Jun 10, 2014 at 6:58 AM, Franck Martin wrote: > -- > > On Mon, Jun 9, 2014 at 11:52 PM, Franck Martin > wrote: > >> This is interesting, however it seems to me that DMARC should be more >> aware of it if used. >> > > Why? This is a way of satisfying the align

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

- Original Message - > From: "Murray S. Kucherawy" > To: "Franck Martin" > Cc: "Dave Crocker" , dmarc@ietf.org > Sent: Tuesday, June 10, 2014 3:47:56 PM > Subject: Re: [dmarc-ietf] Fwd: New Version Notification for > draft-kucherawy-dkim

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On Tue, Jun 10, 2014 at 12:23 AM, Vlatko Salaj wrote: > DKIM-Delegate suffers from replay attacks, and when not, > introduces whitelisting which, kind of, breaks its premise. > DKIM is already replayable. I don't see how this introduces whitelisting requirements. > also, we need a solution th

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On Mon, Jun 9, 2014 at 11:52 PM, Franck Martin wrote: > This is interesting, however it seems to me that DMARC should be more > aware of it if used. > Why? This is a way of satisfying the alignment requirement on the DKIM side. DMARC doesn't need to know it's there. The same is true of ATPS,

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

DKIM-Delegate suffers from replay attacks, and when not, introduces whitelisting which, kind of, breaks its premise. also, we need a solution that doesn't risk of being modified by any middle man on message path. DKIM can't offer that, and will never be able to. -- Vlatko Salaj aka goodone http

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

configuration on MLM side, but less in the way messages are modified - Original Message - From: "Dave Crocker" To: dmarc@ietf.org Sent: Saturday, June 7, 2014 12:43:57 PM Subject: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt Folks, I've

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

Stephen, Thanks for the comments... On 6/7/2014 8:08 PM, Stephen J. Turnbull wrote: > Two nits to pick. First, I'd like a whole (sub)section (containing > approximately one sentence :-) for Mediator responsibilities, even if > it's redundant with step 4 of the specification. Maybe a subsection

[dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

Dave Crocker writes: > URL: > http://www.ietf.org/internet-drafts/draft-kucherawy-dkim-delegate-00.txt Merry Christmas for mailing lists! Mailman at least already recommends that sites hosting lists DKIM sign, so we have nothing new to do! Two nits to pick. First, I'd like a whole (sub)secti

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

This idea is repeating the same thing again. What would "DKIM-Delegate compliant" systems do when the "new information" is missing? What do you do when there are protocol faults? What are the protocol faults? Mr Crocker, you have been leading the DKIM project since day one. You have always

[dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

Folks, I've been stewing on this idea for awhile and Murray pressed to get it into writing, adding his usual, significant enhancements to the original concept. We've gone a couple of rounds before releasing it, but it's still nascent enough to warrant gentle-but-firm handling. In other words, co