Re: [ietf-dkim] versions of RFC822 mail messages, Where is the formal definition of DKIM-Signature?

On 02/11/2018 06:20 PM, Dave Crocker wrote: On 2/11/2018 5:54 PM, Michael Thomas wrote: You clearly have no idea what you are talking about. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html Mike

Re: [ietf-dkim] versions of RFC822 mail messages, Where is the formal definition of DKIM-Signature?

On 02/11/2018 05:46 PM, Dave Crocker wrote: On 2/10/2018 10:47 AM, Michael Thomas wrote: But I still think this entire conversation is silly in its theoreticality. Extra design complexity and consuming development resources -- programming, bench testing, interoperability testing -- for

Re: [ietf-dkim] versions of RFC822 mail messages, Where is the formal definition of DKIM-Signature?

On 02/10/2018 10:22 AM, Dave Crocker wrote: On 2/10/2018 10:12 AM, Michael Thomas wrote: DKIM-Signature-v2: vs DKIM-Signature: v=2; Angels, meet the pinhead. equal semantics does not mean equal implementation. the processing for each of these takes place in very different parts of the

Re: [ietf-dkim] versions of RFC822 mail messages, Where is the formal definition of DKIM-Signature?

On 02/10/2018 10:04 AM, Dave Crocker wrote: On 2/10/2018 9:47 AM, John R Levine wrote: Well, OK, other than DKIM-Improved-Signature how would you do conditional signatures, where the signature has to fail if the semantics of the re-sign tag aren't satisified? Remember that the current rule is

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

On 2/8/18 4:45 PM, Dave Crocker wrote: On 2/8/2018 4:42 PM, Michael Thomas wrote: Besides if you wanted to go from DKIM to EKIM, you'd be opening pandora's box imo. The pandora's box is creating an incompatible new version.  All the rest is just engineering and opera

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

On 2/8/18 12:32 PM, Mark Delany wrote: I think this is the biggest flaw with the whole v= rationale. There is never going to be a v=2 change that doesn't leave everyone continuing to generate/validate a v=1 header. Is a new header by stealth better engineering than formalizing a new header? I

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

On 11/15/16 11:57 AM, Murray S. Kucherawy wrote: On Wed, Nov 16, 2016 at 4:17 AM, Martijn Grooten mailto:mart...@lapsedordinary.net>> wrote: My understanding is an attack where the email is sent to an outside address owned by the sender, who then gets a copy of the email, signed b

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

On 11/15/2016 11:17 AM, Martijn Grooten wrote: On Tue, Nov 15, 2016 at 11:56:11AM -0600, Scott Kitterman wrote: Not at all. As I understand the scenario, the provider knows it's bad, doesn't send the mail on to the outside world, but still gives a signed copy back to the originator (which is th

Re: [ietf-dkim] draft-kucherawy-dmarc-rcpts

On 11/13/2016 09:38 PM, Murray S. Kucherawy wrote: On Sun, Nov 13, 2016 at 9:39 PM, Mark Delany > wrote: Hi Murray. Mark! > RFC6376 and even RFC4871, but now it's apparently happening I'd be interested to hear about the actual scenarios. Are the ta

Re: [ietf-dkim] [Technical Errata Reported] RFC6376 (3758)

On 10/20/2013 06:35 AM, Barry Leiba wrote: > This one's right, of course: no one uses "v=DKIM1"; it's always "v=1". > Authors, was this just left in from the "transition from DK" days? Hmm, my implementation (the first) has it as DKIM1. That says that it's been that way for a long time. Iirc, DK

Re: [ietf-dkim] [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic

On 9/11/13 8:18 PM, MH Michael Hammer (5304) wrote: > > I think you need to look more closely. Many people realized very quickly that > ADSP had significant flaws that made implementation extremely risky for both > senders and mailbox providers. There were a number of private efforts to move > e

Re: [ietf-dkim] [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic

On 9/12/13 12:10 PM, Murray S. Kucherawy wrote: > On Thu, Sep 12, 2013 at 7:57 AM, Michael Thomas <mailto:m...@mtcc.com>> wrote: > > The list of things DMARC does that ADSP doesn't in its appendix, is a > trip down memory lane > of constraints that were plac

Re: [ietf-dkim] [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic

On 9/11/13 9:32 PM, Dave Crocker wrote: > On 9/11/2013 6:41 PM, Michael Thomas wrote: >> It doesn't help that ADSP's author actively wanted to subvert it. >> >> As far as I can tell, DMARC is warmed over ADSP with a different set of >> participants >&g

Re: [ietf-dkim] [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic

On 9/11/13 6:15 PM, Murray S. Kucherawy wrote: > I also agree with this proposal. I don't have much to add over the text in > the formal request; it lays out the case based on my experience > implementing DKIM and ADSP in open source. I can also say that I have never > encountered an operation

Re: [ietf-dkim] Weird i= in client mail

On 06/18/2013 07:18 AM, Tony Hansen wrote: > On 6/18/2013 12:43 AM, Dave Crocker wrote: >> On 6/17/2013 9:20 PM, Franck Martin wrote: >>> On Jun 17, 2013, at 8:58 PM, John Levine wrote: > At one stage i= was thought to represent different mail streams with > different reputation, > ho

Re: [ietf-dkim] The good ol' "t=" tag in key records

On 07/23/2012 06:13 AM, Barry Leiba wrote: >> That customer brought up an interesting point. "t=y" could also be useful >> for messages whose signatures do verify. Specifically, it could be used by >> a signer to say "It's possible this message shouldn't have been signed by >> us. Please don't

Re: [ietf-dkim] The good ol' "t=" tag in key records

On 07/23/2012 06:47 AM, Murray S. Kucherawy wrote: > On Mon, Jul 23, 2012 at 6:42 AM, Michael Thomas <mailto:m...@mtcc.com>> wrote: > > There seems like there are many things wrong with this sort of > "helpfulness". If a given selector is dodgy, the reputa

Re: [ietf-dkim] No signatures, bad signatures, cousin domains

On 05/25/2011 01:05 AM, Murray S. Kucherawy wrote: > Interesting. I ran some queries on our data for ebay.com, paypal.com, > chase.com and bankofamerica.com. In all cases, messages with failed > signatures were never tagged by Spamassassin, and at most 7% (usually less) > of unsigned mail wher

Re: [ietf-dkim] Certifying the DKIM public key?

On 05/23/2011 11:17 AM, Dave CROCKER wrote: > As an impressive example of even deeper misunderstanding: > More of CROCKER's famed civility. >> On 5/22/2011 10:49 AM, Michael Thomas wrote: >> >>> But this is exactly what DKIM is. You prove yourself fsvo

Re: [ietf-dkim] Certifying the DKIM public key?

On 05/22/2011 10:27 AM, John R. Levine wrote: > It occurs to me that since mail certification is likely to make assertions > about behavior as well as identity, the SSL model in which certs last for > a year won't work, since behavior can change rapidly. Either the > certifier has to issue a strea

Re: [ietf-dkim] Certifying the DKIM public key?

On 05/22/2011 08:02 AM, Dave CROCKER wrote: > > 3. As noted, certification was explicitly de-coupled from DKIM. I'll claim > that > it really is a separate, value-added service and any support of it should be > through a separate, value-added mechanism. My own preference would be for > using >

Re: [ietf-dkim] 8bit downgrades

On 05/19/2011 07:20 PM, John Levine wrote: >> Can anyone remember why there's a SHOULD for the downgrade to 7-bit in >> RFC4871 Section 5.3, rather than a MUST? The likelihood of breakage is >> so high when sending 8-bit data that DKIM almost becomes pointless >> without the upgrade. >> > I

Re: [ietf-dkim] 8bit downgrades

On 05/19/2011 07:11 PM, Pete Resnick wrote: > On 5/19/11 6:09 PM, Michael Thomas wrote: >> We send things that get forwarded through all kinds of manglers, >> 8bit manglers just being one variety. In the abstract, you can never >> know >> as a signer that a path is

Re: [ietf-dkim] 8bit downgrades

On 05/19/2011 02:53 PM, Pete Resnick wrote: > In this case, the spec says that you MUST downgrade prior to signing > *unless you know that the end-to-end path is 8-bit clean and will not > downgrade later*. That's what SHOULD downgrade means. If there is an > implementation that doesn't downgrad

Re: [ietf-dkim] 8bit downgrades

On 05/19/2011 10:50 AM, Murray S. Kucherawy wrote: > > Can anyone remember why there’s a SHOULD for the downgrade to 7-bit in > RFC4871 Section 5.3, rather than a MUST? The likelihood of breakage is > so high when sending 8-bit data that DKIM almost becomes pointless > without the upgrade. > > >

Re: [ietf-dkim] New canonicalizations

On 05/16/2011 09:39 AM, Dave CROCKER wrote: > Sorry, but I believe the above also does /not/ help us to understand actual > survivability differences. > > To assess that difference, the experiment needs to send the same set of > message > twice, one with each type of canonicalization, and then see

Re: [ietf-dkim] New canonicalizations

On 05/16/2011 07:40 AM, Mark Delany wrote: > On 16May11, Alessandro Vesely allegedly wrote: >> OTOH, comparing the "count" fields of those two lines, 86% relaxed vs >> 14% simple, says that such kind of benefit is really really wanted. >> > But that's a perceived benefit, not an actual one. >

Re: [ietf-dkim] Issue: Consider deprecating "l="

On 05/09/2011 02:28 PM, Barry Leiba wrote: > Semantics first: we don't "vote" here. > > OK, that taken care of, it's a fair request, because there's been a > lot of discussion about it. We certainly have a good base of support > for deprecating "l=". > > So I'll ask it this way, starting a new thr

Re: [ietf-dkim] Issue: Consider deprecating "l="

On 05/09/2011 02:39 PM, Murray S. Kucherawy wrote: > - the PS-DS promotion "rules" say we should cut stuff that's not actually in > use, but this is; > - we therefore don't have any data to conclude that there isn't anyone out > there that finds it exceptionally useful despite the dangers >

Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output

On 05/06/2011 08:12 AM, Rolf E. Sonneveld wrote: > John, the opendkim project gathers information from various sources, > they're not necessarily the users of Murray and they're not necessarily > subscribed to mailing lists. The statistics also doesn't tell which > inbound mail is from legitimate s

Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

On 05/04/2011 08:34 PM, Murray S. Kucherawy wrote: > Technical: The AUID is an unvetted value. The local-part and the subdomain > could be garbage. It's inappropriate for a security protocol to return a > possibly false value in the context of saying something was cryptographically > validated

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

On 05/05/2011 03:35 AM, Rolf E. Sonneveld wrote: > Excuse me for my poor English, I shouldn't have used the word 'certify' > here. I'm not talking about validity of content. Were I used the word > 'certify' I mean: > > if a DKIM signature verifies successfully, the consumer can be sure that > the b

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

On 05/04/2011 04:40 PM, Dave CROCKER wrote: [] I'll do Barry the favor of stopping this inane conversation, much as it amuses me. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

On 05/04/2011 03:55 PM, Rolf E. Sonneveld wrote: > > Well, I think you both are right in reading what my concern/objection > against 4871bis is. And maybe you're also right in that RFC4871 wasn't > that much different of RFC4871bis. > > I think in the early days of DKIM most people assumed DKIM w

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

On 05/04/2011 02:53 PM, Dave CROCKER wrote: > > > On 5/4/2011 2:47 PM, Michael Thomas wrote: >> On 05/04/2011 02:32 PM, Dave CROCKER wrote: >>> >>> On 5/4/2011 2:29 PM, Michael Thomas wrote: >>>> I should also expand that this entire situation starte

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

On 05/04/2011 02:32 PM, Dave CROCKER wrote: > > On 5/4/2011 2:29 PM, Michael Thomas wrote: > >> I should also expand that this entire situation started with Crocker >> insisting that we must "choose" between between i= and d= >> as The Output. It was a fa

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

On 05/04/2011 02:11 PM, Michael Thomas wrote: > On 05/04/2011 01:57 PM, Murray S. Kucherawy wrote: > >> And who gets to define "appropriate"? >> >> It's already been pointed out that we could list every current tag's value >> and a pile of o

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

On 05/04/2011 01:57 PM, Murray S. Kucherawy wrote: > And who gets to define "appropriate"? > > It's already been pointed out that we could list every current tag's value > and a pile of other stuff to pass on to the next layer, which may or may not > find it useful, but that would make for an ext

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

On 05/04/2011 11:26 AM, Dave CROCKER wrote: >> It's because I didn't want to imply that those were the only two. > > This is quite a remarkable premise for refusing to provide concrete > substance. > > I'm trying to imagine how a working group could ever make progress, > were this premise prevale

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

On 05/04/2011 12:08 PM, Murray S. Kucherawy wrote: >> -Original Message- >> From: Michael Thomas [mailto:m...@mtcc.com] >> Sent: Wednesday, May 04, 2011 12:08 PM >> To: dcroc...@bbiw.net >> Cc: Dave CROCKER; Murray S. Kucherawy; ietf-dkim@mipassoc.org >

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

On 05/04/2011 11:53 AM, Dave CROCKER wrote: >> Considerations Section 8. To avoid this attack, signers should >> be extremely wary of using this tag, and verifiers might wish >> to ignore the tag. >> > To avoid this attack, signers need to be extremely wary of u

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

On 05/04/2011 11:03 AM, Murray S. Kucherawy wrote: >> -Original Message- >> From: Michael Thomas [mailto:m...@mtcc.com] >> Sent: Wednesday, May 04, 2011 10:54 AM >> To: Murray S. Kucherawy >> Cc: dcroc...@bbiw.net; ietf-dkim@mipassoc.org >> Sub

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

On 05/04/2011 10:43 AM, Murray S. Kucherawy wrote: >> -Original Message- >> From: Michael Thomas [mailto:m...@mtcc.com] >> Sent: Wednesday, May 04, 2011 10:29 AM >> To: Murray S. Kucherawy >> Cc: dcroc...@bbiw.net; ietf-dkim@mipassoc.org >> Sub

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

On 05/04/2011 10:25 AM, Murray S. Kucherawy wrote: > I count at least two new normative changes -- in informational notes > of all places -- by scanning *half* the document, both of which are wrong. > What were the two normative changes in informational notes that were wrong in

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

On 05/04/2011 10:13 AM, Murray S. Kucherawy wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] >> On Behalf Of Michael Thomas >> Sent: Wednesday, May 04, 2011 10:11 AM >> To: dcroc...@bbiw.net

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

On 05/04/2011 09:14 AM, Dave CROCKER wrote: > I've uploaded Murray's helpful effort to the DKIM site: > > > > I had assumed that the complete diff would be unreadable, which is why I > originally put up the incremental diffs. > > However in loo

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

On 05/04/2011 09:15 AM, Murray S. Kucherawy wrote: >> -Original Message- >> From: Michael Thomas [mailto:m...@mtcc.com] >> Sent: Wednesday, May 04, 2011 9:03 AM >> To: Murray S. Kucherawy >> Cc: Rolf E. Sonneveld; dcroc...@bbiw.net; ietf-dkim@mipassoc.org >

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

On 05/04/2011 08:51 AM, Murray S. Kucherawy wrote: >> Both documents refer to rfc4686, albeit only in the Informative >> References section. rfc4871 refers to rfc4686 only in section 8, >> rfc4871bis in section 8 as well as in section 1.1. >> > There are two main fallacies that appear to be b

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

On 05/04/2011 08:16 AM, Dave CROCKER wrote: > Michael, > > > On 5/4/2011 7:58 AM, Michael Thomas wrote: >> This is a good example of why this effort has come off the rails. >> Going from 4871 to DS should have been a fairly straightforward >> effort considering the h

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

On 05/04/2011 07:08 AM, Dave CROCKER wrote: > The claim that rfc4871bis has the goal you claim is yours. > > So you need to do the work of subtantiating it. > > So far, as you acknowledge, your only reference is quite old, merely > informative, and not a specification. In contrast, rfc4871bis decl

[ietf-dkim] "Output" considered harmful

On 05/04/2011 05:04 AM, John R. Levine wrote: >> For a scenario where a caller is calling a DKIM milter which in turn calls an >> API, this is all true. But DKIM will be/is deployed in many more scenarios. >> > Indeed, but you're misunderstanding the point of a standard. The DKIM > spec tell

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

Dave CROCKER wrote: > > On 4/30/2011 9:10 PM, 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. Thi

Re: [ietf-dkim] Output summary

Murray S. Kucherawy wrote: >> -Original Message- >> From: Michael Thomas [mailto:m...@mtcc.com] >> Sent: Friday, April 29, 2011 4:37 PM >> To: Rolf E. Sonneveld >> Cc: Murray S. Kucherawy; ietf-dkim@mipassoc.org >> Subject: Re: [ietf-dkim] Output sum

Re: [ietf-dkim] Output summary

Rolf E. Sonneveld wrote: > Don't get me wrong, I just wanted to demonstrate that, IF we follow the > logic of not crossing protocol boundaries strictly, THEN communicating > the d= payload /without additional information/, we > > * either enforce upper layers to violate layers or > * in

Re: [ietf-dkim] despair

On 04/27/2011 12:19 PM, Barry Leiba wrote: > > > >> Complaining is easy. >> > Indeed so. And so let's cut the meta-discussion and not go back to > throwing darts around. To the points: > > Mike's concern is valid. > > Murray's and Dave's notes have addressed it. > I don't see how

Re: [ietf-dkim] despair

On 04/27/2011 09:45 AM, Murray S. Kucherawy wrote: >> -Original Message- >> From: Michael Thomas [mailto:m...@mtcc.com] >> Sent: Tuesday, April 26, 2011 4:31 PM >> To: Murray S. Kucherawy >> Cc: DKIM IETF WG >> Subject: Re: [ietf-dkim] despair >>

Re: [ietf-dkim] despair

On 04/27/2011 09:53 AM, Dave CROCKER wrote: > With that sort of documented history, the responsibility to claim otherwise > falls on the critic. Otherwise the wg is essentially being asked to prove a > negative and almost serves as a DOS attack... > Denial of service on what/whom? As far as I

Re: [ietf-dkim] despair

On 04/26/2011 04:03 PM, Murray S. Kucherawy wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- >> boun...@mipassoc.org] On Behalf Of Michael Thomas >> Sent: Tuesday, April 26, 2011 2:43 PM >> Cc: DKIM IETF WG >> Subj

[ietf-dkim] despair

There sure seems to be an awful lot of changes going on for a supposed draft standard document. I for one can't keep up with the rate of change, and I doubt anybody else can either. I really don't care if each individual piece can -- microscopically -- be justified within the process of draft stan

Re: [ietf-dkim] Issue: Section 4.3 Hash method Note

On 04/25/2011 01:57 PM, Barry Leiba wrote: > Dave further tweaks: > >> INFORMATIVE NOTE: Although use of rsa-sha256 is strongly encouraged, >> some senders might prefer to use rsa-sha1 when balancing security >> strength against performance, complexity, or other needs. Howeve

Re: [ietf-dkim] ADSP stats

On 04/20/2011 04:13 PM, Murray S. Kucherawy wrote: >> That isn't a helpful metric. The 99% most likely domains to >> have a ADSP record are ones where you see DKIM signatures >> and they pass. So if you're only checking domains without >> DKIM signatures (broken or otherwise), you're going to get >

Re: [ietf-dkim] ADSP stats

On 04/20/2011 01:29 PM, Murray S. Kucherawy wrote: > There has been no uptake at all in OpenDKIM for ATPS, and almost none is > apparent with ADSP, although in the latter case our data can only give a > range for adoption because we don't query when an author signature passes. > That isn't a

Re: [ietf-dkim] ADSP stats

Murray S. Kucherawy wrote: > If ADSP is too weak or dangerous a protocol, and there are no current viable > alternatives, then failing to beat the streets to get the industry to deploy > it is an act of responsibility, not one of omission or laziness. My feeling is that it conflicts with too man

Re: [ietf-dkim] Extensions (was RE: Proposal: Removal of AUID (i= tag/value))

On 04/06/2011 01:18 PM, Steve Atkins wrote: >> Yes it does. In your example, a second signer who isn't >> privy to whether it knows the birth date could either sign >> it because it wants to keep transport integrity, or not >> sign it because it doesn't actually know the veracity of >> the X-Birthd

Re: [ietf-dkim] Extensions (was RE: Proposal: Removal of AUID (i= tag/value))

On 04/06/2011 12:34 PM, Steve Atkins wrote: > On Apr 6, 2011, at 11:05 AM, Michael Thomas wrote: > \ > >> The alternative would be very squirrelly when you think >> of the general case of multiple signers in the path. >> > The approach I suggest has no pr

Re: [ietf-dkim] Extensions (was RE: Proposal: Removal of AUID (i= tag/value))

On 04/06/2011 10:53 AM, Murray S. Kucherawy wrote: > >> Having cross semantic correlation of what headers mean with the >> presence of dkim signatures from various different signers seems >> like a lot more of layer violation to me. >> > That a DKIM hash covers a header field doesn't assign a

Re: [ietf-dkim] Extensions (was RE: Proposal: Removal of AUID (i= tag/value))

On 04/06/2011 10:25 AM, Murray S. Kucherawy wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] >> On Behalf Of Michael Thomas >> Sent: Wednesday, April 06, 2011 9:43 AM >> To: Steve Atkins >> Cc

Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

On 04/06/2011 09:29 AM, Steve Atkins wrote: > On Apr 6, 2011, at 9:07 AM, Michael Thomas wrote: > There is something to be said about using tags in the signature > rather than signed headers. Signers don't have to have any > reason -- and none should be inferred -- for signing a

Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

On 04/06/2011 08:48 AM, Steve Atkins wrote: > That sounds like a fragile way to extend things - leave a little used feature > around and hope someone who wants something new hijacks that > field in a non-conflicting way instead. (Which may not be what you're > suggesting, but it's an implication I'

Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

John R. Levine wrote: >> Flip that around: I want to give positive warm fuzzies to mail from the >> users that are authenticated by bigisp.com and are on my positive list. > > I believe that's what we call "human shields." Um, no. This whole model > of bigisp sending a mixture of legit and forg

Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

Dave CROCKER wrote: > The distinction that needs to be made is between formally-specified output > vs. > implementation-specific access to DKIM internals. > i= was never intended to be "DKIM internals". That's why the entire gambit to make d= the only show in town sucked. Mike

Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

Murray S. Kucherawy wrote: >> The working group was bamboozled into the false dilemma >> that DKIM had to produce a singular "output". It has all >> gone down hill from there. Things that use heuristics like >> spam filters thrive with more information, and suffer with >> less. So we've destroyed i

Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

On 03/31/2011 02:33 PM, Jim Fenton wrote: > The direction of the DKIM specifications since RFC 4871 have been to > rely less and less on the AUID (agent or user identifier, the i= value > on the signature) to the point that it provides no security benefit. > The working group was bamboozled in

Re: [ietf-dkim] DKIM using old RSA padding?

Hanno Böck wrote: > Am Mon, 28 Feb 2011 09:44:25 -0500 > schrieb Dave CROCKER : > >> Just for archive completeness (and to comfort folks like me who lack >> crypto clue) could you offer a very brief summary of the difference >> between what DKIM currently uses and what is being suggested, >> espe

Re: [ietf-dkim] Re-thinking the organization of the DKIM spec

Snatching defeat from the jaws of victory: -1 Mike Barry Leiba wrote: > The chairs are happy with how this discussion has been going so far, > except that we remind people that discussion of any details of > iSchedule or any other protocol that might cite DKIM is entirely out > of scope -- we ne

Re: [ietf-dkim] Re-thinking the organization of the DKIM spec

J.D. Falk wrote: > On Jan 11, 2011, at 4:12 AM, Eliot Lear wrote: > >> 2. The mechanisms in DOSETA were designed for DKIM. If we are generalizing >> along the lines that Dave has mentioned, I would prefer that DOSETA in >> particular not advance to draft status, as it ought to be tested in at

Re: [ietf-dkim] Re-thinking the organization of the DKIM spec

Oh, good. I'm not the only party pooper. To what Jim wrote, I'll add: 1) As a developer, multiple documents generally suck. IKE, ISAKMP, and their friends. Need I say more? 2) Frameworks almost invariably fail, and that's what I sense here. We gave some passing thought to making this usa

Re: [ietf-dkim] Statistics about DKIM and MIME

On 10/25/2010 10:01 AM, Murray S. Kucherawy wrote: In the particular case of multipart/signed there were 106 messages where the RSA verification failed, but 122 where it passed but the body hash at the verifier didn't match the one in the signature. So more failures occur from body changes th

Re: [ietf-dkim] double header reality check

On 10/20/2010 04:36 PM, Steve Atkins wrote: > > On Oct 20, 2010, at 3:19 PM, Murray S. Kucherawy wrote: >>> Validating mail syntax belongs in the specification for the mail components and DKIM work belongs in the DKIM components. >>> >>> That's why, layer violation or no, I think it's imp

Re: [ietf-dkim] double header reality check

On 10/20/2010 01:31 PM, Rolf E. Sonneveld wrote: >On 10/20/10 9:30 PM, MH Michael Hammer (5304) wrote: >> Seeing as the M in DKIM stands for Mail, we don't have to put a "but >> only when used in the email context" clause. If a DKIM like approach is >> used for other protocols then we might rea

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

On 10/19/2010 06:18 AM, Wietse Venema wrote: > valid signature + good signer > + no suspicious unsigned content -> good message Has nobody learned that "good" signers from "good" authors can still be evil? I mean come on, people, bot'd machines? This is horrible advice. s/unsigned/; and

Re: [ietf-dkim] sophistry is bad, was Data integrity claims

Far be it for me to defend Dave, but I think you two are in violent agreement. I think you misread some of Dave's comment because they were posed as rhetorical. Mike On 10/16/2010 11:56 AM, Scott Kitterman wrote: > On Saturday, October 16, 2010 10:50:25 am Dave CROCKER wrote: >> On 10/16/2010 10:

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

On 10/15/2010 10:45 AM, Stephen Farrell wrote: > In this case, I don't recollect an objection, so thus far, it seems > to me that Dave's correct on this one. I think its perfectly fine > for an editor to try to close off things that seem to have a clear > consensus like this. Stephen -- the issue

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

On 10/15/2010 11:19 AM, Dave CROCKER wrote: > > > On 10/15/2010 1:32 PM, Barry Leiba wrote: >>> Dave killfile's >>> many participants, therefore any consensus he sees will merely reflect >>> the echo chamber of his own making. >>> >>> So I strongly object on procedural grounds > ... >> >> Mike

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

On 10/15/2010 10:32 AM, Barry Leiba wrote: >> I'd like to ask a procedural question of the chairs: Dave killfile's >> many participants, therefore any consensus he sees will merely reflect >> the echo chamber of his own making. >> >> So I strongly object on procedural grounds for authors who kill f

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

On 10/15/2010 08:28 AM, Dave CROCKER wrote: > > > On 10/15/2010 10:28 AM, Jeff Macdonald wrote: >> On Thu, Oct 14, 2010 at 6:33 PM, Dave CROCKER wrote: >>> >>> Although some folk have done a +1 for one (or another) removal, I'd like to >>> get >>> a round of explicit reactions to the specific id

Re: [ietf-dkim] layer violations, was detecting header mutations after signing

On 10/15/2010 06:51 AM, Charles Lindsey wrote: > 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

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

On 10/14/2010 11:54 AM, Barry Leiba wrote: > On Thu, Oct 14, 2010 at 9:05 AM, Tony Hansen wrote: >> Even though I supported the addition of wording on how to improve the >> compatibility with DomainKeys records, I would support removing the new >> proposed section 3.6.1.1 for the reasons Dave brin

Re: [ietf-dkim] layer violations, was detecting header mutations after signing

On 10/14/2010 10:47 AM, Murray S. Kucherawy wrote: >> -Original Message- >> From: John R. Levine [mailto:jo...@iecc.com] >> Sent: Thursday, October 14, 2010 10:45 AM >> To: Murray S. Kucherawy >> Cc: DKIM List >> Subject: Re: [ietf-dkim] layer violations, was detecting header mutations >>

Re: [ietf-dkim] layer violations, was detecting header mutations after signing

On 10/14/2010 10:15 AM, John R. Levine wrote: >> If you really think this is such a great big problem, maybe you should be >> banging the drums at MAAWG or other venues where the correct set of ears >> is potentially listening. > > I would rather not have to run a session at MAAWG entitled "How to

Re: [ietf-dkim] layer violations, was detecting header mutations after signing

On 10/14/2010 09:45 AM, John R. Levine wrote: >> Unless there's *really* something they can't figure out without protocol >> help, I'm not sure what the point of this is. This double added From thing >> is trivial to detect with the current spec. > > Well, yeah. That's why I don't understand why p

Re: [ietf-dkim] layer violations, was detecting header mutations after signing

On 10/14/2010 07:56 AM, Mark Delany wrote: > On Thu, Oct 14, 2010 at 07:38:13AM -0700, Mark Delany allegedly wrote: >>> What is essential is that it perform the task of validating and delivering a >>> signing domain that is associated with a collection of bits. Anything that >>> defines how to do

Re: [ietf-dkim] layer violations, was detecting header mutations after signing

On 10/14/2010 07:58 AM, John R. Levine wrote: >> Perhaps surprisingly, having redundant header fields does not make >> DKIM break. > > We must have some vastly different definition of "break". > > If allowing through modified messages that render very differently isn't > broken, shouldn't we remove

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] 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] 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] detecting header mutations after signing

On 10/07/2010 05:01 PM, John R. Levine wrote: >>> I'd say that it would be better to just say that if you sign a >>> non-compliant 5322 message that its verification is undefined, >>> and move on. That at least matches reality, and hasn't hurt >>> anything that I'm aware of. > > Except that's not t

Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE

On 10/07/2010 11:01 AM, Murray S. Kucherawy wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] >> On Behalf Of Michael Thomas >> Sent: Thursday, October 07, 2010 9:09 AM >> To: Charles Lindsey >>

Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE

On 10/07/2010 03:40 AM, Charles Lindsey wrote: > 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 w

Re: [ietf-dkim] signing and verifying invalid messages

On 10/05/2010 01:36 PM, John Levine wrote: >> Still, though, it's a solution to deal with malformations to which >> MUAs are susceptible, and not strictly a DKIM problem. > > Would it be a good idea to recommend in 4871bis that DKIM > implementations should not sign or verify invalid messages? I >

  1   2   3   4   5   6   7   8   9   10   >