Re: [ietf-dkim] DKIM and EAI
On Friday, February 09, 2018 05:02:00 PM John R. Levine wrote: > > If I may once again change the topic for a moment ... > > > > https://datatracker.ietf.org/doc/draft-levine-appsarea-eaiauth/ > > I pushed out a new version that says something about SPF macros, > attempting to say that if you try to expand a UTF-8 local part, it doesn't > match anything. I figure this is consistent with what would happen if > your local part was something like foo..bar which won't match anything > either. > > I would appreciate if people would take a look and see if anything seems > obviously wrong. I'm doing some EAI whitepapery things for ICANN and it > would be nice if, for a change, the advice they offer matches reality. Thanks. I think that's a reasonable resolution of the SPF macro issue that I raised. Not ideal, in theory, but plenty good enough for the corner case it is. Does this need to update RFC 7208 since there are SPF related MUST requirements? Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts
On November 17, 2016 2:57:00 PM CST, "Murray S. Kucherawy" wrote: >On Thu, Nov 17, 2016 at 9:51 PM, Michael Storz >wrote: > >> >> Thanks, I see. That means the recipient is bound to the message and >an >> attacker cannot delete or change the new tags. Great solution, I like >it, >> though I do not like the consequences when this extension will go >into >> production. >> >> >You may not need to worry about that. We've reached a point where I >think >we can legitimately say, "We took a serious look, and this is the best >we >could come up with. It has some pretty ugly side effects. Are you >sure >you can't just stop signing spam?" And absent a compelling answer to >that >question, there's no need to roll this out even as an experiment. That's great to hear. You might suggest (if it's someone that does DMARC p=reject) that if they can manage to stop signing reasonably likely (FSVO reasonable) spam they'll get roughly what the proposed protocol change would have provided for that mail without having to wait for the world to upgrade. Direct mail would still pass DMARC due to SPF. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts
Note: Not cc'ing the DMARC list as this is a DKIM only draft. Given the discussions about twice ranging implications of a change like this (the end of email where RCPT TO changes in transit to start), the document needs far more discussion regarding the impact on the current email architecture before it can be considered in any way complete. As much as I appreciate having my input acknowledged, please remove me from the acknowledgement section. If this proposal is going to go forward, I don't want my name on it anywhere. Scott K On November 15, 2016 7:45:52 PM CST, "Murray S. Kucherawy" wrote: >There's been a lot of great feedback here. I just cranked out an >update >based on the discussion so far: > >https://www.ietf.org/rfcdiff?url2=draft-kucherawy-dkim-rcpts-01 > >I forgot to update the title of Section 3, but other than that I think >I >captured what's been discussed. Please let me know what I've missed. > >-MSK > > >On Tue, Nov 15, 2016 at 8:07 AM, Murray S. Kucherawy > >wrote: > >> On Mon, Nov 14, 2016 at 10:36 PM, wrote: >> >>> Let's break this down. If we're going to include recipients in the >DKIM >>> signature, it seems we have at least three key design decisions to >make: >>> [...] >>> >> >> That's a pretty excellent summary. A couple of points: >> >> I think you narrowed it down to (0)(b), (1)(a), (2)(d), and (3)(b) >being >> the ideal choices. Is that correct? If so, we would just need to >> determine the algorithm for generating the signed content that would >be >> included in the augmented signature. If we do something like the >random >> salt suggestion, is this sufficient? >> >> - pick a random string S of length L using only printable ASCII >characters >> (I like 8 for L but that's arbitrary) >> - SHA the string produced by prepending S to the recipient address, >and >> express the result in base64 string R >> - include R in a new "er" (envelope recipient) tag and the salt S in >an >> "rs" (recipient salt) tag >> >> This is not reversible so nothing is leaked, but as we've all >conceded by >> now it's not hard to attack this to recover the hashed address >especially >> since one might have good guesses as to what that address would be. >> >> I can't see the point of actually encrypting the hashed content, >because >> anybody can decrypt it with the public key. >> >> What am I missing? >> >> -MSK >> > > > > >___ >dmarc mailing list >dm...@ietf.org >https://www.ietf.org/mailman/listinfo/dmarc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts
On November 15, 2016 10:53:19 AM CST, Martijn Grooten wrote: >On Mon, Nov 14, 2016 at 07:42:16AM -0500, Scott Kitterman wrote: >> OK. Ultimately, "don't sign spam" has got to be the solution or >reputation is >> going to suffer, so I think they are going to have to eventually bite >the >> bullet and fix it. > >I think you underestimate how difficult it is to detect spam in cases >like this. Good spam, from a spammer's point of view, looks like >legitimate email, except that it's sent in bulk, or links to some bad >site (malware/phishing), or has a malicious attachment. The attachment >aside, none of this has to be present when the first instance of the >email is sent (and signed). And even detecting new malware isn't as >trivial as it may sound. 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 then available for replay). Given that scenario, they've already done the hard part. All the protocol solutions being discussed have huge negative implications for email. I've yet to see a proposal I think should be implemented (my suggestion about a now DMARC policy option still seems the least bad to me, but I don't particularly like it). Scott K Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts
On Monday, November 14, 2016 05:34:19 PM Murray S. Kucherawy wrote: > On Mon, Nov 14, 2016 at 4:37 PM, Scott Kitterman > > wrote: > > >Doesn't that presuppose point-to-point handling? The proposal here > > >doesn't. > > > > Your proposal breaks all non-point-to-point handling, if I understand it > > correctly, so whether you make DKIM signatures non-forwardable or do it in > > DMARC policy, it's the same end result. > > How does it break all non-point-to-point handling? It does break if the > envelope has to change, but that's not what I think of when you say > "point-to-point"; it makes me think of mail from A to C that happens to > transit B, which should survive just fine. Within an ADMD, internal relaying should survive just fine, since, as you say, RCP TO doesn't change, but I don't think that's an interesting case. Email authentication check tend to be very fragile if not done at the edge of the ADMD for lots of reasons. What I was thinking of was non-point-to-point handling while between two ADMDs. Typically mailing lists or transparent forwarding. In both of those cases, RCPT TO changes. One set of advice given to mailing list operators about DMARC has been to change their list setup so that they don't break DKIM signatures (and some have done that). This proposal would make that impossible. Between two ADMDs, you would not be able to change RCPT TO, so it would have to go direct. At that point, if you engage DMARC alignment requirements on the SPF check, you achieve the same result. Also, if you make this a DMARC policy choice, then the added restrictions associated with restricting changes to RCPT TO only affect senders that have opted into the policy choice. > > I think your pushing a substantial change to DKIM and to the extent this > > is a reasonable problem to solve, DKIM isn't the right layer in the email > > authentication stack to do it. > > Ah, yes, that's a plausible argument. > > > I think the solution to "I have a problem that results when I sign spam" > > is "don't do that", not the entire community turns on its head to work > > around someone's local configuration problems. > > Yes, I agree that's the preferable solution. It sounds as if there are > some operators (well, at least one, I think) that are having a problem for > which "don't do that" is an expensive solution, and a question has been > posed about the possible existence of an easy, incremental protocol > solution for it. It's fine if the answer is "no", but I'd like to have the > discussion without prematurely slamming any doors. OK. Ultimately, "don't sign spam" has got to be the solution or reputation is going to suffer, so I think they are going to have to eventually bite the bullet and fix it. I don't think an opt-in extension to DMARC like I suggest above is unreasonable and I think it would be able to be deployed more quickly. So far though, I don't see fixing it in DKIM as a good way to go. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts
On November 14, 2016 12:50:01 AM EST, "Murray S. Kucherawy" wrote: >On Mon, Nov 14, 2016 at 5:41 AM, Scott Kitterman > >wrote: > >> Wouldn't a DMARC option to allow senders to specify only messages >that >> pass verification and alignment for BOTH SPF and DMARC accomplish the >same >> result with less complexity and without the layering violation >inherent in >> this proposal? >> > >Doesn't that presuppose point-to-point handling? The proposal here >doesn't. Your proposal breaks all non-point-to-point handling, if I understand it correctly, so whether you make DKIM signatures non-forwardable or do it in DMARC policy, it's the same end result. > >> DMARC seems to be the policy engine of choice in the community (for >better >> or for worse). I think addressing this at the policy level makes >more >> sense than changing the semantics of DKIM signatures after almost a >decade >> of deployment. >> > >As the problem was presented to me, I haven't heard that DMARC is >specifically involved here. It might be (maybe even "probably" is >apt), >but I haven't heard that, so I limited this idea to just the DKIM >signing >and verifying components of the system. I think your pushing a substantial change to DKIM and to the extent this is a reasonable problem to solve, DKIM isn't the right layer in the email authentication stack to do it. > >> P.S. With my Debian OpenDKIM maintainer hat on, I'm not immediately >> convinced I'd want to enable this feature. I don't know if other >distro >> maintainers are on this list or not, but that's one opinion. It's >not >> guaranteed to be widely deployed. >> > >Why is this a distribution issue? Because so far this looks like a source of interoperability problems and bug report headaches I could do without. I think the solution to "I have a problem that results when I sign spam" is "don't do that", not the entire community turns on its head to work around someone's local configuration problems. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts
On November 13, 2016 1:50:05 AM EST, "Murray S. Kucherawy" wrote: >I've posted a draft that attempts to address an attack that's begun to >appear with DKIM. Interestingly, we called it out as a possible attack >in >RFC6376 and even RFC4871, but now it's apparently happening and being >annoying enough that people (I believe from the MAAWG community) are >asking >if there's a protocol solution that's possible. > >https://datatracker.ietf.org/doc/draft-kucherawy-dkim-rcpts/ > >Comments welcome. Wouldn't a DMARC option to allow senders to specify only messages that pass verification and alignment for BOTH SPF and DMARC accomplish the same result with less complexity and without the layering violation inherent in this proposal? DMARC seems to be the policy engine of choice in the community (for better or for worse). I think addressing this at the policy level makes more sense than changing the semantics of DKIM signatures after almost a decade of deployment. Scott K P.S. With my Debian OpenDKIM maintainer hat on, I'm not immediately convinced I'd want to enable this feature. I don't know if other distro maintainers are on this list or not, but that's one opinion. It's not guaranteed to be widely deployed. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Key Sizes
On Sunday, October 30, 2016 05:50:33 PM John R. Levine wrote: > > It's also probably worth ensuring that the major open source DKIM > > implementations support both signing and verifying with 4096-bit keys. > > Aside from OpenDKIM and dkimpy, are there any others that should be > > checked? > Perl Mail::DKIM is still widely used. It calls Crypt::OpenSSL::RSA which > is a wrapper around openssl so I'd be surprised if it had trouble with > large keys. There's also https://sourceforge.net/projects/libdkim/ by ALT-N. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Key Size Constraints
On Tuesday, May 12, 2015 09:27:51 PM Murray S. Kucherawy wrote: > On Tue, May 12, 2015 at 8:28 PM, Scott Kitterman > > wrote: > > > Is it appropriate to change the protocol document for this? Isn't it > > > really more of a BCP? > > > > I think when key size got put in the protocol, then it's a protocol update > > to > > change it. > > Is it part of the protocol, or is it part of the prose around the protocol? > > The DKIM algorithms don't break if you use weak keys any more than they > break if you put false information in a header field. More generally, I > don't believe DKIM itself cares about the size of the key. All of our > advice absolutely does, and rightly so. > > Do we have any other crypto-related protocols where the protocol itself > legislates the appropriate key parameters for the encoding, decoding, > signing or verifying? Section 6 of RFC3207 (STARTTLS) explains explicitly > that it's a local matter and out of scope, for example. I scanned > RFC4033-4035 (DNSSEC) and didn't see any restrictions or advice about key > size selection at all. I always go cross-eyed when I try to read the TLS > RFCs so I'll stop there for now. ;-) > > > The size of the key doesn't affect interoperability, but rather the > > > > > receiver's choice to accept the signature as valid when it's based on a > > > weak key. > > > > To me that's equivalent to saying choice of crypto algorithm doesn't > > affect > > interoperability since it only affects the receivers choice to accept the > > signature as valid. > > There's also nothing wrong with a receiver deciding it doesn't like > signatures that use relaxed canonicalization, SHA1, or decline to sign the > Subject header field. The algorithm itself worked fine -- that's > interoperability -- but the receiver doesn't like one of the parameters the > signer used and thereby makes a local policy decision. > > You have to set a floor below which it's not reasonable to accept > > > signatures as > > valid. Since receivers have no way to vet sender's key rotation policies, > > taking an out like RFC 6376 and its predecessors do and say that keys > > smaller > > that 1024 bits are OK for keys that aren't long lived is not tenable. > > That > > and since DKIM was first deployed, at least for 512 bit keys, the not long > > lived required to meet even the modest security goals of DKIM are > > substantially shorter than the amount of time typically needed to ensure > > that > > mail deliveries are completed (some fraction of a day at longest). > > > > Key lengths less than 1024 need to be killed dead. > > I don't argue with any of that, except to say again that I'm not convinced > DKIM, the protocol, has to suddenly break for small keys. I absolutely > agree with a BCP statement of some kind, and I also agree in retrospect > that the not-long-lived key advice in RFC6376 is probably not helpful. > (You could in theory observe the timestamp of when you first saw a key and > then watch how long it gets used, but that puts an unreasonable burden on > receivers.) It's been known for years (see the original reference I provided) the 512 bit keys were trivially spoofable. All open source implementations I'm aware of have not accepted keys < 1024 bits for several years. The only sudden is in an abstract sense if one hadn't been paying any attention at all to operational reality regarding DKIM. I don't view this as a functional change to the operational protocol as much as making the IETF paperwork match that reality (which I think is important). We're already several years late writing this, so I don't think any alleged suddenness should be considered at all. If you take out the poorly considered aspect of giving an exception to the existing MUSTard about short lived keys (which is never defined), 1024 bits has always been the limit, it's just that people often ignored it. Rapid key rotation is not something that's generally done. > Do we also want to issue a BCP more generally that tries to compel all > implementations of TLS or anything doing signatures to flatly decline to > operate if someone tries to use a sub-1024-bit key size? I think the considerations for other protocols might be different. I'd rather focus on DKIM for the moment. Once you get to all, it's no longer a quick, easy update. > > BTW (for reference), I'm prompted to do the work to make this change by a > > recent change in opendkim [1] that removed the ability to mark messages > > with small keys
Re: [ietf-dkim] DKIM Key Size Constraints
On Tuesday, May 12, 2015 03:35:37 PM Murray S. Kucherawy wrote: > On Tue, May 12, 2015 at 8:31 AM, Martijn Grooten < > > martijn.groo...@virusbtn.com> wrote: > > > Why remove 512 support from the verification side? Does this mean the > > > verifier will take valid 512 signature and make it invalid, no signature > > > message? Is there a correlation out there that 512 bits signers are > > > more > > > prune to be Bad Guys? Spammers? > > > > The problem here is that 512-bit keys can be trivially broken: it takes > > less than 8 hours and about 100 USD to do so[1]. So there is no way to be > > certain that the signer of the message is the same organisation that > > published the (512-bit) DKIM key, even if that organisation only were to > > send email that everyone would want to receive. > > > > You are right to point out that the RFC says that "[t]he security goals of > > this specification are modest", which indeed they are, but I think 100 USD > > is well within the means of the kind of adversary DKIM is trying to > > protect > > against. The story of Google's 512-bit key that Scott already pointed > > to[2] > > gives at least some anecdotal evidence about why this matters in practice. > > Is it appropriate to change the protocol document for this? Isn't it > really more of a BCP? I think when key size got put in the protocol, then it's a protocol update to change it. > The size of the key doesn't affect interoperability, but rather the > receiver's choice to accept the signature as valid when it's based on a > weak key. To me that's equivalent to saying choice of crypto algorithm doesn't affect interoperability since it only affects the receivers choice to accept the signature as valid. I think that of course it's an interoperability issue. There has to be a meeting of the minds on key signing and key verification in order for DKIM to be interoperable. > I'm not arguing that it's a bad idea to discourage this practice, but > rather ruminating about whether this is the right way to do it. > > Then again, RFC6376 doesn't expressly say that keys smaller than 512 have > to be accepted either. Hmmm. You have to set a floor below which it's not reasonable to accept signatures as valid. Since receivers have no way to vet sender's key rotation policies, taking an out like RFC 6376 and its predecessors do and say that keys smaller that 1024 bits are OK for keys that aren't long lived is not tenable. That and since DKIM was first deployed, at least for 512 bit keys, the not long lived required to meet even the modest security goals of DKIM are substantially shorter than the amount of time typically needed to ensure that mail deliveries are completed (some fraction of a day at longest). Key lengths less than 1024 need to be killed dead. BTW (for reference), I'm prompted to do the work to make this change by a recent change in opendkim [1] that removed the ability to mark messages with small keys as DKIM fail. Scott K [1] ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Key Size Constraints
On May 12, 2015 7:28:25 AM EDT, Hector Santos wrote: >-1 > >Please stop! No more DKIM code changes ok? The IETF just made it a >STD. > >Maybe we should remove the STD status first, move it back to proposed >standard or experimental if this and other changes are coming. > >If signers want 1024 bits, then can do so ready. True, but irrelevant. The change that's needed is to remove the requirement for receivers to verify signatures with keys to small to be secure. Any cryptographic protocol will need periodic adjustment to remain secure. I'm surprised you are surprised. Presumably your implementation already checks for the current minimum key size of 512 bits. If changing that constant to 1024 is too hard, I think you're doing it wrong. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Key Size Constraints
On Monday, May 11, 2015 07:23:58 PM John Levine wrote: > >I propose a short draft that updates 6376 to say MUST use at least 1024 > >bits and setting that as the minimum size verifiers must be able to > >validate. I'm volunteering to write it if people agree it's appropriate. > > That seems fine. This makes the usable range fairly small, since keys > longer than 1536 run into the 512 byte DNS packet limit which shouldn't > still be an issue 16 years after EDNS0 was introduced, but is anyway. I > don't see that as a problem, but it's likely worth mentioning. The last time I saw an interoperability problem related to EDNS0 was this month, so while I generally agree, the impact is still non-zero (it may be time to decide we don't care), but either way, I'm not proposing we do anything other than raise the floor for this update in order to avoid having to decide about things like this. > With regards to Doug's point, yeah, we could have other ways to > distribute keys like, say, a new DNS record type that has a binary > key. For some reason, that gives me a bad feeling. Even if it was a good idea, it wouldn't be a quick update. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Key Size Constraints
On Monday, May 11, 2015 12:04:19 PM Douglas Otis wrote: > On 5/11/15 10:06 AM, Scott Kitterman wrote: > > RFC 6376 (which I think is the latest) includes: > >> 3.3.3. Key Sizes > >> > >>Selecting appropriate key sizes is a trade-off between cost, > >>performance, and risk. Since short RSA keys more easily succumb to > >>off-line attacks, Signers MUST use RSA keys of at least 1024 bits for > >>long-lived keys. Verifiers MUST be able to validate signatures with > >>keys ranging from 512 bits to 2048 bits, and they MAY be able to > >>validate signatures with larger keys. Verifier policies may use the > >>length of the signing key as one metric for determining whether a > >>signature is acceptable. > > > > Since receivers have no good way of knowing what keys are long-lived, > > there's no way on the receiver side to reliably determine if a key > > shorter than 1024 bits is being appropriately used or not. I think it's > > time to kill keys shorter than 1024 bits dead. It's not like the risks > > associated with them are new [1]. > > > > I propose a short draft that updates 6376 to say MUST use at least 1024 > > bits and setting that as the minimum size verifiers must be able to > > validate. I'm volunteering to write it if people agree it's appropriate. > > > > Scott K > > > > > > [1] http://www.wired.com/2012/10/dkim-vulnerability-widespread/ > > Dear Scott, > > Signatures normally offer options not easily supported by > DKIM. One being use of a binary keys, rather than base64. > Indeed shorter keys were a mistake. What other mistakes > should be corrected? I can name a few. I'm not particularly interested in a comprehensive update to DKIM. Time has passed. Moore's Law has operated. It's time to change the minimum key size (past time, IMO). I'd much rather get that done as I don't think it will be controversial rather than get into a broader debate that might get bogged down. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] DKIM Key Size Constraints
RFC 6376 (which I think is the latest) includes: > 3.3.3. Key Sizes > >Selecting appropriate key sizes is a trade-off between cost, >performance, and risk. Since short RSA keys more easily succumb to >off-line attacks, Signers MUST use RSA keys of at least 1024 bits for >long-lived keys. Verifiers MUST be able to validate signatures with >keys ranging from 512 bits to 2048 bits, and they MAY be able to >validate signatures with larger keys. Verifier policies may use the >length of the signing key as one metric for determining whether a >signature is acceptable. Since receivers have no good way of knowing what keys are long-lived, there's no way on the receiver side to reliably determine if a key shorter than 1024 bits is being appropriately used or not. I think it's time to kill keys shorter than 1024 bits dead. It's not like the risks associated with them are new [1]. I propose a short draft that updates 6376 to say MUST use at least 1024 bits and setting that as the minimum size verifiers must be able to validate. I'm volunteering to write it if people agree it's appropriate. Scott K [1] http://www.wired.com/2012/10/dkim-vulnerability-widespread/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Is DMARC the right place for SMTP-TLS policy and reporting?
On Tuesday, June 19, 2012 07:58:44 AM Chris Lamont Mankowski wrote: > Does it makes sense for the DMARC policy to not only set policy and report > on DKIM and SPF but also how the client authenticates via TLS? dmarc-disc...@dmarc.org is the right place for that question. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Doublefrom language should be in ADSP, not core
On Saturday, July 09, 2011 07:19:17 PM Michael Deutschmann wrote: > One additional thought on the whole double-From: argument -- if RFC > language on the issue is justified at all, it really belongs in the > ADSP RFC, not a core DKIM one. > > A double-From: doesn't even rise to the level of theoretical threat > except when dealing with ADSP (or a successor). The abstract for RFC 4871 starts ... "DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transfer Agents (MTAs) or Mail User Agents (MUAs). The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus protecting message signer identity and the integrity of the messages they convey ..." Verification of source and contents is fundamental to the DKIM requirements. If it's not, the assertion of responsibility is meaningless (maintaining the assertion of responsiblity even though the message has been modified in a meaningful way is nonsense). I wish we could have removed l= for this reason. I think we should make it clear that singleton header fields like From (and Subject and Date) can be added without breaking signatures unless one is careful as a signer and/or a verifier. This is related to a core DKIM design principle and doesn't need ADSP (or other non-standard measures) for it to be something we should care about. I haven't had time to carefully parse all the proposed language, so I'm not going to comment on the specifics of the current proposals, but I think it's just flat out wrong to claim that payload integrity is unrelated to DKIM. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
On Thursday, July 07, 2011 12:47:52 PM Murray S. Kucherawy wrote: > > -Original Message- > > From: ietf-dkim-boun...@mipassoc.org > > [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman > > Sent: Thursday, July 07, 2011 9:44 AM > > To: ietf-dkim@mipassoc.org > > Subject: Re: [ietf-dkim] Final update to 4871bis for working group review > > > > I agree it's not exactly what is specified in the protocol, but this is > > an implementation design issue. I think it's safe. If the DKIM > > protocol says I can't do something like this, then I think we have a > > problem with the current "describe it and let implementors deal with it" > > plan. > > It's definitely not proscribed by DKIM. All I meant was that you're > preventing a signer from deliberately accepting responsibility for a > message thus modified (by doing only one "from" in "h="), knowing the > risks of doing so. Yes. I can live with that. Thanks, Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
I don't think so, but I'll definitely test it. If it does, then we won't do it that way. Scott K On Thursday, July 07, 2011 12:51:06 PM McDowell, Brett wrote: > Will your "assume one more From than listed in h=" lead to failed > verifications on messages that actually follow the advice in the RFC to > list duplicate headers in their h= values? > > > -Original Message- > > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > > boun...@mipassoc.org] On Behalf Of Scott Kitterman > > Sent: Thursday, July 07, 2011 12:44 PM > > To: ietf-dkim@mipassoc.org > > Subject: Re: [ietf-dkim] Final update to 4871bis for working group review > > > > On Thursday, July 07, 2011 12:22:20 PM Murray S. Kucherawy wrote: > > > > -Original Message- > > > > From: ietf-dkim-boun...@mipassoc.org > > > > [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman > > > > Sent: Thursday, July 07, 2011 6:32 AM > > > > To: ietf-dkim@mipassoc.org > > > > Subject: Re: [ietf-dkim] Final update to 4871bis for working group > > > > review > > > > > > > > I'm working with someone on an implementation and I think we're > > > > going to assume one more From than listed in h= when verifying to > > > > ensure nothing has been added. > > > > > > This intentionally causes the verifier to assume what the signer > > > really meant when it signed a message using a single From: field. > > > That may look safe but it isn't what DKIM actually says. > > > > > > We might do this for libopendkim somewhere down the line, but it would > > > default "off". > > > > > > In any case, interesting idea. > > > > It only assumes that the signer signed all the From: fields present in > > the message (note: I said one more than in h=, not two). I think it's > > fair to say that if someone is sending messages with multiple From: > > fields (or Date:/Subject:) and trying to sign something less than all of > > them they are fairly deep into unsupported territory and shouldn't find > > any result surprising. > > > > I agree it's not exactly what is specified in the protocol, but this is > > an implementation design issue. I think it's safe. If the DKIM > > protocol says I can't do something like this, then I think we have a > > problem with the current "describe it and let implementors deal with it" > > plan. > > > > Scott K > > ___ > > NOTE WELL: This list operates according to > > http://mipassoc.org/dkim/ietf-list- rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
On Thursday, July 07, 2011 12:22:20 PM Murray S. Kucherawy wrote: > > -Original Message- > > From: ietf-dkim-boun...@mipassoc.org > > [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman > > Sent: Thursday, July 07, 2011 6:32 AM > > To: ietf-dkim@mipassoc.org > > Subject: Re: [ietf-dkim] Final update to 4871bis for working group review > > > > I'm working with someone on an implementation and I think we're going to > > assume one more From than listed in h= when verifying to ensure nothing > > has been added. > > This intentionally causes the verifier to assume what the signer really > meant when it signed a message using a single From: field. That may look > safe but it isn't what DKIM actually says. > > We might do this for libopendkim somewhere down the line, but it would > default "off". > > In any case, interesting idea. It only assumes that the signer signed all the From: fields present in the message (note: I said one more than in h=, not two). I think it's fair to say that if someone is sending messages with multiple From: fields (or Date:/Subject:) and trying to sign something less than all of them they are fairly deep into unsupported territory and shouldn't find any result surprising. I agree it's not exactly what is specified in the protocol, but this is an implementation design issue. I think it's safe. If the DKIM protocol says I can't do something like this, then I think we have a problem with the current "describe it and let implementors deal with it" plan. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
On Thursday, July 07, 2011 01:59:17 AM Michael Deutschmann wrote: ... > In real life, however, if you don't have the power to demand that a > recipient mail admin block incoming double-From: messages, then you don't > have the power to demand that they deploy DKIM at all. ... I think you are confusing protocol with implementation. There's nothing the prevents receivers from ensuring messages that have been modified after signing with an additional From fail verification. I'm working with someone on an implementation and I think we're going to assume one more From than listed in h= when verifying to ensure nothing has been added. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and signatures again
On Thursday, May 26, 2011 11:00:04 PM Murray S. Kucherawy wrote: > > -Original Message- > > From: ietf-dkim-boun...@mipassoc.org > > [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman > > Sent: Thursday, May 26, 2011 5:36 PM > > To: ietf-dkim@mipassoc.org > > Subject: Re: [ietf-dkim] MLMs and signatures again > > > > My experience is it varies a lot by domain. Some domains are phishing > > targets and some aren't. If it's not a phishing target DKIM doesn't > > matter much either way. If it is, then if they can manage to sign all > > their outbound mail signed/not signed gets to be useful. So I don't > > think looking at global status is a very useful basis for deciding the > > question. > > So you'd rather I run this on some signing domains that aren't obvious > phish targets? I can do that. If you have a few you think might be > interesting, send me the names; if not, I can see if I can come up with > some just based on the numbers. > > And I can constrain it to a specific reporting site (e.g., my own) instead > of all reporters if you think that gives a more interesting view. I was thinking the opposite. Look at phish targets that sign pretty reliably. I'll contact you offlist with some ideas on which. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and signatures again
On Thursday, May 26, 2011 07:40:17 PM Murray S. Kucherawy wrote: > > -Original Message- > > From: ietf-dkim-boun...@mipassoc.org > > [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of MH Michael Hammer > > (5304) Sent: Thursday, May 26, 2011 4:15 PM > > To: Scott Kitterman; ietf-dkim@mipassoc.org > > Subject: Re: [ietf-dkim] MLMs and signatures again > > > > The other piece of the equation is how often do I see abusive mail > > purporting to be from this domain with no signature while mail from this > > domain that is normally signed has no significant problems. > > I posted the results of some research on that very question earlier this > week: > > http://mipassoc.org/pipermail/ietf-dkim/2011q2/016656.html My experience is it varies a lot by domain. Some domains are phishing targets and some aren't. If it's not a phishing target DKIM doesn't matter much either way. If it is, then if they can manage to sign all their outbound mail signed/not signed gets to be useful. So I don't think looking at global status is a very useful basis for deciding the question. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and signatures again
On Thursday, May 26, 2011 07:15:25 PM MH Michael Hammer (5304) wrote: > > -Original Message- > > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > > boun...@mipassoc.org] On Behalf Of Scott Kitterman > > Sent: Thursday, May 26, 2011 7:07 PM > > To: ietf-dkim@mipassoc.org > > Subject: Re: [ietf-dkim] MLMs and signatures again > > > > On Thursday, May 26, 2011 03:21:19 PM Steve Atkins wrote: > > > If the reputation of the MLM is poor enough that mail from it is not > > > being > > > delivered, trumping that with an authors reputation may get > > > individual > > > emails delivered - but not threads, so it doesn't really improve the > > > value > > > provided to the recipient (it probably decreases it - a mailing list > > > that > > > delivers one in ten posts to my inbox is less useful than one that > > > delivers none at all). > > > > I think this has it rather backwards. If mail From (body From) a > > certain > > domain arrives 999 time with a valid DKIM signature and on the 1,000th > > time it > > arrives with either no signature or a broken one, then that's a > > negative > > anomaly in the mail stream that receivers are quite likely to take > > notice of. > > While ADSP is the public whipping boy for this, there are plenty of > > private > > efforts based on doing exactly this. > > > > The question isn't do I trust the ML or not. For domains with a non- > > trivial > > number of users the overall mail system will have no idea about what > > ML should > > be trusted or not. The question is how harshly do I treat this > > message based > > on the lack of a good signature. > > > > Scott K > > The other piece of the equation is how often do I see abusive mail > purporting to be from this domain with no signature while mail from this > domain that is normally signed has no significant problems. True. That could be a factor as well. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and signatures again
On Thursday, May 26, 2011 03:21:19 PM Steve Atkins wrote: > If the reputation of the MLM is poor enough that mail from it is not being > delivered, trumping that with an authors reputation may get individual > emails delivered - but not threads, so it doesn't really improve the value > provided to the recipient (it probably decreases it - a mailing list that > delivers one in ten posts to my inbox is less useful than one that > delivers none at all). I think this has it rather backwards. If mail From (body From) a certain domain arrives 999 time with a valid DKIM signature and on the 1,000th time it arrives with either no signature or a broken one, then that's a negative anomaly in the mail stream that receivers are quite likely to take notice of. While ADSP is the public whipping boy for this, there are plenty of private efforts based on doing exactly this. The question isn't do I trust the ML or not. For domains with a non-trivial number of users the overall mail system will have no idea about what ML should be trusted or not. The question is how harshly do I treat this message based on the lack of a good signature. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
On Wednesday, May 25, 2011 02:04:45 PM Hector Santos wrote: ... > When I remove the domains I know, the rest is pretty much spam. ... Isn't that pretty generally true, DKIM or no DKIM. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
On Monday, May 23, 2011 12:35:02 PM John R. Levine wrote: > > In the real world signature reliability matters. If a domain signs mail > > as a rule then an absent or broken signature will be treated as > > suspicious. > > I hope you're wrong, since that violates an explicit SHOULD in RFC 4871, > and in my experience, most broken signatures are due to innocent > modification in transit, not malice. Which one is that? AFAIK treating a broken signature the same as no signature is what the RFC wants me to do. > Do you have numbers to show that broken signatures indicate that messages > are malicious, or spam, or otherwise worse than otherwise? None that I can share unfortunately. IME no signature is more suspicious than a broken one (as you suggest, I think most breakage is innocent), but putting broken and no signature into the same bucket is the most sensible and RFC compliant way to approach it. > For that matter, since we're not talking about ADSP, what do you mean by > an absent signature? Do you track which domains sign what mail? How do > you tell what signature you're expecting? From line domain? Sender? > Message ID? Something in the Received lines? The specific cases (which are non-ADSP) that I'm aware of use the body From as a key. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
>Ian Eiloart wrote: > >On 23 May 2011, at 15:19, Hector Santos wrote: > Ian Eiloart wrote: >> >On 20 May 2011, at 05:24, Hector Santos wrote: >> >>> In this case, if >this is enforced with a MUST, for a system that is >>> not 8BITMIME >ready but is adding DKIM signing support, to remain >>> compliant it is >far more feasible to add a rule to a DKIM signing >>> component: >>> If mail is 8bit then SKIP signing. >> >> But why skip? Usually the >message won't be downgraded. And even if they >> are, usually a broken >signature will cause no harm. > > Thats the problem - define "usually" >and also define "no harm." > Well, harm will only be done when someone >incorrectly punishes a broken signature. They should not do that, so >the damage is actually done by the recipient, not by the downgrading. In the real world signature reliability matters. If a domain signs mail as a rule then an absent or broken signature will be treated as suspicious. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
On Friday, May 20, 2011 01:18:39 AM Murray S. Kucherawy wrote: > > -Original Message- > > From: John Levine [mailto:jo...@iecc.com] > > Sent: Thursday, May 19, 2011 7:20 PM > > To: ietf-dkim@mipassoc.org > > Cc: Murray S. Kucherawy > > Subject: Re: [ietf-dkim] 8bit downgrades > > > > I think Pete's analysis is correct, but my advice would be to take > > it out altogether. We don't have any great insight into the warts > > of what paths are likely to downcode a message and what paths aren't, > > so I would prefer not to purport to offer advice about it. > > Actually, I kinda prefer to leave it in. It seems to me "assume a > downgrade will happen unless you're certain it won't, and plan > accordingly" is good advice without having to know the details of a > transport path. And the paragraph gives discussion of the how and why. +1. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
On Thursday, May 19, 2011 02:16:47 PM Wietse Venema wrote: > We could pretend that the future is 8-bit clean, and hope the > problem will go away eventually. I have a vague recollection that this is the reason it's SHOULD vice MUST. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Protocol layering / Software vs. Protocol
On Wednesday, May 04, 2011 01:01:57 PM Dave CROCKER wrote: > In terms of working group process, one line of criticism demands > re-opening (and, apparently, reversing) the work of the Update (RFC > 5672). I haven't seen any working group consensus to do this nor any > industry feedback indicating this is necessary. Consequently, attempts to > pursue the content of that work is entirely out of scope for the current > working group effort. If you're looking for consensus, count me in. I don't think it was progress. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue: Operations Note in 6.4 redundant and should be removed
On Friday, April 29, 2011 09:22:15 AM Hector Santos wrote: > I think the rev8 version of section 6.5 is much better, but I have a > change proposal with the background reasoning listed below it: > ... I've had no time recently, so I've been attempting to avoid looking at last call messages since I didn't have time to follow it closely. In this case I failed Looking at 6.5, and then looking back at 6.4 (Determine the Header Fields to Sign), it seems to me that the "INFORMATIVE OPERATIONS NOTE" in 6.4 attempts to describe the considerations that are normatively described in 6.5. It's redundant and ought to be deleted. Given what's in 6.5 now, it's just a potential source of confusion. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP stats
On Wednesday, April 20, 2011 08:01:21 PM John R. Levine wrote: > > A much better test would be compile a list of DKIM signing > > domains, and do the ADSP query on them. > > That's what I did. The only ADSP I see this year is Paypal. That's a success story of a sort. We know that ADSP is only potentially useful in a narrow set of circumstances. Data that indicates the protocol isn't being widely deployed for domains for which is not suited is good news. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)
On Saturday, April 02, 2011 02:49:49 PM Michael Thomas wrote: > 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. +1. I don't particularly agree with the idea that the work of the working group is 'done', but it does seem that we'd be better off if we stopped 'improving' things sooner rather than later. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] FW: Getting resolution on the "double header" issue
On Wednesday, February 16, 2011 03:52:24 pm Murray S. Kucherawy wrote: > This is the last text that I circulated on the bogus header matter, in > reply to Barry's proposed path to resolution. The group was pretty > exhausted from debate at that point so there was little response. > > > -Original Message- > > From: ietf-dkim-boun...@mipassoc.org > > [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Barry Leiba Sent: > > Monday, November 08, 2010 1:20 AM > > To: IETF DKIM WG > > Subject: [ietf-dkim] Getting resolution on the "double header" issue > > > > Proposal: > > > > 1. The DKIM spec is responsible for describing the problem in terms of > > how it relates to signed and unsigned versions of the fields. That's > > the stuff in 8.14. > > Concur. I worked through an 8.14 proposal a couple of weeks ago using > input from the list. The last text I have was: > > 8.14 Malformed Inputs > > DKIM allows additional header fields to be added to a signed message > without breaking the signature. This tolerance can be abused, e.g. in a > replay attack, by adding additional instances of header fields that are > displayed to the end user or used as filtering input, such as From or > Subject, to an already signed message in a way that doesn't break the > signature. > > The resulting message violates section 3.6 of [MAIL]. The way such input > will be handled and displayed by an MUA is unpredictable, but in some > cases it will display the newly added header fields rather than those that > are part of the originally signed message alongside some "valid DKIM > signature" annotation. This might allow an attacker to replay a previously > sent, signed message with a different Subject, From or To field. > > Because of this, DKIM implementers are strongly advised to reject or treat > as suspicious any message that has multiple copies of header fields that > are disallowed by section 3.6 of [MAIL], particularly those that are > typically displayed to end users (From, To, Cc, Subject). A signing > module could return an error rather than generate a signature; a > verifying module might return a syntax error code or arrange not to return > a positive result even if the signature technically validates. > > Senders concerned that their messages might be particularly vulnerable to > this sort of attack and who do not wish to rely on receiver filtering of > invalid messages can ensure that adding additional header fields will > break the DKIM signature by including two copies of the header fields > about which they are concerned in the signature (e.g. "h= ... > from:from:to:to:subject:subject ...). See Sections 3.5 and 5.4 for further > discussion of this mechanism. > > Specific validity rules for all known header fields can be gleaned from the > IANA "Permanent Header Field Registry" and the reference documents it > identifies. > > > 2. The DKIM spec should probably say that signers need to sign valid > > messages, and, therefore, SHOULD NOT sign things like this. Text > > along the line of this might work well: > > "Signers SHOULD take reasonable steps to ensure > > that the messages they're signing are valid according to [RFC 5322, > > etc]." Leaving the definition of "reasonable" out allows flexibility. > > It may be waffly, but I like the approach in this case. > > Works for me. How about: > > 3.10. Input Requirements > > DKIM's design is predicated on valid input. Therefore, signers and > verifiers SHOULD take reasonable steps to ensure that the messages they > are processing are valid according to [MAIL], [MIME], and any other > relevant message format standards. See Section 8.14 for additional > discussion and references. > > > 3. It'd be reasonable for the DKIM spec to remind verifiers that > > signers aren't supposed to sign stuff like this, so they might > > consider that when deciding what to do with it after verification. > > It'd be reasonable to remind them of this particular case. But > > I think that all ought to be informative text. > > Yup; the above two amendments cover both cases. +1. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re-thinking the organization of the DKIM spec
On Thursday, January 13, 2011 02:48:14 pm Barry Leiba wrote: > ... And at some point between now and then, please make it clear > where you stand on the question, so we can fairly judge consensus. -1 on splitting now. For two primary reasons: 1. While the proposed split doesn't affect the maturity of DKIM, the maturity of having got the split correct is a different matter. Until there are multiple users of the split out DOSETA functionality, I think it's premature for it to be advancing along the standards track. 2. While the intent of clearly to maintain DKIM as it is through the split, without a stable set of specifications to compare the split documents to (and implementation experience based on the split documents) it's difficult to really know if any inadvertent incompatibilities have been introduced. My preferred approach would to be to complete the current charter work item based on finishing the unitary specification and then work on the split as a new work item (after rechartering). I don't think that precludes interested parties from continuing work on DOSETA in the mean time. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Japan has been set up
"John R. Levine" wrote: >We really need a FAQ for this group. > >>> Simply publishing an ADSP record does not change this fact. ADSP >can >>> perhaps be used productively for specific signers and verifiers, but >it >>> does not work for all legitimate scenarios. >>> >> What does work for all legitimate scenarios? > >Short answer: nothing. > Right. It also doesn't wax my car, which is equally relevant. ADSP certainly isn't ideal, but (unlike the rest of your message) saying something "does not work for all legitimate scenarios" is not a useful contribution to the discussion. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Japan has been set up
On Monday, November 22, 2010 01:37:13 pm Dave CROCKER wrote: > On 11/21/2010 6:43 PM, Tsuneki Ohnishi wrote: > > But there is a small problem. It is rather polical. > > We have a telecommunication law that allows ISPs to discard > > forged email, but our Ministry so far does not acknowledge > > that failure of DKIM verification immediately equals to > > forgery, because there could be other reasons to fail. > > There are technical and operational reasons that can cause legitimate mail > that was originally signed with a legitimate DKIM signature, to fail to > verify. > > The fact that a signer signs all their mail does not mean that all their > mail will arrive with a valid signature. > > Simply publishing an ADSP record does not change this fact. ADSP can > perhaps be used productively for specific signers and verifiers, but it > does not work for all legitimate scenarios. > What does work for all legitimate scenarios? Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Getting resolution on the "double header" issue
On Monday, November 08, 2010 04:20:19 am Barry Leiba wrote: > As participant: > > Here's how I see the situation. It's purely as a participant, and has > no chair weight. I think it does represent a compromise position that > should work. > > Problem description: > An "attack" has been described that can be mounted by adding a second > "from", "subject", or possible other header field that is only > supposed to appear once. This situation might fool a UA, filtering > software, or some other software into considering the added, unsigned > field as the "real" one. > > Who is responsible for dealing with this situation? If the DKIM spec > is at least partially responsible, to what extent, and what should it > say? > > > Proposal: > > 1. The DKIM spec is responsible for describing the problem in terms of > how it relates to signed and unsigned versions of the fields. That's > the stuff in 8.14. > > 2. The DKIM spec should probably say that signers need to sign valid > messages, and, therefore, SHOULD NOT sign things like this. Text > along the line of this might work well: > "Signers SHOULD take reasonable steps to ensure > that the messages they're signing are valid according to [RFC 5322, > etc]." Leaving the definition of "reasonable" out allows flexibility. It > may be waffly, but I like the approach in this case. > > 3. It'd be reasonable for the DKIM spec to remind verifiers that > signers aren't supposed to sign stuff like this, so they might > consider that when deciding what to do with it after verification. > It'd be reasonable to remind them of this particular case. But > I think that all ought to be informative text. > > 4. We should agree to this or some variant of it, and then move on. > This is not meant to satisfy everyone. In fact, it isn't what I'd prefer, > if I had my full choice. But it takes care of the problem in a way > that I think is sufficient, and allows us to resolve the issue. I think this oversimplifies the issue from a DKIM perspective. If this were added, should signatures that sign a second (non-existant) from header specifically to ensure header addition breaks the signature verification be verified if in fact the message hasn't been modified? Rather than fall back purely on 5322, I'd prefer to see something in security considerations that says if the count of a particular header field that is supposed to be limited (e.g. From and Subject) present in a message exceeds the number of signed fields, then the signature shouldn't be verified. Additionally, signing a message with (for example) two From: fields is not a problem in the context of this issue, so the advice not to sign such messages isn't particularly related. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Commments and clarifications to 4871bis-02
On Friday, October 22, 2010 09:38:47 pm John Levine wrote: > This is one of those places where I don't know how much we can change > without the IESG deciding to recycle. I think we should decide what's best for the long term health of the protocol and then let the IESG worry about recycling or not. Getting it right is more important than advancing up the standards ladder. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] double header reality check
"Michael Thomas" wrote: >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 important to distinguish between format errors that are likely to lead to misleading rendering in existing MUAs, and the much larger class that may produce nonsense but won't produce lies. >>> >>> I think we're close to converging here. >>> >>> I totally agree that that's an important distinction to make, document, >>> highlight and shout from the rooftops. But... Does it *have* to use >>> RFC2119 normative language? >>> >>> Here's maybe a better way to frame the question: Should we empower >>> ourselves to label a DKIM implementation that doesn't do format enforcement >>> as (a) non-compliant, or (b) low-security/low-quality? >>> >>> I'm pushing for (b), while someone who insists the text be normative is >>> pushing for (a). >> >> I'm pushing for neither. It's not the DKIM verifiers responsibility to >> enforce that. >> >> I do think that an informative note observing "Here are a couple of issues >> that might theoretically be exacerbated by a DKIM-using world; you might >> consider checking for these problems somewhere in your mail handling path, >> if you aren't already" would be reasonable. >> >> "Somewhere in your mail handling path" might be in the same binary as the >> DKIM validator, or it may not - and implying that an implementation that >> chooses to handle two entirely separate validation issues in two separate >> modules is "non-compliant" or "low-security" or "low-quality" doesn't seem >> helpful. > >I think that Steve threads this just about right. No need to cast aspersions, >or kick them off the "compliant" island. Just lay out the security >consideration >and let people deal with this however makes sense. I'm still puzzled how this >tempest entered this tea pot. > Um. That's not how I read what he wrote. He specifically said no to security considerations and I understand that's what you're in favor of. Confusedly yours, Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] sophistry is bad, was Data integrity claims
On Monday, October 18, 2010 02:19:06 pm Murray S. Kucherawy wrote: > > -Original Message- > > From: ietf-dkim-boun...@mipassoc.org > > [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman > > Sent: Saturday, October 16, 2010 11:56 AM > > To: ietf-dkim@mipassoc.org > > Subject: Re: [ietf-dkim] sophistry is bad, was Data integrity claims > > > > > The current DKIM spec does not answer these questions and easily > > > permits protecting very little of the message. Almost certainly too > > > little to ensure the protection you assert. > > > > One can also point a gun at ones own head. That doesn't make a gun a > > suicide device of no value for anything else. The spec does permit > > people to do silly things, but so what. > > Doesn't this statement advocate for informative advice rather than > normative requirements? I'm OK with that, but the informative advice needs to be in security considerations, IMO. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] sophistry is bad, was Data integrity claims
On Saturday, October 16, 2010 10:50:25 am Dave CROCKER wrote: > On 10/16/2010 10:26 AM, John R. Levine wrote: > >> Yes, it ties an identifier to a bag of bits, and yes it specifies what > >> those bits are, but it really does deal only with those bits and not > >> (necessarily) the entire message. > > > > Technically. you are correct. Semantically, that's silly. > > > > We went through backflips trying to figure out how to design the > > signatures so that the message modifications they allowed would preserve > > the same message, for an ill defined but I think well understood version > > of the same. > > Yes that was the goal. No that was not the result. -1. I think we did that just fine. > Which header fields are essential to protect? How much of the message body > is essential to protect? This is completely orthogonal to the question. As long as a receiver can reliably determine what is protected and what is not, then the protection goal is achieved. It does not require that there is agreement on what that should be. > The current DKIM spec does not answer these questions and easily permits > protecting very little of the message. Almost certainly too little to > ensure the protection you assert. One can also point a gun at ones own head. That doesn't make a gun a suicide device of no value for anything else. The spec does permit people to do silly things, but so what. > That's an example of what I mean when I says that there are assumptions > about DKIM that go beyond what it (always) delivers. Saying it's possible to use DKIM in ways that doesn't support this is not the same as saying DKIM doesn't support it. It's possible to operate any modern MTA as an open relay, but it doesn't follow that all MTAs are open relays or that they fail to protect against open relaying. > I guess I should thank you for demonstrating my point. If you had one that relevant to the discussion, it's not at all clear to me what it was or how it was demonstrated. > > While it's always been possible to sign messages in ways > > that allow gross changes, e.g. don't sign the subject or MIME headers, > > set l=0, if you sign a message using a normal set of options, the idea > > was always that the message the recipient saw would be the one you > > signed. Throwing up our hands at the double header trick is, one might > > say, ahistoric. Claiming it's an MUA problem is simply wrong. > > 1. Your first sentence concedes my basic point > > 2. There is no commonly-agreed upon and documented concept of "normal set > of options" that I'm aware of. What is normal for you might or might not > be normal for the next person configuring DKIM. True, but irrelevant. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
On Friday, October 15, 2010 07:50:36 pm Murray S. Kucherawy wrote: > > -Original Message- > > From: ietf-dkim-boun...@mipassoc.org > > [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Douglas Otis Sent: > > Friday, October 15, 2010 2:30 PM > > To: ietf-dkim@mipassoc.org > > Subject: Re: [ietf-dkim] detecting header mutations after signing > > > > Citing a layer violation makes little sense. With DKIM, the message > > body does not stand on its own. DKIM binds elements related to the > > RFC5322 header fields with the message body, for the purpose of > > extending favorable message handling, such as white-listing. Since > > DKIM has this property, citing layer violations lacks any basis. > > I thought the "What DKIM does" thing was a long-dead horse, as we'd long > ago reached consensus that what DKIM does is provide a stable identifier > on the message, and nothing more. That makes this assertion inapposite. Does it? If the identifier is bound to the hashed information, I think it makes complete sense to believe one can make something of that content and it's relation to the identifier. It provides a stable identifier, but that identifier is inextricably tied to the signed content. > I think perhaps now would be a good time to make that explicit, since a lot of people (including some in here) are continuing to infer that DKIM should be used to "protect" the body. So I propose this be added to 4871bis: > > > 1.4 Data Integrity > > > > > > A DKIM signature associates the d= name with the computed hash of > > > some or all of the message (see Section 3.7) in order to prevent the > > > re-use of the signature with different messages. Verifying the > > > signature asserts that the hashed content has not changed since it > > > was signed, and asserts nothing else about "protecting" the end-to-end > > > integrity of the message. > > I apologize in advance if that causes yet another traffic maelstrom, but > it's something we need to settle. And since the discontinuous expectation > of DKIM exists outside the working group as well as inside it, that means > consensus needs to be codified. Your proposed wording sounds a lot to me like what I think of as "protecting" the end-to-end content. I feel there's a lot of talking past each other here. If we were doing what you think of as "protecting", what would be different? Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
On Friday, October 15, 2010 01:58:07 pm Barry Leiba wrote: > On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos wrote: > > Murray S. Kucherawy wrote: > >>> I appreciate the desire to put more information in there to help, but > >>> we really can't be writing a tutorial on managing DNS records. > >> > >> +1. However, I'd be fine with adding some informative guidance to DKIM > >> implementers reflecting current experience, something like: "The use of > >> wildcard TXT records in the DNS often result in something coming back > >> from a query that isn't a valid DKIM key record (and ADSP will encounter > >> the same thing). Verifiers should expect this to occur and plan > >> accordingly." > > > > Thank you Murray. Something small and sweet will be useful, and your > > text is good enough. > > Good; we have a start. Will others please indicate support (or not) > for adding this or similar text ? > > Barry, as chair I'm neutral on the subject of covering this topic, but if we are going to cover it, this or similar text is good. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
On Friday, October 15, 2010 10:04:40 am MH Michael Hammer (5304) wrote: > why don't we just deprecate "l="? Yes. Please. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
"Barry Leiba" wrote: >On Thu, Oct 14, 2010 at 12:45 AM, SM wrote: >> At 17:31 13-10-10, Hector Santos wrote: >>>My proposal to add more informative notes to help minimize this for >>>the systems with the lack of DNS admin expertise on board. In >>>particular for those with currently one existing need for a TXT record >>>and that is SPF and incorrectly believe since its a TXT record, adding >>>the DKIM public key data to it will work. >> >> There is an assumption that people managing DNS zones will have a >> basic understanding of DNS. Â I don't think that the DKIM >> specification should get into badly designed GUIs. > >I agree, more generally, that the DKIM spec can't tell people the >right way to manage their DNS records. DKIM already separates its TXT >records with the "_domainkey" identifier, as SPF does with _spf. If, >given that separation, people still merge the TXT records and whatnot, >that problem's well beyond the scope of our work to fix. > >I appreciate the desire to put more information in there to help, but >we really can't be writing a tutorial on managing DNS records. > >Barry, as participant > +1. Just as a note of clarification, SPF doesn't prefix TXT records, but I don't think that affects the analysis. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
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 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 a DKIM signed message that is signed by any entity and add > > additional From/Subjects and the message may still appear to be the one > > signed by the original entity even though it's been modified > > post-signature. > > Right. I had understood that and then forgot. > > If DKIM is just viewed as providing an identifier and nothing more, > then this is a MUA problem. > > If DKIM is viewed as providing more than an identifier, then this is a > DKIM problem. The identifier only makes sense within a context. For DKIM that context is the signed content. For the identifier to be meaningful, it has to be connected to the actual content of the message, if not, the identifier could be arbitrarily reused and would serve little purpose. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
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 a DKIM signed message that is signed by any entity and add additional From/Subjects and the message may still appear to be the one signed by the original entity even though it's been modified post-signature. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
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-dkim] detecting header mutations after signing > > > > The bad guy (the phisher) provides two From headers, but only signs one > > which, as DKIM is currently defined, has to be the second one. > > > > His two headers are: > > From: i...@ebay.com > > From: i...@phisher.com > > > > BUT many/most MUAs currently display only the first From header if two > > are provided. There is no reason why the verifier at the boundary should > > report an invalid signature, so the message gets through to the intended > > victim who just sees what his MUA shows him, which apparently is a > > message from the genuine ebay address. > > This is true if the message is not DKIM-signed at all. The rendering > choice you're highlighting here already exists in many/most MUAs. > > If we can extract DKIM from the equation entirely and the problem remains, > how is it a DKIM problem? If the DKIM signature doesn't verify after signed headers have been altered, then it's not. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
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 convenience for key rotation and > ease of domain delegation. They have no semantics beyond > being used to query DNS to find the public key. Sure. That's the right answer from a standard POV, but if I can extract statistically significant information by segregating mail streams by selector, I'll do it anyway, I don't care what the standard says (no, I haven't done this analysis yet, so I don't have an opinion on if one actually could do it or not). Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
"Dave CROCKER" wrote: > > >On 10/12/2010 11:21 AM, Murray S. Kucherawy wrote: >>> -1; I like the wording that's there. >> Concur; -1 on the change. I furthermore submit that we are compelled to >> describe the known "attack", as that's precisely what we are supposed to >> include in Security Considerations. > > >We should keep in mind that DKIM's job is to deliver a validated domain name. >I >believe none of the "attacks" that have been discussed have anything to do >with >that task. Instead, they pertain to other forms of attack on perceived >message >content validity, which is entirely outside of DKIM's scope. > >Seriously. > -1. Seriously. DKIM also attempts to provide assurance that content is unmodified. Without that the identity assurance is meaningless. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Friday, October 08, 2010 01:41:15 pm Murray S. Kucherawy wrote: > > -Original Message- > > From: ietf-dkim-boun...@mipassoc.org > > [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman > > Sent: Friday, October 08, 2010 10:01 AM > > To: ietf-dkim@mipassoc.org > > Subject: Re: [ietf-dkim] detecting header mutations after signing > > > > > We want to re-submit DKIM Signing to Proposed Standard, in order to fix > > > an edge condition that is only a theoretical issue and only fixes a > > > problem that is actually outside of the scope of what DKIM is trying > > > to achieve? > > > > Detecting modification in transit is outside the scope of what DKIM is > > trying to achieve? > > Doesn't DKIM try to detect modification of the portion covered by the > hashes, which is unchanged in this scenario? For what I view as a very abstract definition of unchanged, sure. I think adding additional From or Subject does change the content of the message From or Subject. If one takes the view that we've defined things such that this is OK from a protocol definition perspective, so it's not an issue, I think we've lost sight of the original goal of this requirement in the protocol. I think that this can be dealt with through an additional security consideration and doesn't have to disrupt the rush to get this advanced through the standards process. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Friday, October 08, 2010 12:33:38 pm Dave CROCKER wrote: > On 10/8/2010 9:28 AM, Murray S. Kucherawy wrote: > > I'm still cringing at the layering violation of "fixing" in DKIM the fact > > that many RFC5322 implementations, MTAs, MSAs and MUAs alike, don't > > bother to enforce normative portions of that specification. > > > > Is there precedent of this being done elsewhere, i.e. compensating in one > > protocol for abundant lousy implementations of a layer below it? > > I'm a bit confused. > > We want to re-submit DKIM Signing to Proposed Standard, in order to fix an > edge condition that is only a theoretical issue and only fixes a problem > that is actually outside of the scope of what DKIM is trying to achieve? > > d/ Detecting modification in transit is outside the scope of what DKIM is trying to achieve? Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
"Dave CROCKER" wrote: > > >On 10/6/2010 8:00 AM, Steve Atkins wrote: >> It also changes what DKIM means, >... >> Either the message has a valid DKIM signature, or it does not. If the >> signature is valid, then the signing domain takes responsibility for the >> message, subtly malformed or not. Just because the message lacks a Date: >> header or has bare linefeeds doesn't mean that the signing domain isn't >> responsible for it. > >THis is a particularly clean and precise attention to DKIM's job, nicely >filtering out issues that are not part of DKIM's job. > >In particular, it makes the multiple From: issue entirely irrelevant to DKIM. > In a normative sense, perhaps, but in real world terms, it doesn't. Since this does away with "It's not valid 5322, so it can't be valid DKIM", it puts the question of how implementors should deal with such things back on the table. I'd like to see us include a general helpful note to implementors about covering the case where a duplicate header field is added after signing. Maybe this is an added item for security considerations? Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
"Murray S. Kucherawy" wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] >> On Behalf Of Scott Kitterman >> Sent: Tuesday, October 05, 2010 12:24 PM >> To: ietf-dkim@mipassoc.org >> Subject: Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple >> 5322.From >> >> Nack. DKIM also purports to provide assurance that the signed content >> of the message is unmodified. I think mentioning that all instances of >> a header that is signed should be used for signing and verification is >> a useful data point for implementors. > >I'm having trouble parsing that. Aren't all instances of a signed field used >for verifying already? Or are you proposing an "If you sign one, you have to >sign them all" sort of approach? > >That will wreak havoc with Received:, if so. > I'm suggesting making it clear that if one signs a type of field they should sign all of them. I'm not suggesting adding any requirements that additional types of fields be signed. Scott K P.S. I'm not sure I parsed your question correctly. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
"Dave CROCKER" wrote: > > >On 10/5/2010 8:15 AM, Ian Eiloart wrote: >>> It has been observed by implementations that is it possible to replay >>> > a message with a 2nd 5322.From header at the top which wouldn't break >>> > the DKIM signature validity, but would often be displayed by MUAs to >>> > display the new 5322.From display rather than the signature bound >>> > 5322.From header. >> Ouch. That's nasty. But wouldn't it be better to advise MUA vendors to >> display the signed header? Are there really MUA's that will display the >> unsigned headers*and* assert that it was validated? If so, that's surely a >> bug in the implementation of the MUA. > > >Your comments underscore the importance of being careful about what we expect >from DKIM. As you note, if software is DKIM-aware, it also needs to be >DKIM-intelligent. > >At a deeper level, there is a continuing problem with casting DKIM as a >mechanism to "protect" a message. That's something that OpenPGP and S/Mime >do; >it's not something DKIM does. DKIM merely tries to do enough to ensure that >the >d= is valid, to provide a basis for reputation assessment. > >Hence, I recommend that this ISSUE be declined and closed. > Nack. DKIM also purports to provide assurance that the signed content of the message is unmodified. I think mentioning that all instances of a header that is signed should be used for signing and verification is a useful data point for implementors. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
"John R. Levine" wrote: >> The law requires that there be an easy to use address for unsubscribing. >> The List-unsubscribe header: would do the job nicely, if the majority of >> people were using mail clients that expose it by default. I don't know of >> any mail client which does that. > >pine/alpine does, but I agree, most MUAs don't show headers other than To, >From, Cc, and Subject. > >This might be a good time to remind people that MLMs in their current form >are not broken, and any proposal that requires them to stop doing >something that they're currently doing, like rewriting messages or adding >message tags, is a non-starter. > Since nothing requires anyone do anything with respect to DKIM, I'm hard pressed to imagine something that doesn't meet that requirement. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-vesely-dkim-joint-sigs
On Thursday, September 23, 2010 03:16:53 pm John R. Levine wrote: > >> Ian, this makes no sense to me. If a signing domain is concerned enough > >> to choose to implement ADSP, why would they reduce what they are signing > >> to accommodate a small percentage of their mail going to MLMs that they > >> may or may not be able to identify? > > I'm with you. All of this emphasis on complex designs for MLMs strikes me > as a waste of time, since it's a tiny corner of the mail space that has > not historically been a vector for abuse, and shows no sign of becoming > one. > > That's why my advice is that lists should sign their mail, which is easy > and at worst harmless, and we're done. > > R's, > John In that case, we should just say we're done. I see zero value in a document that says people should sign mail. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC4871 5322.From Binding - Proposal to relax it.
On Thursday, September 16, 2010 03:23:15 am Hector Santos wrote: > Scott Kitterman wrote: > >> My Technical recommendation. > >> > >> 1) For 4871bis, we should consider relaxing the 5322.From > >> > >>binding requirement from a MUST to a SHOULD. This will help > >>justify its new words of "separating the signer domain from > >>the author domain." There is no separation until the 5322.From > >>binding requirement is relaxed. > > > > As discussed during the original DKIM development effort, this > > is about protecting content from modification. The base DKIM spec > > already doesn't treat 5322.from specially, so such a change in not > > needed to meet your specified goal. > > Excuse me if I don't understand your reading. 5322.From is the only > header that is required hashing. Is that not a special consideration? > > I think it will serve the community interest to find out why this > large MTA vendor revised there open source software three years later > presumably after extensive field operations to include a new option to > relaxed the 5322.From binding. Finding out why sounds reasonable. What you propose isn't finding out why, but assuming it's valuable without bothering to find out. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC4871 5322.From Binding - Proposal to relax it.
"Hector Santos" wrote: >Based on existing open source DKIM API code from a large MTA, they >must of come across signatures that did not include the 5322.From >signature binding requirement of RFC 4871 because it contains an >option to not enforce 5322.From hash binding in the DKIM.H header. I don't think that's a reasonable conclusion do draw from this data point. >In other words, if the DKIM-Signature h= header does not have the >"from" value, then this code has an option to ignore this RFC 4871 >requirement and allow this type of DKIM-Signature. > >Although the API is technically violating RFC 4871, they must of did >this for a reason but I am not totally clear what all scenarios this >will cover with Author Domains who sign without the 5322.From bind. Protecting messages from in transit modification was one of the DKIM design goals. Excluding this user visible header from such protections is not a good idea. This is an even worse idea than "l=". >The main point is they found an implementation reason to add an >verification option to relax the RFC 4871 MUST hash 5322.From requirement. People implement all kinds of thing for all kinds of reasons. Don't depend very much on the mere fact of an implementation tidbit. >My Technical recommendation. > >1) For 4871bis, we should consider relaxing the 5322.From >binding requirement from a MUST to a SHOULD. This will help >justify its new words of "separating the signer domain from >the author domain." There is no separation until the 5322.From >binding requirement is relaxed. As discussed during the original DKIM development effort, this is about protecting content from modification. The base DKIM spec already doesn't treat 5322.from specially, so such a change in not needed to meet your specified goal. >2) We should consider a 5617bis (ADSPbis) to codify its semantics >regarding Author Domain only signature policies to include a: > >Always sign by *anyone* Policy. > >Currently 5617 (ADSP) defines the two policies: > > > all All mail from the domain is signed with an Author > Domain Signature. > > discardable All mail from the domain is signed with an Author > Domain Signature > >Many people felt we were missing the "Signed by Anyone" concept which >did not help "authorized" 3rd party signers or the list servers who >are going to be resigning. To compensate, many viewed ADSP=ALL to >mean it allowed any signer, not just the Author Domain as defined by >the spec. > >In fact, this same DKIM API includes ADSP support and it also >interprets ADSP=ALL as an anyone can sign concept as long as there is >a valid signature. There is no option in the software to follow >ADSP=ALL exactly how it it defined in 5871. It sounds to me like a bug. >Since this is an API from a large MTA vendor, I would not ignore this >implementation "data point." If the suggestion is made the software is >"buggy" then we are back to a status quo of non-resolution of >conflicting issues regarding the author domain, 3rd party signers >and/or list servers. > Since anyone can generate a DKIM signature with a signing domain they control, an unconstrained 3rd party signing policy means precisely nothing. Without some kind of constraint (1st party only or a defined set of third party signers) arbitrary senders could meet the policy requirements. - 1. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Tuesday, September 14, 2010 09:18:23 am John R. Levine wrote: > As I keep saying over and over, discardable really means discardable: if > in doubt, throw it away. It does NOT, repeat NOT, mean high value mail. > It means low value mail. I think your view is to narrow. It means that the domain owner prefers it be discarded if not signed. This means they view the risks of having legitimate mail discarded as lower than the risks associated with having unsigned mail delivered. This is a relative assessment. Your "low value mail" assertion only addresses one part of that equation. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
"John Levine" wrote: >>It's not clear to me that there's consensus that anything qualifies as Best >>Current. We have some small samples of a few things that some people have >>tried, but I don't sense we're there yet. > >I hope that lists signing their outbound mail qualifies. Large >providers Googlegroups and Yahoogroups do it, small providers >including MAAWG and myself also do. > >Beyond that, you're right, we're at best guessing and at worst pulling >stuff out of our whatevers. > Which brings us back to the question of the value of the DKIM working group writing an RFC that suggests people should sign mail. I don't think it has much. I think an experimental document that amounts to something like "We've thought about this a lot and discussed it and collectively we've got NFC yet what's best yet. Here are some ideas ..." is what's most needed. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
"Steve Atkins" wrote: > >On Sep 10, 2010, at 3:46 PM, Scott Kitterman wrote: > >> On Friday, September 10, 2010 06:37:46 pm Steve Atkins wrote: >>> On Sep 10, 2010, at 2:31 PM, Scott Kitterman wrote: >>>> >>> >>> I don't think it inoculates them against ADSP problems - rather >>> it opens them up to violations of the security model that ADSP >>> would like to impose. >>> >> This is only true if John is wrong and mailing lists are a vector that we >> need >> to worry about. > > >Doing what you suggest would avoid the problems of legitimate >email being discarded due to ADSP/mailing list interactions at >the cost of allowing phishers to send email "from" a sender >violating the ADSP security model simply by pretending to be >a mailing list. > >> I happen to generally agree with him on this. > >Me too. But you're breaking the ADSP security model for all >email with your suggestion. Note that neither of the examples >I gave involved me sending a phishing email via a mailing >list. > I don't think it breaks it. It avoids it and I think that's fine. Whatever limited value ADSP provides, it is only relevant to exact domain phishing. What we are describing is a putative weakness that's already beyond it's design scope. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Friday, September 10, 2010 06:37:46 pm Steve Atkins wrote: > On Sep 10, 2010, at 2:31 PM, Scott Kitterman wrote: > > On Friday, September 10, 2010 03:17:47 pm Steve Atkins wrote: > >> On Sep 10, 2010, at 11:27 AM, Charles Lindsey wrote: > >>> On Fri, 03 Sep 2010 15:15:37 +0100, Hector Santos > > > > wrote: > >>>> I think you need to better appreciate and understand how fundamental > >>>> the "Message" From field for any forms of communications and/or mail > >>>> networks is. It would be a radical change to open up this door and > >>>> "Pandora box" to make it the norm and mindset that a From: is > >>>> unreliable. Not saying it is not prone to abusive, but fundamentally, > >>>> when people believe in the message, they also make that natural > >>>> trusted tie to the author of the message. > >>> > >>> Yes, but nobody is trying to change that. We seem to be agreed that > >>> what a mailing list sends is, from some POV, a "new" message, and so > >>> logically a new "From:" is not wholly out of order. > >> > >> What's the benefit to this, though, other than obscuring the original > >> author? > > > > If you agree with John Levine's proposal that mailing list mail is, in > > general, not a problem then there is negative value in mailing lists > > throwing away (discarding) good mail from domains that happen to use > > ADSP Discardable (or any other mechanism for inferring something from > > the lack of a signature - this isn't really ADSP specific, it's just the > > implementation we have at the moment). If this negative event can be > > avoided by the simple mechanism of using a mailing list specific > > "Message" From, then that is a benefit. > > Rather than go into the general reasons why I think this is not > something that ADSP users really want, I'll give a concrete > example. > > Lets say this mailing list rewrites the From: address in some > reasonably mechanical manner, and the From: field of > this message were rewritten as (making up syntax on > the fly)... > > From: steve%blighty.com%ietf-d...@mipassoc.org > > ... such that recipients (or their MUAs) know that this mail > was sent by st...@blighty.com via a mailing list at > dkim.org. > > There's nothing to stop me from sending mail > From: billing%paypal.com%ietf-d...@mipassoc.org, as > the mailing list isn't using ADSP. And there's certainly > nothing to prevent me from sending mail from > billing%paypal.com%ietf-d...@blighty.com that has > a valid first-person signature. > > That means that, as far as the end user is concerned, > I can send them email that is "from" bill...@paypal.com, > even though paypal.com is using ADSP to ask receivers > to discard mail that claims to be from paypal.com but > is not validly signed by paypal.com. > > Given the whole point of ADSP is "Discard if you're not > sure", I don't think that's what an ADSP using domain > would want. > > (The effect is softened somewhat if you use random > from addresses with no connection to the real address, > but only somewhat. And that damages the communication > between users quite a bit more. That's what I meant when > I talked about obscuring the author, upthread). > > > This is > > > > not the only potential use of such a feature. I've spoken to one MLM > > developer who told me the feature has been previously requested for > > privacy reasons nothing to do with DKIM or ADSP. > > That would be "for obscuring the original author", and > it's certainly possible for MLMs to do that now, though few > do. > > > I think this is quite reasonable as it would inoculate MLM users from > > ADSP (or similar) problems in a way that does not limit their ability to > > promote communication among their subscribers (which is what mailing > > lists do). > > I don't think it inoculates them against ADSP problems - rather > it opens them up to violations of the security model that ADSP > would like to impose. > This is only true if John is wrong and mailing lists are a vector that we need to worry about. I happen to generally agree with him on this. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Friday, September 10, 2010 05:53:57 pm J.D. Falk wrote: > On Sep 10, 2010, at 12:34 PM, John R. Levine wrote: > >> The problem is that too many people on this WG take the view "I believe > >> in solution-X (TPA, PGP-MIME, don't use ADSP because it's broke, don't > >> use mailing list if you advertise 'discardable') and I will vote down > >> any solution other than X". > > > > Call me old-fashioned if you will, but I take the view that a purely > > hypothetical paper design to address a largely hypothetical problem, with > > unknown security problems, unknown user interface problems, and unknown > > interoperation problems have no place in a document about actual e-mail > > practice. > > +1 > > It's the difference between Best Current Practices and Things We Thought Of > But Haven't Tried Yet. Either could be published as an I-D, but we > shouldn't try to fit both approaches into the same BCP. It's not clear to me that there's consensus that anything qualifies as Best Current. We have some small samples of a few things that some people have tried, but I don't sense we're there yet. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Friday, September 10, 2010 03:17:47 pm Steve Atkins wrote: > On Sep 10, 2010, at 11:27 AM, Charles Lindsey wrote: > > On Fri, 03 Sep 2010 15:15:37 +0100, Hector Santos wrote: > >> I think you need to better appreciate and understand how fundamental > >> the "Message" From field for any forms of communications and/or mail > >> networks is. It would be a radical change to open up this door and > >> "Pandora box" to make it the norm and mindset that a From: is > >> unreliable. Not saying it is not prone to abusive, but fundamentally, > >> when people believe in the message, they also make that natural > >> trusted tie to the author of the message. > > > > Yes, but nobody is trying to change that. We seem to be agreed that what > > a mailing list sends is, from some POV, a "new" message, and so > > logically a new "From:" is not wholly out of order. > > What's the benefit to this, though, other than obscuring the original > author? If you agree with John Levine's proposal that mailing list mail is, in general, not a problem then there is negative value in mailing lists throwing away (discarding) good mail from domains that happen to use ADSP Discardable (or any other mechanism for inferring something from the lack of a signature - this isn't really ADSP specific, it's just the implementation we have at the moment). If this negative event can be avoided by the simple mechanism of using a mailing list specific "Message" From, then that is a benefit. This is not the only potential use of such a feature. I've spoken to one MLM developer who told me the feature has been previously requested for privacy reasons nothing to do with DKIM or ADSP. I think this is quite reasonable as it would inoculate MLM users from ADSP (or similar) problems in a way that does not limit their ability to promote communication among their subscribers (which is what mailing lists do). Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Wednesday, September 01, 2010 08:23:19 am John Levine wrote: > >> At this point, unless we can cut back the MLM document to stick to > >> items that we have consensus about, e.g., that it is typical for > >> signatures applied to incoming mail not to verify after a message > >> passes through an MLM, and that it would be nice if a list or its MTA > >> signed its outgoing mail, I don't think we will produce anything that > >> is useful to anyone. > > > >If that's all we can say, I'd say don't bother. I don't see much value in > >the DKIM working group saying it thinks mail should be signed by DKIM. > > "e.g." means "such as" or "for example." > > I expect there's a fair amount we agree on. Maybe it's enough to be > worth documenting, maybe not, but I think it would be more productive > to see what we agree on rather than trying to force our pet projects > into the document. > > I'll cheerfully give up references to S/MIME, if other people will > give up on telling software developers how to rewrite MLMs to do > things they've never done before. > > Don't forget that an experimental RFC is the accepted way to document > a paper design to see if it gets any traction, as the EAI group did > with various ways to represent non-ASCII e-mail addresses. Since things to do to get signatures to survive on mailing lists doesn't seem to be on your list of stuff we agree on, what else is? I know you said e.g., but given what I understand you to not agree on, I'm not sure what else is left. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Wednesday, September 01, 2010 05:18:02 am John Levine wrote: > >> ANNEX A - MUA Considerations > > > >Is a draft about mailing lists the right place to make recommendations > >to MUA developers? Seems like those should probably be in a separate > >document. > > No, but the entire document is riddled with advice that has no basis > in experience and is unlikely ever to be implemented. > > We have a serious problem that people in this group have deeply > incompatible ideas of what DKIM does. A lot of the arguments seem to > be from people who believe that a DKIM signature can or should > identify the individual author of a message, and that subscribers to > mailing lists need assurances about the identity of list authors > beyond the minimal level that has been adequate for the past twenty > years. I have trouble understanding how anyone who is familiar with > DKIM or with the operation of mailing lists could hold these > positions, but it is quite obvious that some do. > > At this point, unless we can cut back the MLM document to stick to > items that we have consensus about, e.g., that it is typical for > signatures applied to incoming mail not to verify after a message > passes through an MLM, and that it would be nice if a list or its MTA > signed its outgoing mail, I don't think we will produce anything that > is useful to anyone. If that's all we can say, I'd say don't bother. I don't see much value in the DKIM working group saying it thinks mail should be signed by DKIM. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposed changes to MLM draft
On Monday, August 30, 2010 02:03:45 pm Murray S. Kucherawy wrote: > I'd like some help tackling the next version of the MLM draft. People seem > to have varying ideas about what should be removed and perhaps appear in > other documents now. I need some consensus on a direction in which to > proceed. > > So can I please get some +1s/-1s on each of the following: > > (1) Split the document into three documents: A DKIM MLM BCP that discusses > signing and verifying in the context of MLMs with no value-add items > addressed, a DKIM MLM Informational that discusses possible value-add > enhancements to MLMs in the DKIM world, and a non-WG BCP about mailing > lists irrespective of DKIM (Dave's proposal); -1. I don't think the first part has much value without the second (if I understand the split correctly). > (2) Tear out everything having to do with making author signatures survive > list relaying, dropping all that text altogether, and instead pointing > people at S/MIME or PGP (John's proposal); -1. While I think it's premature to specify "THE" way to solve such problems, I think it's useful to present possibilities for implementers to consider. I don't think redefining the problem so that a class of failures are no longer failures is helpful. > (3) Something else (and specify what that might be). > > AND... > > If you support any of the above, please take a few minutes to include some > pointers to what text you want changed/exported and in what way. Actual > diffs would be ideal, but I'll take point-form commentary as well. I'll try and do this, but not today. > AND... > > If you advocate for a general MLM BCP, this will be a non-WG document (it's > outside of our charter) so I'd love to get some MLM operators and > developers involved. (Maybe this should take place on ietf-822 or maybe > on a new non-WG list; suggestions welcome.) Expressions of interest in > that work would be appreciated. I'll approach the APPS ADs about a venue. > > Thanks, > -MSK Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Feedback on draft-ietf-dkim-mailinglists for discussion
"Dave CROCKER" wrote: > > >On 8/2/2010 11:34 AM, Steve Atkins wrote: >> A "-1" on ever altering the From: field for any reason other than special >> requirements of the people running a specific mailing list. > > >A +1 in support of that -1. > >The view that modifying the From: is helpful has no empirical basis. I'll >claim >that there is a pretty good theoretical basis for believing it makes things >worse, not better. > >As always, the instant the IETF gets into user interface design, it steps out >of >its group competence. As a group, we do not have the training in cognitive >models, UXE, or the rest of what's needed to work in this space. > That seems pretty orthogonal to the discussion so far. Declaring discussion of From off limits because it is also displayed makes me wonder why you thought it was alright for the IETF to take on the work codified in RFC 822 and its descendants? Just because it's displayed doesn't mean any change is driven by UX considerations. I get that you're intent on avoiding anything that might make ADSP deployment less difficult, but please stick to the arguments that make some sense. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Straw poll results
On Monday, August 09, 2010 06:52:04 pm Steve Atkins wrote: > On Aug 9, 2010, at 3:13 PM, Scott Kitterman wrote: > > This assumes mail from MLMs is treated differently than other mail. > > While individual users may (and probably do) treat it differently, > > receivers of non- trivial scale don't and can't. > > I agree, in general. > > One implication of that is that if you're planning to do something with > email that will break if there's a MLM involved, it's broken[1]. > > Cheers, > Steve > > [1] We could call this "The SRS lemma". Yes. It's very similar. One needs to decide what factors one cares about the most. I said a few threads ago that I don't think there is a completely satisfactory solution. I think the possibilities are roughly: 1. Fix lists so that signatures survive. 2. Have MLMs change the domain of the message. 3. Have mail get rejected/discarded/etc. There are variants of all three possibilities, but none that will satisfy everyone. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Straw poll results
On Monday, August 09, 2010 06:48:51 pm John Levine wrote: > >This assumes mail from MLMs is treated differently than other mail. > >While individual users may (and probably do) treat it differently, > >receivers of non- trivial scale don't and can't. > > Sigh. Anyone who uses gmail would know that your assertion is just > plain wrong. There's a difference between "claims to be from an MLM" and "From an MLM". Today there isn't much value in making the claim, so no one bothers. It would be unfortunate if we recommended something that caused List-ID headers to be less useful because people found value in spoofing them. > And in any event, even if your assertion were true, so what? Our > working assumption is that receivers will use valid DKIM signatures to > whitelist mail from signers they like. How does it matter whether the > signer happened to be a related to a list? > If I'm a consumer of your list of domains that you're convinced sign all their mail and I get an unsigned message from one of them, I'm bound to be extra suspicious of that. "Oooh, it came from a mailing list so I don't care" isn't the most likely response. Which is why the whole straw poll is irrelevant. Since the D in DKIM is Domain, it's really no concern how individuals filter mail. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Straw poll results
On Monday, August 09, 2010 05:22:35 pm Steve Atkins wrote: > On Aug 9, 2010, at 1:26 PM, Scott Kitterman wrote: > > On Monday, August 09, 2010 04:11:57 pm John R. Levine wrote: > >>> Why do you simplify handling of list mail to sorting and filtering, > >>> ignoring two other important list handling activities: > >>> > >>> 1. reading mail > >>> 2. responding to mail > >> > >> Well, OK. Can you offer some non-hypothetical situations where you > >> would read or respond to list mail differently if there were extra > >> assurance on identity of the list contributor? > >> > >> Or to put it another way, if someone has put an S/MIME signature on a > >> messsage sent through a list, does that affect the way you respond? > > > > It's not at all clear to me that the answer to that question is in any > > way related to the work of the working group. What would we design > > differently if the answer was yes (or no)? > > If a recipients handling of an inbound email from a mailing list varies > depending on whether you can authenticate the original author (the > > >From field) or not, then there may be some value in helping mailing > > lists tunnel authentication through in a way that allows you to > authenticate the original author. > > If it doesn't, there isn't. > > If none of the members of this list would handle an inbound email from > a mailing list depending on whether they can authenticate the original > author or not, nor point at a concrete example of people ding so, that > would suggest it's not a common requirement. Which would suggest it's > not worth considering how to support it for DKIM, which seems to be at > least tangentially related to what we're doing here. This assumes mail from MLMs is treated differently than other mail. While individual users may (and probably do) treat it differently, receivers of non- trivial scale don't and can't. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Straw poll results
On Monday, August 09, 2010 05:38:18 pm Rolf E. Sonneveld wrote: > Scott Kitterman wrote: > > On Monday, August 09, 2010 04:11:57 pm John R. Levine wrote: > >>> Why do you simplify handling of list mail to sorting and filtering, > >>> ignoring two other important list handling activities: > >>> > >>> 1. reading mail > >>> 2. responding to mail > >> > >> Well, OK. Can you offer some non-hypothetical situations where you > >> would read or respond to list mail differently if there were extra > >> assurance on identity of the list contributor? > >> > >> Or to put it another way, if someone has put an S/MIME signature on a > >> messsage sent through a list, does that affect the way you respond? > > > > It's not at all clear to me that the answer to that question is in any > > way related to the work of the working group. What would we design > > differently if the answer was yes (or no)? > > Let me try to explain. If the identity of the list contributor is of any > value to the receiver of an MLM-distributed message, then it is > important to (try to) preserve the original DKIM signature across an MLM > redistribution of the message (if at all possible). If however the > identity of the list contributor is of no value whatsoever, we should > not bother about preserving the original DKIM signature. > Not at all. If the receiver is going to act differently to signed or unsigned mail from certain domains, then it's important to preserve the signature or change the domain. For receivers of non-trivial scale they aren't in a position to know what mail they are receiving is MLM-distributed, so the question of how they would treat MLM-distributed mail is irrelevant because they don't and can't segregate it that way. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Straw poll results
On Monday, August 09, 2010 04:11:57 pm John R. Levine wrote: > > Why do you simplify handling of list mail to sorting and filtering, > > ignoring two other important list handling activities: > > > > 1. reading mail > > 2. responding to mail > > Well, OK. Can you offer some non-hypothetical situations where you would > read or respond to list mail differently if there were extra assurance on > identity of the list contributor? > > Or to put it another way, if someone has put an S/MIME signature on a > messsage sent through a list, does that affect the way you respond? > It's not at all clear to me that the answer to that question is in any way related to the work of the working group. What would we design differently if the answer was yes (or no)? Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature
On Tuesday, August 03, 2010 08:02:34 am Hector Santos wrote: > It seems much easier for MLS (Mail List Servers) to preempt > restrictive ADSP Domains from subscribing and from submitting mail to > the list enabled with DKIM resigning. This would also give you the use case to deal with of restrictive ADSP published after someone has already subscribed. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Feedback on draft-ietf-dkim-mailinglis ts for discussion
On Monday, August 02, 2010 02:39:05 pm Michael Thomas wrote: > On 08/02/2010 11:21 AM, Scott Kitterman wrote: > I think this is worth considering. In discussions with one of the > developers > > > of a major open source MLM, he mentioned to me that they've had feature > > requests over the years to alter From due to privacy/spambot harvesting > > reasons, so this isn't something that would only serve to mitigate damage > > due to ADSP. > > Yeahbut... given the inertia how much could we possibly expect? There's > going to be breakage and hence resistance to this were it a good idea > (which I'm not sure of). Suppose only 10% by volume of lists did this, > would it still be a net benefit? > I don't think there are any solutions to ADSP and MLMs that are unadulterated good. I think each option has risks and benefits. I think this is one reasonable approach that may suit some lists and be implemented for some MLMs. I think it doesn't risk mail loss and is consistent with existing standards. It does require some change in practices, but I think that's rather the point of the document. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Feedback on draft-ietf-dkim-mailinglists for discussion
On Monday, August 02, 2010 02:13:39 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: Monday, August 02, 2010 10:53 AM > > To: DKIM List > > Subject: Re: [ietf-dkim] Feedback on draft-ietf-dkim-mailinglists for > > discussion > > > > > c) A "-1" to the idea of altering From: to cope with ADSP; the reason > > > > given: > > > "This presumes endpoints will understand a DKIM-related From:-altered > > > message." > > > > I must of missed that point in Daniel's thread. I hadn't realized that > > the From would of been conditionally re-written. Today, endpoints (I > > take that to mean MUAs), don't seem to have a standard way of dealing > > with mailing lists anyway. So I'd say -1 to the reason. > > I don't think there's anything conditional about it. The suggestion is to > rewrite From: when the MLM remails its modified content. > > It sounds like you're saying that's a good idea. By my count that's three > in favour and two against, and I suspect that's not rough consensus in > either direction, but is probably enough to add some discussion about it > to the draft, unless of course there's objection to even mentioning the > idea. I think this is worth considering. In discussions with one of the developers of a major open source MLM, he mentioned to me that they've had feature requests over the years to alter From due to privacy/spambot harvesting reasons, so this isn't something that would only serve to mitigate damage due to ADSP. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Alternative MAiling List Approach
On Friday, July 30, 2010 11:48:22 am Steve Atkins wrote: > On Jul 30, 2010, at 12:26 AM, Murray S. Kucherawy wrote: > >> -Original Message- > >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > >> boun...@mipassoc.org] On Behalf Of Steve Atkins > >> Sent: Thursday, July 29, 2010 8:56 PM > >> To: DKIM List > >> Subject: Re: [ietf-dkim] Alternative MAiling List Approach > >> > >> On Jul 29, 2010, at 3:45 PM, Murray S. Kucherawy wrote: > >>> Should the MLM draft suggest From: replacement and addition of Reply- > >> > >> To: as a specific example of DKIM-friendly MLM behavior? > >> > >> No. DKIM doesn't really say much about either the From: address or the > >> Reply-To: address, so such a suggestion for "DKIM-friendly" behaviour > >> would be nonsensical. > >> > >> It might be a reasonable suggestion for the benefit of other protocols, > >> but that's a different question. > > > > Is it not an ADSP issue though? Covering ADSP issues is (at least > > implicitly) in scope for this document. > > It may well be an ADSP issue - I've not looked in detail at the > proposal - and it may be in scope for this document. (I suspect > it's also a bad idea, but that's a separate discussion). > > It's definitely not a DKIM issue, though, and any labeling of a > non-DKIM issue as "DKIM-friendly" would be misleading. IIRC we used to refer to the DKIM base signing spec and ADSP (and all the names it previously had, most of which I've fortunately forgotten) as both being part of DKIM. It seems a bit odd to me to refer to issues with specs produced by the DKIM working group as "non-DKIM". Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Alternative MAiling List Approach
On Thursday, July 29, 2010 12:46:34 pm Alessandro Vesely wrote: > On 29/Jul/10 13:21, Charles Lindsey wrote: > > The REAL cause of the problem is that From: line. My proposal is that MLM > > should change the From: header in such a way that the mail appears to > > have come from MLM.example and not from discardable.example. Clearly, > > this removes the cause of the problem at a stroke (the mail will no > > longer be discarded), but obviously it raises several other issues > > instead. > > SRS on "From"? It is intriguing that, after having taken a rather > different approach, DKIM faces much the same problems that SPF had > been criticized for, for the same minor fraction of the email traffic. > > IMHO, the real cause of the problem is that the same "From" field is > being used for entirely different message streams. On the one hand, > the MLM wants the input message to be signed, so it can authenticate > the poster. On the other hand, MLM output isn't the land of the > author domain (including IPR, usually) even if the original "From" > stays there to identify the author. First, it's a different minor fraction of email traffice (forwarding versus mailing lists), but more importantly there's clear support in the standards for treating mailing list mails as a new transmission, rather than a continuation of the old one. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP and Discardable (was Re: Lists "BCP" draft review)
"Dave CROCKER" wrote: > > >On 6/2/2010 8:08 AM, Al Iverson wrote: >> Agree. "Discard" and "silently discard" mean the same thing, in my >> opinion. Though, I am guilty of using the phrase "silently discard." >> Maybe in an attempt to be slightly over-specific. > > >I do not recall seeing a dictionary or technical definition of "discard" that >says anything at all about whether the discarder says anything at all. > >Taken on its own and without further technical specifications 'discard' does >not >direct, imply or request that the action be silent or noisy, and if noisy who >gets to hear it. IIRC, this is by design since there was no consensus around what exactly to do. Personally, I tend to favor not having messages silently vanish. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
"John Levine" wrote: >>Similarly, with ADSP you don't have to rely on published information, and >>when information is published, you don't have to guess whether the >>publisher is competent. You can maintain your own list of domains that you >>trust to get ADSP right, and use standard software to apply that judgement. > >Manual drop lists are a fine idea, but what do they have to do with ADSP? > >>1. Code reuse: Although you may choose to maintain your drop list, you >>don't have to write software for your MTA, you can just configure it. > >I'm happy to reuse the manual drop code in Spamassassin. I still don't >see what it has to do with ADSP. > >>2. Discoverability: You can find out from ADSP publications that the sender >>cares about this stuff. OK, it's still a leap to add them to your drop >>list, but you do at least have somewhere to start. > >Here's a thought experiment: let's say you have your list of domains >that are known to be phish targets that sign their mail, so you drop >unsigned mail, and they all happen to publish ADSP. Someone's ADSP >record goes away. Is it more likely that they've stopped signing >their mail, or that their ADSP record is temporarily messed up? Why? Or, I suspect most likely, they thought they were signing everything and then later something changed or they discovered they missed a piece of their infrastructure, so they've retracted the policy until they've corrected the problem. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
... > 1. Do we want to reduce the DKIM broken signature rate or do we want to > make ADSP less vulnerable to it. Or both, I guess. > > 2. If we want to reduce the DKIM broken signature rate, do we need to > rework DKIM at all, or do we need to make operational recommendations to > the generator and signer of the mail, or do we need to provide > operational advice to forwarders and mailing list managers. For any of > those we need to balance the improvement against the reduction in > deployment and reduction in correct deployment the increased complexity > will cause. The history of SPF-all and SRS is likely relevant there. ... I'm curious what level of reliability you think DKIM signatures have currently? And are you measuring at a border MTA or somewhere later in the delivery chain? Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
"Steve Atkins" wrote: > >On May 27, 2010, at 7:38 PM, Scott Kitterman wrote: > >> "Steve Atkins" wrote: >>> >>> That should be >>> >>>> Legitimate email from paypal: >>>> >>>> 72% rejected by ADSP >>>> 28% not rejected >>>> >>>> Phishing emails using "paypal" in the From line: >>>> >>>> 39% rejected by ADSP >>>> 61% not rejected. >>> >> Why "paypal" in the from line and not from payal.com? It sounds like you are >> capturing messages unrelated to any ADSP assertions paypal.com might make. > >No, I'm capturing (a subset of) phishes that were targeting paypal. That >subset was those that were using the string "paypal" somewhere in the From: >field, either in the local part or domain part of the email address or the >"friendly" from. Some of those would have been rejected by ADSP, some >wouldn't. See the message the one you quote was a reply to for the methodology. > >This is just a quick and dirty way to identify a subset of paypal related >phishes, though, as I don't want to grovel through hundreds of thousands of >messages looking for phishes by hand. A more thorough approach would have >found a number of additional phishes that did not have the string "paypal" >anywhere in the From: line, and so which would not have been rejected by ADSP. >In other words, were I more thorough I would have found exactly the same >number of phishes that were rejected by ADSP and I would have found more that >were not rejected. > >(If you were to define phishes targeting paypal as "phishing mail that would >have been rejected by ADSP" then that would lead to 100% of phishes rejected >by ADSP and 0% that weren't. That would be nonsensical, though.) > Selecting messages that are by design outside the scope of what ADSP is intended to deal with to prove ADSP doesn't work is even more so. ADSP does only deal with exact domain forgery. Some people think that's worth doing and others don't. The fact that it is not the miracle solution to all phishing is neither surprising nor particularly interesting. The working group went through this exact discussion when ADSP was being developed. The rough consensus of the group was to go forward and unless there is some new information to cause us to reconsider the decision, hauling the same arguments out again is just wasting time better spent on other things. ADSP is not the policy component for DKIM that I would have designed, but it's the one we have and I'd rather see what can be done with it than rehash preconceived notions. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
"Brett McDowell" wrote: ... >As a newbie to this list, I have to say I agree. This has been a far less >collegial debate than what I'm used to. That said, I may be guilty of >reciprocating, and if anyone feels they have been on the receiving end of >such, I apologize. ... I think your only offense is presenting a perspective based on operational experience that varies from the preconceived notions of a substantial fraction of the participants of this working group. There has been considerable resistance to doing any standardized policy work relative to DKIM. It's unfortunate that this resulted in policy having to be bolted on to DKIM after it was designed because we were prohibited from doing policy work as a part of DKIM development. As far as I can see, the only problem with ADSP and your discussion of it is that ADSP is guilty of doing exactly what it was designed to do with exactly the limitations we said it would have when we designed it. The same people that didn't like it then, don't like it now. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
"Steve Atkins" wrote: > >On May 27, 2010, at 2:22 PM, Steve Atkins thinkoed: >> >> Legitimate email from paypal: >> >>72% rejected by ADSP >>28% not rejected >> >> Phishing emails using "paypal" in the From line: >> >>39% rejected by ADSP >>61% rejected. > >That should be > >> Legitimate email from paypal: >> >>72% rejected by ADSP >>28% not rejected >> >> Phishing emails using "paypal" in the From line: >> >>39% rejected by ADSP >>61% not rejected. > Why "paypal" in the from line and not from payal.com? It sounds like you are capturing messages unrelated to any ADSP assertions paypal.com might make. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] more on discardable, was Lists "BCP" draft
"Roland Turner" wrote: >On 26/05/2010 22:48, Steve Atkins wrote: > >> However, domain B is not an innocent bystander, as they intentionally >> configured their mail system to reject mail it shouldn't, and the >> recipients at domain B support that decision, on some level. > >Domains don't subscribe to mailing lists, individual recipients do. The >recipients in a domain may oppose the domain[-administrator]'s decision, >but often lack the power to have it changed. "Failure to quit your job" >cannot reasonably be construed as consent/support in this context. This just brings us back to the "Do domain owners have a right to control how their domains get used in email" question. If they do, the point is irrelevant. If they don't, email authentication policy is wrong and we should just stop. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP, was Lists "BCP" draft available
"Brett McDowell" wrote: >On May 25, 2010, at 8:43 PM, Scott Kitterman wrote: > >>> Like I said, "throw away anything that doesn't have our signature" has >>> some chance of broad adoption. Every extra word you add to the message >>> makes it less likely that people will do it. >>> >> I agree with this. I have yet to see any proposals for additions that didn't >> either add enough complexity to act as a barrier to deployment or >> alternately make it trivially possible to allow third parties to create >> messages that render discardable moot. > >I agree that adding anything to "throw away anything that doesn't have our >signature" add complexity to implementation and therefore, by definition, is a >barrier to adoption. That's not what we are debating. What we are debating >is whether such complexity is a necessary evil that we should provide a >specification to support -- as an optional mechanism for stakeholders who want >to opt-in to the authenticated email ecosystem. I *think* the answer is >"yes". But we haven't yet had the meaningful debate that will resolve that >question. > >Let's debate whether transient trust through a MLM is actionable. Would a new >header that enabled the MLM to report to the receiver that they indeed >validated the original signature actually make any difference in the >deliverability of that message to the receiver, and if yes, is that actually a >good thing? I say "yes" and "yes". But I expect that if we debate this >specific point one of you might highlight an unintended consequence that would >tip the balance away from pursuing such a model. > >Thoughts? > That's not quite the question. Such transient trust can't be spoofable. It needs to have properties such that if it asserts "trust me, it was signed by PayPal when I got it, so you can ignore their discardable flag" it can't be used by arbitrary senders to bypass PayPal's ADSP. I don't know of a way to do that which doesn't require a trust relationship with the mail list provider. If you have such a relationship then it's relatively trivial to just not bother with ADSP checks for mail from such lists. I'm left not knowing what advantage there would be from a more complex standardized approach. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP, was Lists "BCP" draft available
"John R. Levine" wrote: >> Colorful, but those were not my/our words or sentiment. >> >> Once again, our use case is: > >Maybe, I'm dim, but I don't see any practical difference between what >you're saying and what I'm saying, other than perhaps that you have a far >more optimistic idea of what people will deploy that doesn't directly >benefit them. > >Like I said, "throw away anything that doesn't have our signature" has >some chance of broad adoption. Every extra word you add to the message >makes it less likely that people will do it. > I agree with this. I have yet to see any proposals for additions that didn't either add enough complexity to act as a barrier to deployment or alternately make it trivially possible to allow third parties to create messages that render discardable moot. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] besides mailing lists...
"Dave CROCKER" wrote: > > >On 4/30/2010 9:37 AM, Jeff Macdonald wrote: >> ESPs have a "forward-to-a-friend" feature for their clients. Its a >> feature in which the ESPs creates the content and sends a message from >> a friend, to a friend. It would be discarded. However, I'm willing to >> say this is a bogus practice. > > >F2F is a well-established and helpful feature. That some uses of receive-side >authentication cannot cope with it is a limitation of the authentication-based >service, not a flaw in F2F. > If authentication has to be shoehorned into email without disturbing any existing practices then we may as quit and spend our time on something else. Scott K___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Broken signature analysis
"Michael Thomas" wrote: >On 02/24/2010 12:28 PM, Franck Martin wrote: >> I spoke recently to someone which I think will join this group soon. >> >> But basically his idea of being alerted of a broken signature was also to >> catch people who are trying to fake the DKIM signature, and see the extent >> of it. > >Faking DKIM signatures shouldn't help *anybody*. If there's any incentive to >make a fake DKIM signature by bad guys, somebody's software is horribly broken. > >> Also personally, I think the sender is more motivated to fix a broken DKIM >> signature than the receiver. > >Sure, but I think the question here is whether a huge hose of ARF reports from >potentially unknown and not very trustworthy sources is the right way to go >about >sniffing out forwarding oddities, etc. > >I guess a lot of my uncomfort here is that abuse reporting could end up being >its own abuse vector as well as something that take on a life of its own. The >potential volume of traffic could be very large versus the benefit of... what? >It seems to me that the problem space for this should be extremely constrained >to solve a minimal set of very explicit existing problems, and not feature >creep beyond that. WRT DKIM, I'm not sure what that problem set is. Well said. Much better than the reply I'd started drafting. Scott K___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM charter update proposal
On Sat, 24 Oct 2009 18:13:41 -0400 Barry Leiba wrote: >As I see it, the reasons to go to DS would be > >Y1. to progress a fairly stable standard along a defined track, and >Y2. to review it and perhaps clean it up a little along the way, and >Y3. to get broader deployment as a result of higher maturity. > >As to Y3, there's evidence, as Murray has pointed out and as many of >the rest of us are aware, that most deployment comes from publication >as PS, and from other sorts of publicity... and DS probably doesn't >create the swell of deployment that we might like. Still, as long as >the IETF considers the three-stage standards track to have value, I >think there's some value in working within it. > >The reasons not to go to DS would be > >N1. to avoid wasting our time on nominal advancement that has little >or no real value, or >N2. to avoid wasting any more time working on something that's not >very useful, or >N3. in recognition that it's not stable, and that, while it certainly >meets stated criteria for DS now, we think we're likely to change it >significantly after more experience with it. > >My opinion is that N1 is arguable, but that N2 and N3 are not the >case, and that we shouldn't resist advancing DKIM base to DS for >reasons N2 and N3. My opinion is also that, while N1 might be true, >the fact the IETF considers it worthwhile overrides that. > >And note that I'm only advocating advancement for DKIM base at this >point; I think we DO need more experience with ADSP before we have any >clue whether it's stable (or useful). I think it's a reasonable set of criteria. Where I disagree is that we have a sufficient basis to declare it stable. It has not been very long at all since we rushed a new RFC out to clarify things. What's the basis for confidence that that was it? It is my expectation that if there are any significant warts left in the basic protocol it will become apparent in large scale deployments where DKIM signature data is being used as an input to other processes (like ADSP or private reputation services). I don't see a lot of evidence that such deployments are at all common yet. If other participants have significant experience with these, I'd appreciate hearing about it. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM charter update proposal
On Fri, 23 Oct 2009 16:54:52 -0700 Dave CROCKER wrote: > > >Jim Fenton wrote: >> It's fairly easy to demonstrate interoperability of protocols, but >> usefulness is much more difficult. DKIM is an infrastructure protocol, >> designed to provide a basis for other mechanisms, such as domain-based >> reputation, to operate. Those other mechanisms are as yet nascent; how >> does one judge usefulness at this point? > > >Jim, > >This appears to be imposing criteria that go considerably beyond the IETF's >requirements for Draft. > > From the standpoing of IESG process, how is this legitimate? So is it your position that a protocol must be advanced if it meets a minimal set of criteria even in the face of engineering judgement that the protocol is not yet sufficiently deployed to have a reliable understanding of the adequacy of the current design? Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] How about that DKIM charter update proposal
On Mon, 19 Oct 2009 09:58:55 -0700 "Murray S. Kucherawy" wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- >> boun...@mipassoc.org] On Behalf Of John Levine >> Sent: Sunday, October 18, 2009 1:31 PM >> To: ietf-dkim@mipassoc.org >> Cc: barryle...@computer.org >> Subject: Re: [ietf-dkim] How about that DKIM charter update proposal >> >> Re the ADSP data collection, I'd like to add a third option to move it >> to Historic if ADSP turns out to be as useful as I think, but I >> realize this is unlikely to be a popular suggestion. > >How about "Experimental"? > Why is it more experimental now than when it was published? >From the beginning, I have not had the impression that the policy piece of the charter has not been taken very seriously. Publishing All/Discardable does take some significant effort to make sure all of an entities MTAs are reliably signing. I think it's way premature to have an opinion about if it will get used or not. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM charter update proposal
On Sun, 18 Oct 2009 11:54:47 -0400 Barry Leiba wrote: >Some have opined that it's even too early to consider taking the base >DKIM protocol to Draft Standard; let's make sure we have consensus on >that point, one way or the other. > I'm going to re-iterate my point for this perspective. We do not yet have a broad experience base with deployment of DKIM by large, heterogeneous organizations. This is a hard problem for them because they first have to get their outbound mail architecture under control. My view is that these types of deployments are the ones that will teach us the most about the protocol and we are at least a year and maybe two or three from getting significant experience/feedback to support progressing DKIM along the standards track. The methaphorical ink is barely dry from our last update (which was eith much ado about nothing or a correction of a serious problem, I'm not quite sure which). Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Resigner Support of RFC 5617 (ADSP)
On Mon, 12 Oct 2009 13:45:21 +1200 (FJT) Franck Martin wrote: > >- "Scott Kitterman" wrote: > >> >> Except that the ADSP RFC is already published and so it is what it is. >> It is definitely >> premature to crack ADSP open again (of course I thought that about >> DKIM too). >> >But as ADSP states, that the problem of 3rd party signing is not covered, and it seems the issue of mailing lists, then an addendum can be done. > The rough consensus of the group resulted in the ADSP we have now. These issues were discussed before and until there's some reason to believe the rough consensus has shifted, I think it's not the best use of my time. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Resigner Support of RFC 5617 (ADSP)
On Sun, 11 Oct 2009 15:26:52 -0700 (PDT) Michael Deutschmann wrote: >On Sun, 11 Oct 2009, Michael Thomas wrote: >> On 10/11/2009 02:41 AM, Michael Deutschmann wrote: >> > If this is indeed the official semantics of the protocol, then I would >> > petition to add a "dkim=except-mlist" policy. Which means "I sign >> > everything that leaves my bailiwick, but may post to signature-breaking >> > MLs." >> >> No need. That is exactly what the semantics of "all" is. >That appears to be a contentious issue. > >While I don't think the Hector/Levine interpretation is very useful, I >think it would be a sound strategic move to yield to them regarding >dkim=all, and instead create our own dkim=except-mlist space where our >semantics are in place with *no ambiguity*. Except that the ADSP RFC is already published and so it is what it is. It is definitely premature to crack ADSP open again (of course I thought that about DKIM too). Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM charter update proposal
If advancing DKIM/ADSP along the standards heirarchy is all that's on the table, I think it should wait. Effective rollout of DKIM in large hetrgenous organizations is complex and takes time. I think it's better to pause for a while and give broad operational experience more of a chance to exercise what has just been standardized. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM adoption
On Sat, 1 Aug 2009 12:51:01 +1200 (FJT) Franck Martin wrote: >Yes the reputation of the domain override things, but what happens when it is the first time a domain is seen? Does DKIM help or not? > It can't. >Also, I'm thinking in terms of points like for spammassin. Seeing some patterns in the email increase or lower the points. > > Some of the people involved early in the SPF project had the same idea. It did encourage spaammer to adopt it, but it also had a big backlash after people noticed spammers could publish SPF record just fine and the positive points were just helping spammers. I don't suggest a repeat. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Escaping things in key/ADSP records
On Fri, 31 Jul 2009 10:19:43 -0400 Tony Hansen wrote: >I'm wondering if there is a need for a web interface at dkim.org that >would validate someone's _domainkey TXT record. > I'd say yes. It would provide a good way to isolate record specific issues from other potential problems people are having error sources when troubleshooting. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
