Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
On 09Feb18, John R. Levine allegedly wrote: > RFC 822 may not have versions but 821/2821/5321 sure do. > > As soon as 2821 added EHLO, SMTP got service extensions and pretty > much by their nature, those extensions are not backward compatible. > > Well-known examples are 8BITMIME and SMTPUTF8. If you have a message that > needs > one of those and the server you're trying to send it to doesn't support the > extension, you lose, the message bounces. I'm not sure whether this an argument for or against versioning. Or an argument that sometimes bad engineering choices are made regardless of the upgrade mechanism. In any event, 822 is an existence-proof that decades-long upgrades are entirely possible without the scorched-earth approach of versioning. I hope it would take a very strong argument to suggest that we shouldn't (or can't) follow the 822 strategy. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
On 08Feb18, Michael Thomas allegedly wrote: > I dunno, it's not like there isn't precedent for this. oh say, like ipv4 > vs. ipv6? Oh I dunno. The precedent of RFC822 - the very standard we rely on - has survived numerous upgraded and enhancements over a 36 year period and managed to do just fine without a version. I might add that RFC822 seems to have adapted a lot better than the v4 vs v6 crowd. Not sure you picked the best example of success there, Michael :-) > Besides if you wanted to go from DKIM to EKIM, you'd be opening > pandora's box imo. Indeed. As mentioned previously MIME-Version: 1.0 has set the standard for us to emulate. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
> True, but not very interesting. In my spamassassin example, the outside > code knows nothing about DKIM versions, it just sees a dkim-signature > header and sends it to the DKIM library. > > The point of a v=2 flag is to ensure that old v=1 code doesn't As a practical matter haven't you effectively invented a new header? After all, what are most senders going to do? They will not want their signatures to be suddenly unrecognized by 99% of the planet so they'll continue to generate a v=1 header and they will also want to reap the bennies of your fantastic SpamAssassin feature so they'll additionally generate a v=2 header. The end result is two DKIM-Signature headers with different versions for decades to come. This will no doubt tweak some receiver is a negative way. I think this is the biggest flaw with the whole v= rationale. There is never going to be a v=2 change that doesn't leave everyone continuing to generate/validate a v=1 header. Is a new header by stealth better engineering than formalizing a new header? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
On 08Feb18, John R. Levine allegedly wrote: > On Thu, 8 Feb 2018, Mark Delany wrote: > > Heh. I'm still waiting to hear a good reason as to why "v=" exists at all - > > apart > > from exposing brittle parsers which mistakenly expect it to show up as the > > first > > tag. > > I had a draft that invented v=2, for headers with a tag syntax that is not > quite backward compatible with the current spec. I realize that we could > change the header to DKIM-Improved-Signature but the change was small and > it smelled to me like the same header. Yes, one can certainly contrive a situation in which they prefer a v=2 solution, but as you say, the requirement can be just as easily satisfied in a number of other ways too. A new header is one as is the presence of a new tag and v= is a third. There are other ways as well. Given we're talking about standards, it's de rigueur that we end up with at least three competing ways of achieving the same outcome without any guidance whatsoever as to which mechanism to choose when and why. Underlying all this of course is the assumption that programmers intuit the possibility of change inherent in these non-essential mechanisms and code and test accordingly. Now that's a goodun. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Where is the formal definition of DKIM-Signature?
> "v=1" doesn't have to come first. It just usually does. I think there was > a version of RFC4871 that did that, but then when challenged we couldn't > come up with a good reason to keep it that way. Heh. I'm still waiting to hear a good reason as to why "v=" exists at all - apart from exposing brittle parsers which mistakenly expect it to show up as the first tag. It's about as likely to change as "MIME-Version: 1.0", which is to say, never. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Fwd: SendGrid, GetResponse and Hubspot being used over DKIM "patent"
On 06Dec17, Suresh Ramasubramanian allegedly wrote: > The pledge idea isn???t terribly novel either > > Anne Mitchell used a habeas haiku Gosh. The Haiku. How could I have possibly forgotten that beauty! But, if you really want to intimidate spammers with poetry I recommend the very effective Haka instead. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Fwd: SendGrid, GetResponse and Hubspot being used over DKIM "patent"
On 05Dec17, Steve Atkins allegedly wrote: > > I thought this might be of interest to DKIM implementers. > The Asserted Patents share a common specification. Did the claimants vacuum up the IP of the now defunct Goodmail? Reads somewhat similar to what they were once trying to sell. Particularly the "contractual" obligations of the senders. From what I can glean, the plan is to digitally sign the email along the lines of S/MIME (PKI and CAs are referred to extensively and exclusively) and the sender include a "pledge" about the contents such as "no more than 5 recipients will get this email". Recipients can act on the pledge in the knowledge that senders apparently won't lie in their pledge. Or if they do lie something will happen to them - exactly what or how is not specified. How the pledge is validated across the whole of Internet email is undefined as is what to do to the sender if the pledge is known to be a lie. There are no references to DNS, no reference to how they determine identical mail (canonicalization), no reference to S/MIME or DKIM in any of their filings. I guess the "pledge" on the part of the sender is vaguely novel but there is no equivalent in DKIM as far as I recall. Maybe the vendors you refer to have features that emulates pledges when sending email? For moral equivalence, the Date: header is a pledge as to when the email was composed/sent and Content-Type: is a pledge as to how the MIME part has been encoded so the novelty is not even that there are pledges in the email, just the nature of the pledge. To me they seem to have invented a new mail header. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-kucherawy-dmarc-rcpts
Hi Murray. > RFC6376 and even RFC4871, but now it's apparently happening I'd be interested to hear about the actual scenarios. Are the targeted users somehow given an indication that the email verifies and it's from a credible domain and yet it contains a malevolent payload? This sounds like some sort of quarantine system which only looks at verification status. It's too bad formal communication to the MUA was eliminated in DKIM. The original hope was that after a decade or so, MUAs would have evolved to participate and make some rendering indication in such situations. After all, an unknown-to-the-MUA to:/cc: recipient or domain in a verified email is highly actionable. Anyway, based on your draft I presume the desire is still to retain the binary verification status as a strong dispositional attribute that is handled by anything *but* the MUA? In the section that discusses the impact on forwarded and list email you might want to highlight that the proposal could further reduce email to a point-to-point protocol. In which case an alternative long-term strategy might be simply to insist on strong SPF checks rather than signatures. Or do SPF checks not help the scenario you're addressing here? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] need for clarification
On 27Jan15, A. Schulze allegedly wrote: > > Hello everybody, > > Murray encourage me to ask here: > > https://tools.ietf.org/html/rfc6376#section-3.3.3 say > "Signers MUST use RSA keys of at least 1024 bits for long-lived keys." > > and > "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." > > Signer using a key larger then 2048 (like I do for years now) aren't > inside the specification > because there is no MUST on the validation side. > From operational perspective I experience no drawback using 4k RSA > keys for DKIM. > > I see these options: > - the signer could use smaller keys and rotate them more often > - the specification support other key types which gather same level > of security with smaller keys > ( elliptic curve crypto ) > - the specification REQUIRE validators to handle larger keys. > > I would kindly ask for other options or advise. On the matter of smallish keys, it was originally stressed that validation should only occur at the time of delivery rather than many years later, so the notion of smaller keys being vulnerable to future technology is less of a risk. So from the perspective, shorter keys are not as terrible. But others will disagree. On the matter of EC and larger keys, both of those are valid suggestions in 2015, however not so much in 2004 when many of these original decisions were made. At that time: o there was limited support for EDNS0 - even today it's not 100% o (as I recall) openssl exhibited erratic behavior with 2048 < keys < 4096. This made me pretty nervous about the true level of support for large keys in general. o EC was nascent in 2004 - I don't recall whether there was much if any s/w that supported it. I don't recall how much re-evaluation of those limits was done in later incarnations of the specs. EC at least is probably worth as it reduces DNS payload sizes. Of course introducing larger keys and/or a new algorithm is within the protocol but will be quite a challenge due to the installed base. I also note that we original had the notion of the verifier having to choose the signature with the "most secure signing algorithm", so in theory you could create signatures with RSA and EC, but that notion was lost/dropped in later iterations of the specs. Perhaps it should be revivified? Mark. pgpFr4Or7E7QD.pgp Description: PGP signature ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] [Technical Errata Reported] RFC6376 (3758)
> I admit that I also got confused a few times while working on the DKIM > documents and keeping it straight as to which section was referring to > which set of arguments. Having them use different values and different > tags for items that were conceptually the same was an unfortunate aspect > aspect of the history behind DKIM. Indded. And the inverse. That the same tag had different syntax or semantics depending on location. Originally there was a unified tag-space to avoid these risks. That was easy back then as there was only 11 tags that covered policy, keys and signature thus little risk of tag-space depletion even with single character tags. Perhaps ironically, around the time tag-space was dimensionally expanded with versioning and multi-character tags, the principles underlying the unified tag-space disappeared. Anyway, as others have suggested, one solution is to put a tag-space hierarchy into the spec or... Alternatively, if you're a believer in versioning you could simply bump the versions and re-assign tags. This way you get to feed two birds with one cracker. Prove that versioning is useful and consign this tag-space fuzziness to history! Just kidding. Seems like Barry's later diagnosis is accurate thus if any clarification is needed at all it can be bundled with other errata. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Doublefrom, ADSP and mailing lists in perspective,
> > DKIM should be viewed as a Work-In-Progress still missing a viable > > policy layer. > > +1. But 5+ years WIP? :) It wasn't rocket science. Well, 7+ years ago it was suggested that "Domain policy is nascent" with the stated expectation that MARID would soon develop something comprehensive to satisfy our needs... Apropos rocket science, at our current rate of progress we risk outliving the Space Shuttle program. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities
On 22Jul11, O'Reirdan, Michael allegedly wrote: > Chaps > > I would like to bring to your attention and solicit comments on the following > draft. > > http://tools.ietf.org/html//draft-oreirdan-rosenwald-ipv6mail-transition-00 Hi Mike. On first glance it doesn't look like much of this document is relevant to DKIM or vice versa. This is unsurprising since DKIM has little to do with IP addresses. On a non-DKIM related front, your document talks about "connection exhaustion" as a consequence of the increased address space with IPV6. I would have thought the maximum number of connections is a function of the number of clients (malicious or otherwise) rather than the address space they use. Are you anticipating a larger number of new SMTP clients as a consequence of IPV6? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: (DKIM And Mailing Lists) to BCP
On 16May11, J.D. Falk allegedly wrote: > On May 15, 2011, at 9:42 PM, Barry Leiba wrote: > > >> The author can be a human using an MUA (Mail User Agent) or > >> an automated mail robot with an MTA. > > > > I don't see that "automated mail robot with an MTA" is right at all. > > But I see what you're getting at, and I'd support a change such as > > this: > > > > The author can be a human using an MUA (Mail User Agent) or > > an automated process that may send mail (for example, the "cron" > > Unix system utility). > > +1 I've got a few of these left so I may as well use 'em while I have 'em. +1. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
> Content-type: text/plain; charset=us-ascii (Plain text) > > Content-type: text/plain; charset="us-ascii" > > are completely equivalent DKIM has never tried to understand the semantics or syntax of each header. First off, doing this properly is very hard as there are a large number of "equivalent" header variations, but second off, it would make DKIM brittle against future headers that might have the same characteristics you describe. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
On 16May11, Alessandro Vesely allegedly wrote: > On 16/May/11 15:41, John R. Levine wrote: > >> http://www.opendkim.org/stats/report.html#hdr_canon says > >> > >> Header canonicalization use: > >> canonicalization count domains passed > >> simple 6536886786591938 > >> relaxed 3940377 56621 3640854 > >> > >> Although they only differ by 2% (90% simple vs 92% relaxed), such > >> percentages would be superb for tools like Spamassassin. I'd expect > >> at least 99% from a cryptographic tool. > > > > This tells me that the benefit from relaxed is at most pretty small. > > OTOH, comparing the "count" fields of those two lines, 86% relaxed vs > 14% simple, says that such kind of benefit is really really wanted. But that's a perceived benefit, not an actual one. Folk think they need "relaxed" to significantly increase survivability but that's not the case given the stats above. So yo may be right that folk really really want it, but they don't really really need it. Mark. ___ 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)
> specification. For this reason, I am formally proposing that the i= tag > and supporting text be removed from 4871bis. Gosh Jim, you're probably not surprised when I say +1 to that :-) While the i=/g= were attempting to solve problems, I agree that the spec has moved on and simplifying to just d= has considerable crispness. As for the other follow-up, I am not aware of Yahoo using i= as a discriminator. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] If DKIM would ignore [] at the beginning of the subject line
On 31Mar11, Franck Martin allegedly wrote: > Silly question (?): > > Knowing that many mailing lists add [topic] at the beginning of the Subject > line, what if DKIM was set to ignore that part when signing/verifying? > > Would it help to solve the problem of broken signature thru mailing lists? In part. What you are doing is indirectly addressing mailing list canonicalization. If I may be so bold, I think the Cisco innovation of l= does much the same for another aspect of list mail. But maybe this piecemeal/generalized approach to mailing lists is not the right way? For example, is l= really useful outside of lists? Is your [] solution useful outside of lists? Instead, what if we invented a canonicalization specifically for lists that recognized the content munging of lists as first-class behavior that encompassed things like l= and [] and other typical list munging? If your "Silly question" suggests a list canonicalization, then, IMO, it's a pretty interesting idea. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Security Area Directors
> As you see, Sean has kept DKIM. Stephen will be up there with me on > the Monday in Prague, for his last meeting as working group chair; Gosh. And it only seemed like yesterday ... or was it the day before yesterday ... that Stephen came on board as a chair. Many thanks to Stephen for doing a sterling job. I'm sure the success of this WG is largely due to having competent, caring and persistent chairs who have pulled us back from many a rat-hole and dead-end to maintain our focus on delivering the end-product. Much appreciated. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ECC (was RE: DKIM using old RSA padding?)
On 28Feb11, Murray S. Kucherawy allegedly wrote: > > -Original Message- > > From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] > > Sent: Monday, February 28, 2011 10:35 AM > > To: Murray S. Kucherawy > > Cc: Michael Thomas; Hanno B?ck; ietf-dkim@mipassoc.org > > Subject: Re: [ietf-dkim] ECC (was RE: DKIM using old RSA padding?) > > > > The time to switch for DKIM is likely to be when you no longer > > want to sign with an RSA key that fits a DNS response nicely. > > Not sure off the top of my head what exactly that would be in > > terms of RSA modulus size. > > Based on the work I did on resolver truncation handling, I believe that's > 2048-bit RSA keys, but I don't recall exactly at the moment because it was a > while ago. In theory EDNS0 will give us plenty of extra payload to play with. Mark. ___ 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 11Jan11, Eliot Lear allegedly wrote: > Barry, Dave, and others, > The innovation of DKIM is not any one of these things, but rather the > combination. The test question for me here, for instance, is whether we > can standardize the processing of the signature in DNS as separate from > how the signature is made. Extending Eliot's point, does the split make the individual docs potentially beholden to multiple masters? The Chairs suggest "no", but won't the split encourage DOSETA participation (and possibly others) who necessarily have different perspectives and goals? I also agree with the comment that DKIM probably had an easier time getting to this stage because it focuses solely on email. Our assurances that this was *just* for a particular security application with fairly modest goals rings a little hollow if we are now saying that DKIM is to become a general framework. Do folk think we have enough deployment experience to say that those assurances are obsolete? >From a personal perspective, getting closure on DKIM is tantalizingly close. Those with WG-fatigue probably feel that this proposal risks moving that achievement further into the future with no appreciable gain to DKIM. Perhaps that's a selfish POV, but the doc split does have a whiff of second-system syndrome which worries me when we're still applying the finishing touches to the first system. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Are arbitrary From addresses in the physical world following DKIM?
Forgive me for a bit of an aside, sortof. A lot of people have long used the Postal Service analogy of being able to supply an arbitrary return address as a justification for doing the same in email (DC I'm looking at you, buddy). So did anyone catch the news today that UPS.com are planning to verify the return address of a package against your drivers license? And that other "postal" services may soon follow suit? In other words, the days of providing an unauthenticated "author address" may be numbered in the physical world. It's all in the name of security theater of course, but nonetheless, somewhat amusing in the DKIM context. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] SPF/DKIM complementary failure scenarios?
On Wed, Nov 24, 2010 at 10:57:58AM -0800, Douglas Otis allegedly wrote: > On 11/24/10 9:01 AM, Dave CROCKER wrote: > > > > On 11/23/2010 3:14 AM, Ian Eiloart wrote: > > > Actually, they're complementary. In places where DKIM fails > > > (mailing lists rewriting messages), SPF can succeed. And in places > > > where SPF fails (message forwarding), DKIM can succeed. > > > > This assertion of facts is almost certainly incorrect. > > > > Please specify the details of the scenarios in which you claim these > > assertions are correct. > > +1 -10 Please don't. It's out of scope for this group. Mark. ___ 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 Sat, Nov 20, 2010 at 11:49:36AM +0900, Tsuneki Ohnishi allegedly wrote: > > Hi to all, > > I am Tsuneki Ohnishi and I would like to let you know > that DKIM Japan(dkim.jp) has just been set up as of > Nov 15, 2010. Welcome, Tsuneki, glad to have you join. It's great news to hear of such commitment. Who knows? Maybe .jp will be the first ccTLD to get comprehensive DKIM coverage. Wouldn't that be something! Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
> The universe of email is replete with software that forgives > messages which do not conform strictly to the grammar that defines > what valid email looks like. This is a long-standing practice known > informally as the robustness principle, originally coined by Jon > Postel: "Be conservative in what you do, be liberal in what you > accept from others." Well, I'm clearly the outlier here, but I think "be liberal" is protocol nonsense that has been accepted as "conventional wisdom" for far too long now. Put another way, "Accept crud and pass it on" constitutes good protocol design? Gimme a break. More particularly, DKIM is a security protocol which means that "being liberal" is entirely antithetical and highly risky to boot. In short, I don't think any part of DKIM should be based on "be liberal" because it always trades off security. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Focusing on 4871bis
> > Those are two different changes. My own sense is that each has some > > controversy, with the first being pretty substantial and with the first > > having > > some significant counter-proposals. > > My preference is still that verifiers reject messages that are likely to > display misleadingly in MUAs, e.g., multiple copies of headers that MUAs > render one of. This is a rathole if you consider all the junk a bad guy > can do in HTML body parts, but at if you insist that the entire body is > signed, you can at least say that the garbage the user sees is same > garbage that was signed. That matches my position - such messages should not verify. Though I would generalize the "display and MUA" part to "not verify messages that could mislead subsequence consumers" (where a program is a consumer too!) I agree that there is a distinct difference between goop that is part of the signed message and goop that is not. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] double header reality check
On Wed, Oct 20, 2010 at 09:38:04PM -0700, Murray S. Kucherawy allegedly wrote: > > -Original Message- > > From: John R. Levine [mailto:jo...@iecc.com] > > Sent: Wednesday, October 20, 2010 5:08 PM > > To: Murray S. Kucherawy > > Cc: ietf-dkim@mipassoc.org > > Subject: Re: [ietf-dkim] double header reality check > > > > > 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? > > > > The latter. Hey, we agree. I think I always said SHOULD rather than > > MUST. > > Damn, lost it. I think we should talk about it, and even in detail, > but without using those words. > And I'd be fine converting the MUA advice to which you refer into > something more general, like hammering home the point about what > exactly a validated signature is telling you, and leave it to the > implementers of those modules to figure out what to do with that > information. It's stating the obvious by now, but I'm with (a). While it might be technically elegant to delegate (a) to another layer or some "magic sauce", or some informative text, it misses the bigger picture. That bigger picture is that DKIM has no certainty of success simply by being a technically neat and layer-compliant protocol. DKIM will succeed only if it is picked up and used by a vibrant and wide-spread community of DKIM consumers - MUAs, list servers, reputation systems, email appliances, whatever. Given the well-recognized inertia in the email biz, to maximize our chance of success, we need to make it as easy as possible for this new community of DKIM consumers to succeed. To my mind that means that those consumers can write no-brainer code and reap the benefits of DKIM. So, every time we relegate or delegate parts of DKIM compliance to those consumers - perhaps by way of informative text about 2822 compliance - we are simply creating barriers for the very consumers that we need to make DKIM a success. Are we so confident about DKIM adoption that we feel we can effectively "order" this future community to do this sort of work? I for one am not. I for one think that if we make DKIM as easy as possible to consume and we market the heck out of it, we may, we just may succeed in wide-spread adoption, maybe. So, forget technical elegance. Forget layering violations. What are we doing that makes DKIM compelling and easy to consume? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] double header reality check
On Wed, Oct 20, 2010 at 01:41:03AM -0700, SM allegedly wrote: > At 17:53 19-10-10, Mark Delany wrote: > >In a DKIM world a list server could reasonable use DKIM to bypass this > >"confirm" sequence and make your life a bit simpler. Perhaps it relies > >on Authentication-Results or somesuch. In any event such a list server > >is actually *more* vulnerable than it is today if we let thru bogus > >payload that appear to be valid. > > According to Section 7 of RFC 5672: > >"For DKIM processing, the domain name portion of the AUID has > only basic domain name semantics; any possible owner-specific > semantics are outside the scope of DKIM." > > Furthermore, in Section 8: > >"A module that consumes DKIM's mandatory payload, which is the > responsible Signing Domain Identifier (SDID). The module is > dedicated to the assessment of the delivered identifier. Other > DKIM (and non-DKIM) values can also be delivered to this module as > well as to a more general message evaluation filtering engine. > However, this additional activity is outside the scope of the DKIM > signature specification." > > Based on the above, I don't think that a list server could use DKIM > to bypass the "confirm" sequence. Well, that's "should". It also assumes that all subsequent users of DKIM bother to read and obey. It also assumes that future users of DKIM won't get inventive and use DKIM in ways that we can't even imagine. I think that undersells DKIM and future users. Just ask the inventors of DNS whether they thought we'd be using it the way we are... or whether we're using it the way they intended. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] double header reality check
> Any filter or agent that makes any kind of filtering, routing or > sorting decision based on any header field which in turn presumes > there's only one such field without actually checking is a potential > security concern. I think this is a subtely different problem though. All of the examples you cite (and all other pre-DKIM examples for that matter) are foolable with a single forged header today. That they could be further fooled with multiple headers is not an issue. In a future world where such tools (and UAs) could act with authority because DKIM has assured the headers/payload is where we have the problem. Only once tools and UAs take advantage of DKIM, do these attacks become relevant. That's why I think this is a DKIM problem. We are wanting tools and UAs to take advantage of DKIM but by doing so they are possibly making themselves more vulnerable to attackers. A simple (but hyperthetical) example. If you unsubscribe from a list today, most list servers typically confirm the request by emailing you back with some nonce to ensure the unsubscribe request isn't forged. You then hit reply or click on the link to confirm you have access to that mailbox, etc. In a DKIM world a list server could reasonable use DKIM to bypass this "confirm" sequence and make your life a bit simpler. Perhaps it relies on Authentication-Results or somesuch. In any event such a list server is actually *more* vulnerable than it is today if we let thru bogus payload that appear to be valid. IOW. Asking them to rely on DKIM is a backward step. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] How MUAs render mail
> result of software layers that render those bits. DKIM has no > control over that rendering process. Really? Do you mean doesn't or shouldn't or can't? Apropos layering violations: are we saying that having a UA inject message 'A' via a DKIM layer into the mail stream, and then having some random/malicious goop cause message 'B' to pop out of the DKIM rabbit hole at the other end is less of a layer violation than ensuring that message 'A' comes out that rabbit hole? That seems odd. Even if layer-violation is viewed by some as an immutable law, there is some argument that allow the 'B' rabbit to pop out is failing that law. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Mon, Oct 18, 2010 at 06:07:15AM -0700, Dave CROCKER allegedly wrote: > > > On 10/18/2010 3:31 AM, Ian Eiloart wrote: > > --On 15 October 2010 11:53:51 -0400 Dave CROCKER wrote: > >> On 10/15/2010 11:40 AM, Mark Delany wrote: > >>> Well, if you want to introduce semantic changes why not just change > >>> the meaning of h=from:to: to be semantically identical to > >>> h=from:from:to:to: > >> > >> This would mean that it is /never/ ok to add a listed header field after > >> signing. Adding would /always/ break the signature. > > > > I assumed that the proposal applied only to headers rfc5322 says cannot be > > duplicated. > > That is a constraint that was not stated. It is now. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
> Don't think of DKIM as being inviolate offering only a disjointed > sacrosanct identifier. DKIM process must also guard against the > exploitation of its results +1 By DKIM process, I would include anything cognizant of DKIM upto but not including the MUA. Mike's secret sauce would count here, eg. I for one would have dumb sauce. Perhap prefixing unsigned headers with "DKIM-hidden-" such that only DKIM aware MUAs will render original unsigned content. As others have said, there is nothing between DKIM and the MUA that prevent DKIM exploitation so who is going to solve that problem if not us? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
On Sat, Oct 16, 2010 at 12:10:48AM -0400, Dave CROCKER allegedly wrote: > > > On 10/15/2010 8:32 PM, Mark Delany wrote: > > Therefore one could > > argue that DKIM is "protecting" that relationship between the message > > and identifier. > > Clever phrasing. Might be too subtle for general use, but I think it offers > a > perspective that could be useful. > > I think the issue here is that when people talk about protecting a message, > they > tend to have in mind all sorts of attacks designed to trick users. DKIM > actually does not have much to say about such things. > > 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. I have a problem with this approach and I don't pretend to know the right answer. My problem is that if some valuable domain like paypal sends me a bunch of bits that I or my MUA or my MTA ties to paypal.com then the end goal of DKIM is, IMO, that those bunch of bits I "see" are the ones that paypal sent. No more, no less. To murder another idiom: "What you see is what they sent" is I believe the ultimate goal of DKIM. Or, "what you complain about is what they sent". Whatever. So anything that circumvents "what you see is what they sent" I think is in scope for DKIM to eliminate or mitigate. Is that requirement solved in the verification protocol of DKIM or is that solved in advice to MTAs/MUAs? I don't know. But I am sure that if we don't end up with that guarantee, then I do wonder what we are offering. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM and patents
On Sat, Oct 16, 2010 at 02:54:13PM +1200, Franck Martin allegedly wrote: > I found today this patent: > > US PATENT 7487217 > http://www.docstoc.com/docs/57449330/Network-Domain-Reputation-based-Spam-Filtering---Patent-7487217 > > but then it seems prior art existed in the form of DKIM (which was started > around 2004 http://news.domainmonster.com/dkim-email/) DKIM largely derives from DomainKeys which largely derives from US Patent 6,986,049 filed in Sep 2003. In 2004 the IPR was bequeathed to the IETF by the Assignee (aka my employer at the time). See: https://datatracker.ietf.org/ipr/693/ and http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=9&f=G&l=50&co1=AND&d=PTXT&s1=delany.INNM.&OS=IN/delany&RS=IN/delany Given the timing, clearly the 2005 filing of 7,487,217 you mention cannot encroach on the prior filings of DomainKeys. If anything it's around the other way as 6,986,049 could invalidate 7,487,217. But, IANAL and I never want to be one. I am just stating known facts here. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
> 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. > 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: (I don't know what "inapposite" is, but I like it!) To your point, the identifier and the message must go together to be meaningful. One without the other is meaningless. Therefore one could argue that DKIM is "protecting" that relationship between the message and identifier. Or put another way, if a DKIM signer is taking responsibility for the message, then DKIM should also protect the original assertion of the signer - which again includes the message as well as the identifier. I don't think you can disconnect the two and retain value. Maybe that's what folk mean when they say "protect the body"? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 2 Day Collection Stats
> Breaking that down further: Of the 8,219, 6,614 (80.4%) were author domain > signatures, so the rest were presumably list signatures (or something else). > > 57 of them failed even in the presence of an "l=" tag. More work for Murray. Distribution of the l= values? Particularly l=0 Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
> > h=from:from:subject:subject:to:to:cc:cc:mime-version:mime-version:list-id:list-id? > > Yes, it does. The only question is to devise normative statements > correctly, e.g. MUST duplicate "From", SHOULD duplicate the rest. > > This is _not_ a kludge. It is how DKIM signing works (Section 5.4). > > Are we worried about wasting 100~200 bytes per signature? (I get ~4Kb > headers nowadays, so that is about 3% of it.) Introducing an > abbreviation --e.g. an h2 tag-- is considerably clearer from an > algorithm developer's POV. Well, if you want to introduce semantic changes why not just change the meaning of h=from:to: to be semantically identical to h=from:from:to:to: Old verifiers still work as well as they do today, new verifiers work better and virtually all existing signers still work (excepting those that sign a subset of legitimately repeating headers - which must be rare). In either cases, the implementation changes are about the same, but the spec is simpler. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Thu, Oct 14, 2010 at 08:01:17PM +0200, Alessandro Vesely allegedly wrote: > On 13/Oct/10 20:45, Scott Kitterman wrote: > > On Wednesday, October 13, 2010 12:54:23 pm Murray S. Kucherawy wrote: > >> If we can extract DKIM from the equation entirely and the problem remains, > >> how is it a DKIM problem? > > > > If the DKIM signature doesn't verify after signed headers have been altered, > > then it's not. > > Correct. And the way that it fails to verify is h=from:from. Which strikes me as an ugly hack. Given that most headers should only occur once and given that a lot of signers sign most headers doesn't this suggestion degenerate to h=from:from:subject:subject:to:to:cc:cc:mime-version:mime-version:list-id:list-id? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
On Thu, Oct 14, 2010 at 07:38:13AM -0700, Mark Delany allegedly wrote: > > What is essential is that it perform the task of validating and delivering > > a > > signing domain that is associated with a collection of bits. Anything that > > defines how to do this is essential. Anything that can make this break > > needs to > > be covered, especially if there are ways to protect against the breakage. > > But isn't the problem that the signing domain is being incorrectly > associated with a different collection of bits? And just to elaborate on my own point. We went thru a lot of hand-wringing over canonicalization and the l= tag and so forth precisely because we were concerned about associating a signing domain with the wrong bits. But now it seems that making the wrong association is not treated with as much concern. If it is true that the DKIM effort is about associating an identifier with a collection of bits, it equally must be true that we want to make a similar effort to ensure that identifier is not associated with an unrelated collection of bits. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
> What is essential is that it perform the task of validating and delivering a > signing domain that is associated with a collection of bits. Anything that > defines how to do this is essential. Anything that can make this break needs > to > be covered, especially if there are ways to protect against the breakage. But isn't the problem that the signing domain is being incorrectly associated with a different collection of bits? Mark. ___ 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
> to: > > title="Introduction"> > > DomainKeys Identified Mail (DKIM) permits a person, role, or > organization to claim some responsibility for a message by > associating a domain name target="RFC1034" /> with the message. This can be an author's > organization, an operational relay or one of their agents. > ... Well, just to create a bit more of a rat-hole, is there any chance you'd like to add a definitional link for the word "message" as well? It seems to me that much of our other discussion swims around that meaning. Is it what is sent, is it what's signed, is it what shows up in the MUA... Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
> > In that light, taking an additional step wrt duplicate headers (or > > malformed 2822 in general) is still in the same layer as the verifier. > > My objection isn't so much layering within the software, because I know that > gets mushy real quick, but layering among the protocol specifications. For > example, we wouldn't include in an SMTP specification some text about dealing > with fuzzy TCP implementations, and what people are talking about here makes > just as much sense to me. The problem is that I don't think we are really just talking about getting a protocol right from a bits perspective. If DKIM has any value it's that it ultimately affects the user mail experience for the better. Consequently, to remain silent on matters that we know will adversely affect that experience seems contradictory. Similarly to not offer guidance to implementors on the sorts of things they can do to maximize the value of DKIM seems similarly to miss the point. Furthermore, DKIM specifically came into existence to deal with an adversarial environment whereas 821/822 and the like have very specific "just get the bits right" goals. So guiding verifiers to assume the worst seems consistent with our intent or at least our genesis. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Wed, Oct 13, 2010 at 04:09:34PM -0400, MH Michael Hammer (5304) allegedly wrote: > Having said that, if an MUA is going to present an indication of > "DKIM PASS" to the enduser, then a reasonable person would expect > some relationship between what is "passed" and what is presented to > the enduser. That makes sense. And at least one MUA already renders DKIM verified mail differently. I would think such an MUA could take the additional step of rendering verified payload differently too. I know we're not in the MUA business, but if DKIM makes no difference to what an end-user finally sees, then it serves a very limited purpose indeed. > I understand the issues raised by Murray about the slippery > slope. On the other hand, I would rather see an MUA present nothing > about DKIM than give a false impression to endusers. I can understand the engineering nervousness over crossing layers, but that seems to me to be conflating the SMTP aspects of an MTA with the DKIM aspects of an MTA/verifier. It strikes me that a DKIM verifier is already well into the business of 2822 semantics as it knows about headers, header labels, continuation syntax, header/body boundaries and so on. In that light, taking an additional step wrt duplicate headers (or malformed 2822 in general) is still in the same layer as the verifier. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
> I'm scratching my head to see if there is any advice we can offer to make > signing and verification more robust while not changing the behavior of > existing code for normal (for some definition of normal messages). > > A) You have to sign either all occurences of a header or none of them, and > a message with some but not all occurences signed fails verification. This > is probably too strong, although I doubt that there are many places in > practice where it would matter. > > B) Same as A, but limited to an enumerated set of headers that are > supposed to occur only once. > > c) Same as B, but tell signers to use the h= trick to make verification > fail if extra headers show up. Realistically useful advice probably has to influence rendering of messages. That might mean MUA participation or it might mean mailstore participation that removes all (typically) rendered headers that are unsigned. That raise a pre-cursor question as to whether DKIM is intended to offer rendered-to-user value? If not, then this whole discussion is moot. If so, then that implies greater participation from the rendering process. Mark. ___ 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
> I don't think that's a fair characterization. It is simply wrong to try to > deal this problem in DKIM. For example, a bug in the TCP stack that causes > malformed data to arrive in an application which in turn causes something > visible and unexpected, possibly even something dangerous, to happen in that > application is still a bug in the TCP stack and saying so puts the > responsibility for resolving the problem where it belongs. Yeahbut. Isn't that conflating detection with fixing? Lots of protocols have end-to-end or layer-to-layer verification to detect intervening bugs. You also well know that treating all external input with the greatest suspicion *almost* goes without saying in any programming endeavour, but particularly so in this one. I agree that a full 2822 parser is over the top and something that is unlikely to exist near verification code, but we do need to instruct verifiers to be suspicious and untrusting. What's the middle ground? Serendipitously, my early implementation refused to verify an email that had a From: prior to the signature header. The general problem is that applying authentication results to the whole payload is wrong. I don't argue this, but one could consider removing or denaturing all payload outside of the signature... Mark. ___ 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
> > That this is not in 4871 seems to be mostly a WG assumption that > > should be made explicit. > > I think several of us thought it was in there, but on review it apparently > was indeed lost somewhere along the way. We've certainly, as I understand > it, been proceeding from that assumption for a very long time. > > I like the idea of saying so explicitly in 4871bis, and applying it both to > signers and to verifiers. Agreed. Though frankly I couldn't care less about signers. It's always the verifier that really counts. > I don't like the idea of being any more specific than that. That > is, I don't want to create specific text for specific cases we know > about because that means anything we don't list could be perceived > as less critical. A blanket admonishment to implementers is > sufficient and appropriate. Right. We could attempt to enumerate the 1,000 edge-cases we know today and then re-bis 4871 for the additional 1,000 edge-cases we learn tomorrow, or we could simply say that invalid 2822 messages MUST never verify and call it a day. Mark. ___ 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
On Tue, Oct 05, 2010 at 10:31:32PM -0400, Dave CROCKER allegedly wrote: > > > > > PS: Note that I'm saying nothing about whether or not this > > issue should be mentioned in 4871bis. > > > FWIW: > > Adding to a specification, by trying to protect against behavior that is > already > illegal is wasteful, redundant and opens the door to an infinite path of > similarly unnecessary provisions. Plainly bad specification methodology. Right. This seems like it's going down a rat-hole. There was an assertion in RFC4780 about "conforming emails" that must only have a single 2822.From header. That got lost in the translation to 4781 I guess. Unfortunately, 4780 failed to specify what "conforming" means explicitly. I also know that this WG has repeatedly stated that messages that are not within standard MUST fail verification. That this is not in 4871 seems to be mostly a WG assumption that should be made explicit. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Comments on draft-ietf-dkim-implementation-report-01
On Thu, Sep 30, 2010 at 06:51:44PM -0700, SM allegedly wrote: > Hello, > > I have a few comments about > draft-ietf-dkim-implementation-report-01. Me too. Thanks very much for writing this up, Murray. Very enlightening. And that Alt-N - a relatively small company - hosted an event for the big guys at their expense speaks volumes about the commitment of Arvel and his crew. We are in their debt. Mark. ___ 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
On Mon, Sep 27, 2010 at 11:39:43AM -0700, Dave CROCKER allegedly wrote: > > > On 9/27/2010 11:04 AM, Murray S. Kucherawy wrote: > >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > >> boun...@mipassoc.org] On Behalf Of John R. Levine > ... > >> It is not my impression that they all do the full DKIM validation while > >> the SMTP session is open. Mine doesn't. > > > > The milter-based ones like OpenDKIM and dkim-milter do. > > > It's been a significant revelation, for me, to realize how common it is for > DKIM > processing to occur during the SMTP session. > > So SMTP issues reduce to finding ways of preventing the cross-net transfer of > data or even of preventing the SMTP session. Oddly, I think the latter is > more > feasible than the former. So is this a premature optimization discussion? In terms of the big guys, it's a complex question as it depends on what other processing occurs at SMTP time, such as AV and anti-spam and *where* that processing occurs (on the SMTP socket machine or somewhere else). Most big guys will have mail processing distributed across multiple systems during the SMTP session. All the big guys have an ideal location (or the only realistic location in some cases) where they did/or-will install DKIM processing and that will likely vary from player to player. The smart ones might even do some processing in different places dynamically depending on the current load of each piece of infrastructure. Frankly I think that the decision of where a big player does processing will be driven by their infrastructure and internal design far more than any tweaks to a standard or set of recommendations we might make. Even if we knew what they all did today, there is no reason to expect that will remain unchanged for any substantial period of time. As an aside. Just looking at the simple metric of holding times of an SMTP session, the biggest cost typically comes from slow clients rather than the CPU latency of processing a DKIM signature or anti-spam content analysis. Mail from remote ISPs in countries with constricted connectivity can often trickle in at 1200bps-type speeds. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Key rotation
> http://feedbackloop.yahoo.net/ > > Step 2 doesn't help. (yes, you can put * for all selectors, but asking for > one when it isn't really needed leads to FUD). A selector can of course be in a sub-domain format, such as september.dialup._domainkey.example.net I wonder if they considered letting you enter *.dialup or somesuch? Obviously, requiring or using a fixed name selector is something no sensible person should be advocating. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Key rotation
On Sat, Sep 04, 2010 at 01:41:41PM -0700, Steve Atkins allegedly wrote: > Do we have any thoughts on 1. how often keys might sensibly be > rotated and 2. how long public keys should remain visible after the > private key has been rotated out? I believe the general thrust is that DKIM keys are ephemeral so no one should rely on there long-term presence. Your verifying MTA should annotate inbound mail appropriately so that subsequent reliance on the public key is not needed. Authentication-Results header being a good place to store what is needed here. (I know you know this, Steve. I'm just setting the stage). In that light, I would expect that a public key only needs to stay around as long as an email can remain in-transit plus some fudge. Maybe seven days or thereabouts? Turning the question back to you. Is there any motive for removing public keys rapidly apart from when they've been compromised? I can't think of any obvious reason why you'd want to do this, so I'm curious to hear of any use-cases you have in mind that warrant rapid removal. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Mailing lists and s/mime & dkim signatures - mua considerations
> >> As a part-time MTA developer I am not confused. The DKIM signature
> >> provides a simple piece of trace information ("I handled this mail")
> >> that is cryptographically bound to some header and body content.
> >
> > Yes. And that the obverse is possible: "I didn't handle this mail".
>
> I don't see how DKIM can provide the obverse - the obvious way
> is for a sender to assert that all their mail has a DKIM signature,
> but that fails when the DKIM signature breaks in transit. Is there
> a clever trick I'm missing?
So you're saying it can provide the obverse; you just don't like the
failure modes. Perhaps surprisingly, the failure modes are exactly
what attracts some folk to DKIM.
We also have to be patient. When DK was first discussed, folk said
that it was impossible because MTAs routinely made arbitrary changes
to the payload, but that's no longer true. Folks also said that the
mainstream players would never get on board, but that's no longer
true.
A fork-lift change was never going to occur overnight so we just have
to keep chipping away.
Mark.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Mailing lists and s/mime & dkim signatures - mua considerations
On Tue, Aug 24, 2010 at 09:45:20AM -0400, Wietse Venema allegedly wrote:
> Hector Santos:
> > IMO, it is these statements that continues to raise confusion and
> > raise the barrier of industry wide adoption that includes the general
> > population of MTA developers and operators from tiny to small to even
> > large.
>
> As a part-time MTA developer I am not confused. The DKIM signature
> provides a simple piece of trace information ("I handled this mail")
> that is cryptographically bound to some header and body content.
Yes. And that the obverse is possible: "I didn't handle this mail".
As Jon Callas is fond of saying, you know a protocol is a success when
it's abused in ways you never thought possible. The bi-laterals that
others have discussed are a small example of this.
Jon got it right: we don't need to know all of what is possible with
so general a component as DKIM.
My personal motivation, going back some seven years now, was about
tools for putting credibility (back) into the email system. Clearly
this is far from the only motivation across the population of DKIM
developers. Varying motives don't necessarily mean varying tools.
Mark.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
> hmm, I am surprise that I have to be put into an awkward > position to explain what "binding" means here as digital signature > term in what I thought was a technical qroup. Very odd. Hector. You are too funny. You miss the subtlety and then you assume the OP is inexcusably ignorant. I just love the Schoolmarm lessons that inevitably follow. Priceless. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
On Fri, Aug 20, 2010 at 11:55:40AM -0700, Murray S. Kucherawy allegedly wrote: > > -Original Message- > > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > > boun...@mipassoc.org] On Behalf Of Hector Santos > > Sent: Friday, August 20, 2010 11:42 AM > > To: ietf-dkim@mipassoc.org > > Subject: Re: [ietf-dkim] marketing dkim > > > > Dave CROCKER wrote: > > > > > > No doubt some do validate the From: field. Others merely mean "the > > > message went through my MTA". Any assertion of From: field assessment > > > is therefore far outside the scope of the DKIM base specification. > > > > This is hard to grasp and conflicts with the DKIM base specification > > which makes the 5322.FROM a fundamentally required binding hashed > > entity in the DKIM signature manufacturing. > I don't know what you mean by "binding". DKIM doesn't say From: has > to contain any particular value, only that it has to be one of the > signed fields. I don't know about binding either, but my point, before this sub-thread is completely lost, is that the suggestion that a "caring provider" put in some user identifiable token amounts to the same thing as asking a "caring provider" to ensure that 822.From can be used as a user identifiable token. In other words, there is no need to invent anything new here to achieve the OP's result. After all, an uncaring provider means that >From is as reliable as any other user identifiable token, which is to say, not at all. So, assuming you can determine a caring provider, then ask them to be careful about 822.From rather than ask them to invent and insert some other user identifiable token. Note: I'm not necessarily advocating the OP's suggestion, just saying no new token needs to be invented to support it - instead, just make the recommendation to "caring providers". Job done. Move along. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
> > Right, but emphasize that the granularity is a signing domain -- it is > > not and cannot be a way to attribute mail to individual people. > > > > Unless you have reason to believe that the signer is taking steps to ensure > that the sender information is accurate. I'd say that a DKIM signature from > a reputable service provider would quite likely increase the *chance* that > the sender information is accurate. Of course, you can't be certain (with > any technology), because any account might be compromised by phishing. Why isn't a signed 822.From sufficiently accurate sender information from a provider who cares? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Mailing list reality check
> A) Use the From: address (or something that identifies the contributor) > as the primary sort criterion > > B) Use the List-ID: (or something that identifies the list) as the > primiary sort criterion > > C) Something else C) The 821.RCPTTO address. Which probably means this straw poll really is surveying the "fringe" of the email world. (And I mean fringe in the nicest possible way of course). Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
> So my view of the service being discussed here isn't one where some > guy in upstate NY claims to have full knowledge of which domains > DKIM-sign all their outbound email. Rather, it's a service where the > manager of the service uses claims made by the sender about whether > they sign all of their email and then only lists those domains that > know what their doing. Why not have a negative service then? John's list can refute an ADSP of "at risk" domains by including a link of an exemplar unsigned email (ironically provable via SPF if necessary...) Sortof assume ADSP competence until shown otherwise rather than assumed incompetent until judged otherwise? That list would then be quite valuable as a way of letting such domains know that they are vulnerable *and* where their leak is. dig paypal.com._whatever... txt atRisk=y; claimsADSPAll=y; counterExample=http:// Conceivably "at risk" domains would first submit themselves to such a service and ask it to discover and publish (and/or feedback) counter examples. Since all you need is one counter example, getting 20 or 30 large, trusted mail providers to participate in identifying such emails and domains should be able to know pretty quickly when something has gone awry with their IT audit. John's list then simply becomes a focal point of discovery rather than a judgment call. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Broken signature analysis
> The thing that I'm skeptical about is that an automaton can be > programmed > to do this sort of analysis with any sort of accuracy. We're talking > about > a potential flood of reports coming in, I assume, so I doubt we're > all going > to be putting out job reqs for "DKIM Signature Breakage Analysis > Engineer". > There were far too many breakages even with tools and hunches that > were very > difficult to figure out, and even then there were lots of mysteries. > > And of course, there's an open question about what you do with this > sort of > forensic data... it can be gamed, after all. So if there's any > advantage for > bad guys to game it, it probably will be. I wasn't thinking of wide activation necessarily, it might be something that, eg, just MAAWG members and implementors might selective enable over an interop testing period. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Broken signature analysis (was: Proposed new charter)
On Feb 24, 2010, at 5:51 AM, Michael Thomas wrote: > I'm sort of dubious about this. Unless you're using z=, your chances > of > figuring out why something broke are slim to none. With z=, your > chances > of figuring it out are merely slim. > > Mike, with far too much experience at that It got a luke-warm response a few years back, but now that a lot more people are having to deal with "why did the verify failed", is it worth re-vivifying the DKIM-Trace stuff, or whatever it was called back then? We found it very useful for our early days of interop testing. The idea is pretty simple: The signer adds a header that characterizes the content before and after canonicalization. The verifier performs the same characterization and compares the differences. The characterizations we used at the time were simple character counts represented in a relatively compressed form (27 a's, 60 b's, 40LFs, 50spaces, etc) The form we used is kinda ugly as http://www.ietf.org/mail-archive/web/ietf/current/msg39488.html shows, but it was very illuminating as things like mis-match of white-space counts, or case-conversions, etc, identified what changed and where it changed (canonicalization vs transit). Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM on envelope level
> Do you mean the server's side of the connection will have buffer > data in it? That would mean the client sent DATA followed > by header/body information, possibly even in the same packet, > without waiting for the reply from DATA. The server could drop the > connection I haven't been watching lately, but at some point a popular bot technique was to send the whole transaction without looking at the responses. After all, what do they care? It was popular enough to generate the "greet_pause" feature in sendmail - as you must know. I don't know whether "greet_pause"-type detection is so wide-spread now that spammers have moved away from doing it, but I'll bet a lot still don't care and just blast away. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM on envelope level
On Oct 29, 2009, at 9:11 AM, Dave CROCKER wrote: I'm guessing the incentive for all of this is to reduce bandwidth, otherwise why not just issue the 4XX/5XX after the DATA/. sequence rather than invent a new mechanism to issue the same response at the envelope end of the transaction? > First blank line after DATA. > If the proposal is an attempt to reduce SMTP bandwidth, which is becoming a vanishingly small part of Internet traffic for most sites anyway, then stopping after DATA doesn't help as your OS will have likely received a socket buffer full of data, even if the application doesn't read it. So it might make you feel good, but it doesn't reduce the bytes coming down the line consequentially. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM adoption
On Aug 3, 2009, at 10:31 AM, Douglas Otis wrote: > On 8/2/09 1:06 AM, Mark Delany wrote: >> On Aug 1, 2009, at 9:14 PM, Franck Martin wrote: >> >>> But is ICANN supposed to clean all these random valid domains? >> >> You half-joke, but one of the arguments we presented to the FTC >> back in >> 2003 or so regarding spam was that we had an opportunity to regulate >> issuance of domain names. If not regulate, then at least insist on an >> identifiable legal entity being required to register a domain. > > Rather than viewing control of a domain as indicative of good email > behavior, positive reputations based upon histories of DKIM > signatures could offer an alternative or enhancement to methods > currently used in the disposition of messages. > That's entirely orthogonal and nothing new. My point was something stronger and different from "reputation", namely something jurisdictional; can I find (and sue) the owner of the domain on the DKIM signature? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM adoption
On Aug 1, 2009, at 9:14 PM, Franck Martin wrote: But is ICANN supposed to clean all these random valid domains? ;) You half-joke, but one of the arguments we presented to the FTC back in 2003 or so regarding spam was that we had an opportunity to regulate issuance of domain names. If not regulate, then at least insist on an identifiable legal entity being required to register a domain. With that "simple" expedient and wide-spread deployment of DKIM you have potential legal recourse to inappropriate email. ICANN of course couldn't care less as they are in it for the money, just as registrars are, but as I understand it, ICANN still operates under an MoA from the US Department of Commerce so the opportunity is not completely lost, yet. Unfortunately that opportunity may disappear soon as ICANN are pushing hard for complete autonomy, at which point profit will always be the primary motive. My point being, issuance of domain names could be a choke-point and combined with DKIM potentially provides recourse that is currently not available. This attacks the opposite end of the spectrum that "reputation" focusses on. Having said that, you could then have reputation systems based on jurisdictional recourse. What if you receive traffic from a domain and you are able to query for the legal owner of that domain and whether you could sue that domain for spamming? A jurisdictional market for domains could move good senders to register in tougher jurisdictions whereas the bad guys would stay well clear. Just as companies today decide whether to register on the NYSE or in the Cayman Islands. Just another arrow in the quiver, but a useful one methinks. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC4871bis - whether to drop -- h: Acceptable hash algorithms
>> If a site wanted to revoke instantly any signature previously >> generated with rsa-craphash, couldn't it just revoke its old keys >> and generate new keys, and begin signing with rsa-goodhash? > > Yes, it is a design feature of DKIM that an operational crypto error > can be instantly "revoked" by merely yanking the keys from DNS (modulo > cache timeouts etc). The only thing I would correct in your statement > is the word "revoke." DKIM bypasses the very notion of revocation by > being key-centric. Though the spec discusses an empty p= as giving an explicit "revoke" indication. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Features that could be reconsidered as part of the bis process
>> DKIM-Signature Header tags >> >> x: Signature expiration >> l: Body length count > > Removal of these would be a show stopper for me. In fact, overall, > anything that is SECURITY related should be protected from removal > proposal. Do you mean anything that is security related or do you mean any thing that improves security? You're not being very precise. As I understand it l: reduces security because it introduces wiggle- room and x: seems only to offer theoretical benefits that are far more concretely established via key revocation in the DNS. Furthermore, x: is largely meaningless if you accept that DKIM is a temporal authentication mechanism, which it has always intended to be. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP Informative Note on parent domain signing
Informative Note: DKIM signatures by parent domains as described in section 3.8 of [RFC4871] (in which a signer uses "i=" to assert that it is signing for a subdomain) do not satisfy the requirements for an Author Domain Signature as defined above. >> [ . . . ] >>> Works for me. >> >> +1 >> >> (I'd use commas instead of parentheses, but that's minor.) > > IMHO, this is still wrong. The i= value should be _ignored_ when > determining ADSP compliance. I'll try some examples. > > > Any sub-domain included within the i= value (AUID) will not affect > ADSP compliance. Only email-address domains that reference the DKIM > key can comply with ADSP assertions. > ' Right. The point is that i= is irrelevant at this stage to ADSP, just as other tags in the signature may be. The question is whether we want to be explicit about this tag not being relevant (and hence all the others that aren't relevant need to be stated too). Maybe the right thing to say is that a future extension to ADSP may address how to interpret other signature tags, such as i=, but for now they are explicitly *not* part of the ADSP evaluation. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Author Signature vs. Author Domain Signature / Internal vs External threats
On Apr 2, 2009, at 1:46 PM, Wietse Venema wrote: >> I think you may have put your finger on the root of much of the >> interpretation differences. It might in fact be a really good idea >> to replace the term "Author Signature" with the term "Author Domain >> Signature" throughout the ADSP spec to help address this. It seems >> >>> The specification and semantics of ADSP get simpler, cleaner and >>> properly >>> scoped, when d= is used. Using i= really does invite a complex of >>> issues that >>> should be outside the scope of DKIM and ADSP. >>> >>> Use d=. >> [> ] >> >> +1 > > I am all for this. > > +1 Agreed. Let's have a simple ADSP that minimizes the wiggle room available for confusion or complexity. After some real world experience, we can add complexity as needed. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Consensus point on ADSP
>>> Note: ADSP is incompatible with valid DKIM usage in which a >>> signer >>> uses "i=" with values that are not the same as addresses in >>> mail >>> headers. In that case, a possible workaround could be to add a >>> second DKIM signature a "d=" value that matches the Author >>> Address, but no "i=". >>> > > I'll start by proposing text that we could use if we adopted an > alternate definition of Author Signature based on the d= value only. > Then I'll describe what I think we'll lose by going to that > definition. Given that i= is an arbitrary value assigned by the signer, the question to me is what value does it add beyond what signed RFC2822 headers can do just as well. Eg, why not set an rfc2822.Sender Field and sign that rather than invent i=? IOW, what is the value-add in inventing yet another identity called DKIM.i= when we already have rfc2822.From, rfc2822.sender, rfc2822.resent-from, rfc2822.resent-sender and rfc2821.mailfrom? Are you suggesting that DKIM.i= should have preference over signed RFC2822 identifiers? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Another take on "all email from us is dkim signed"
> Outside of DNS query related technical issues, the first > operational repercussion is the lost of handling legacy mail. We > need to use an "standard anchor" something we know will always be > there, which as it is now, is the From: domain lookup. > For those subset of folk who want to do that, nothing stops you storing the ADSP query result with the email when you write it to your local disk. Your disk, your rules. Besideswhich, since only signed mail could legitimately contain the "I don't sign everything anymore" you'll have to somehow track that across to unsigned emails when you store them or maintain a state change history per domain so you can correctly analyze unsigned legacy mail. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Another take on "all email from us is dkim signed"
On Wed, Mar 11, 2009 at 3:33 PM, Steve Atkins wrote: Did we already look at this idea and discard it before we settled on using a DNS query for every email received? Discussed, not discarded. AFAIR, the general feeling is that Lookups are cheap today. Essentially such an approach is asking every MX target with more than one system to invent some way of distributing the knowledge it discovers on an inbound, signed message. You also have to invent mechanisms to deal with corner cases and timing windows, such as when one MX target receives a "we don't sign all anymore" and another MX target for the same domain almost immediately receives an unsigned email from that domain. Or what if you use your ISP as a secondary MX and the "state changing emails" happened to be queued up there for a while? I also don't see how it changes anything from a functional POV. If ADSP is carried in the signature vs carried in a DNS record, it would presumably invoke the same level of WG discussion over semantics and purpose. Given the highly cacheable nature of ADSP information and the fact that we're already querying the DNS for key information, it's unclear what the big benefit would be in moving this in-band. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC4871bis
On Jan 28, 2009, at 5:22 PM, Suresh Ramasubramanian wrote: > On Thu, Jan 29, 2009 at 2:22 AM, Douglas Otis > wrote: >> There will be work involved when dealing with opaque i= values when >> assessing reputations. Any amount of consolidation of this >> information will >> induce a higher degree of collateral blocking. It seems best to >> keep this >> an opaque value that the sender fully controls. > > Those opaque i= values will be of some use to the sender. I see no > reason why the receiver can't simply ignore them. Colo(u)r me dumb/confused/take-your-pick, but is i= effectively the moral equivalent of IDENT (RFC1413)? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] domain existence check
On May 23, 2008, at 6:05 PM, Arvel Hathcock wrote: > > A compromise proposal has been laid out which is to remove the > NXDOMAIN > step from the algorithm but add text defining ADSP as applicable > only to > domains which actually exist in DNS. This removes the need for > ADSP to > specify how (or by what means) such a check is determined, does not > introduce normative language, addresses all the objections yet put > forth, and still provides a basis for believing that a check will > be done. > If we are to have or to imply a check, then surely the worst situation is for a domain advertising ADSP to have no clue as to what verifiers will do, apart from the fact that they will do something that is effectively random. Surely a technical spec that guarantees a random result is not a good spec. Rather than create a vague definition of "existence" why not make a precise definition but make it optional. A verify MAY do an existence test and if they do so, it will be done as follows... Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: Overview service-type and delegation
> It also limits the ability of an external party that has been > delegated a key for a particular service to (mis)use that key for > other, unauthorized services. > That's probably the best reason for it. In any event, this is surely moot at this stage. Most protocols end up with unused or under-used parts to them. It's a pity my Mum never warned me that protocol design has much to do with prophesying. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: Overview service-type and delegation
On Mar 25, 2008, at 9:00 AM, Jim Fenton wrote: > Dave Crocker wrote: >> >> >> Jim Fenton wrote: >>> Dave Crocker wrote: >>> You further seem to indicate that s= is not currently useful but would be if it listed other services. (I well might be misunderstanding this part of your text.) In any event, either the capability has currently utility, or it was a mistake to put it in the spec. Which are you saying? >>> >>> The current utility is that, while extensions can be added any time, >>> constraints need to be added up front. So if another service >>> besides >>> email >>> wanted to use DKIM and its key infrastructure, it wouldn't be >>> possible to >>> cause new keys created for that service to not also be used for >>> email >>> unless >>> we define it now so that "legacy DKIM implementations" in the future >>> will >>> honor the constraint. >> >> Actually, this all touches on the question of trying to recruit >> signature verifiers into the task of enforcing a signer's internal >> policies. That's what restrictions on authorization to signing are. > > The same could be said about restrictions on hash and signing > algorithms, yet those are essential. > But the failure mode is quite different. If the verifier ignores or mis-interprets instructions on hash and signing algorithms, the verify process fails-closed. If the verifier ignores s= instructions, the verify process fails-open. As a principle, I would have thought that a fail-closed outcome would be something we prefer if the verifier does the wrong thing. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: Overview service-type and delegation
On Mar 24, 2008, at 10:30 PM, Jim Fenton wrote: > The current utility is that, while extensions can be added any time, > constraints need to be added up front. Okay, I'll bite. Why is this a good idea? By way of contrast, when an A RR is added to a DNS zone saying what address to use, no constraint is placed on the sorts of connections that can be made to that address. When an MX is added to a DNS, nothing is said about using it or not using it for purposes other than finding a mail server (they are of course used for anti-spam checking amongst other things). So I sort of struggle over why we would want to try and constrain the use of a DKIM RR, particularly when we rely on the good graces of a verifier to enforce that constraint and whether they do so or not is entirely unknown to the DKIM RR publisher. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: Overview service-type and delegation
On Mar 24, 2008, at 10:18 PM, Dave Crocker wrote: > > Jim Fenton wrote: >> Section 4.1 paragraph 3 talks about the service type (s=) >> constraint in >> key records, and goes on to say that it is helpful when delegating >> signing authority. s= was included to provide expansion capability >> should, at some point, some service other than email decide to use >> DKIM. If and when some other service does use DKIM, the ability to >> constrain a key to signing email only would help delegation. In the >> meanwhile, there isn't any benefit to delegation as a result of s=. >> >> I suggest that the paragraph be deleted. > > > You suggest having the DKIM Overview make no comment on the s= > parameter? > > The signing specification's explanatory text for s= is: > > "This tag is intended to constrain the use of keys for other > purposes". > > If there is something inaccurate in the Overview text, what is it? > > As for "included to provide expansion capability", I don't > understand what this > means. The signing spec text says it was included for a different > purpose, but > that it *includes* an expansion capability, to list other services. > > You further seem to indicate that s= is not currently useful but > would be if it > listed other services. (I well might be misunderstanding this part > of your > text.) In any event, either the capability has currently utility, > or it was a > mistake to put it in the spec. Which are you saying? As I understood it, s= is about minimizing a compromise at the signing end. If a verifier in another context sees content signed by a key that says s=email, then they know that the private key at d= has been compromised. So s= is about a verifier helping to minimize the damaged of an internal key compromise at d=. Whether this is a reasonable risk or not to encode in the protocol is a question. Also, I don't understand what "s= helps delegation" means, that Jim refers to. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] What's the errata process for RFC4871?
A minor typo in one of the examples has been pointed out by one of our implementers and I don't really know the process for fixing this. Can someone explain this for me? (Chairs maybe). The typo is the absence of v=1 in the example on page 25. No big deal. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue 1550 - the name of the document (remains open *briefly*); there's still,disagreement on "Author"
On Mar 12, 2008, at 8:20 PM, John Levine wrote: >> Hello? Why? You mean it's out of line for me to point out that >> people might not have appreciated the full implications of what they >> were arguing about? > > Based on the discussion I listened to in the DKIM session, I am > confident that people who proposed changing the name of SSP are fully > aware that slightly more than zero effort would be required to change > record names from _ssp to _frodo or whatever, and perhaps even a > slight additional amount of effort would be needed to publish and > check both old and new names for a few weeks while people catch up. Might I also add that we agreed to a totally incompatible change from DomainKeys to DKIM in the interest of harmonizing the final standard even though the *installed based* was/is quite large. In that light, I'm interested in understanding why breaking DomainKeys for non-technical reasons was ok, yet breaking an _ssp draft with a relatively miniscule adoption rate is less than ok. Put another way, we had a bunch of working code that the IETF threw away. Why is our working code less important that the _ssp working code? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: ISSUE 1521 -- Limit the application of SSP to unsigned messages
On Jan 24, 2008, at 6:14 PM, Hector Santos wrote: Mark Delany wrote: On Jan 24, 2008, at 8:37 AM, Wietse Venema wrote: Summary of proposal: All text that causes SSP to be applied to an already-signed message needs to be removed. I would take this further: remove all text that says when to apply SSP. Instead, provide text that states the contribution that SSP can make under different conditions: mail with valid first-party signature, mail with valid third-party signature, and mail without valid signature. +1 If for no other reason than the obvious fact that SSP is not making progress as it stands. We need some sort of reset if we hope to proceed. Its unfortunate that it has nothing to do with technical reasons but the powers that are pushing reputations instead. The fact is, Dave's never cared for SSP It's the IETF, everyone has a say regardless of whether they are qualified. You, me, Dave, everyone here. But to disagree with you, I voted +1 precisely for technical reasons. I want a simple solution that non-WG-specialists can grok. I don't think we have that today. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: ISSUE 1521 -- Limit the application of SSP to unsigned messages
On Jan 24, 2008, at 8:37 AM, Wietse Venema wrote: Summary of proposal: All text that causes SSP to be applied to an already-signed message needs to be removed. I would take this further: remove all text that says when to apply SSP. Instead, provide text that states the contribution that SSP can make under different conditions: mail with valid first-party signature, mail with valid third-party signature, and mail without valid signature. +1 If for no other reason than the obvious fact that SSP is not making progress as it stands. We need some sort of reset if we hope to proceed. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Tracing SSP's paradigm change
It's purely a strawman, but I sense that sub-setting a core might help us move forward. I am likely wrong, but it's a question I'd like to ask. My sense from reading the list traffic is that there are a lot of differing opinions on what the subset might contain, with results ranging from making SSP vaguely useful to actively hostile to DKIM deployment. So does that mean you are skeptical about the existence of a broadly acceptable subset of SSP or merely that there might be contention over what that subset is? Given your participation level, I readily bow to your greater knowledge of WG sentiment, but it seems to me that if there is no acceptable subset, then you are in effect saying that the current SSP is the minimalist possible functional spec. Is that what you are saying? That the current SSP is indivisible? In any event, I see Jon's suggestion as a divide-and-conquer approach. If it moves us forward, I'm for it because at this stage I suspect that progress is as important as substance. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Tracing SSP's paradigm change
On Dec 12, 2007, at 10:36 PM, Jim Fenton wrote: Mark Delany wrote: On Dec 12, 2007, at 6:01 PM, J D Falk wrote: Jon Callas wrote: I offer as a suggestion that we issue an SSP document that describes only the basic broken-signature-only model of SSP with only the one policy (sign-all). After that, we look at enhancements to the model carefully. We seriously discuss whether they are outside the charter because of the effect it has on the global email infrastructure to turn DKIM from an opt-in protocol to a you-must protocol. We also seriously have to look at other policies to discuss their effectiveness along with their environmental effects. +1 This will let us experiment and learn through real-world operational experience, rather than continually rehashing the same arguments. Plus One. I'm inclined to this approach if we can't reconcile the differences that appear to have stalled SSP progress. Is there a common subset of SSP that most everyone agrees on? I thought we had documented it in RFC 5016. From an IETF procedural perspective that may well be so - my question is more about whether the sentiment of the WG matches 5016? It's purely a strawman, but I sense that sub-setting a core might help us move forward. I am likely wrong, but it's a question I'd like to ask. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Tracing SSP's paradigm change
On Dec 12, 2007, at 6:01 PM, J D Falk wrote: Jon Callas wrote: I offer as a suggestion that we issue an SSP document that describes only the basic broken-signature-only model of SSP with only the one policy (sign-all). After that, we look at enhancements to the model carefully. We seriously discuss whether they are outside the charter because of the effect it has on the global email infrastructure to turn DKIM from an opt-in protocol to a you-must protocol. We also seriously have to look at other policies to discuss their effectiveness along with their environmental effects. +1 This will let us experiment and learn through real-world operational experience, rather than continually rehashing the same arguments. Plus One. I'm inclined to this approach if we can't reconcile the differences that appear to have stalled SSP progress. Is there a common subset of SSP that most everyone agrees on? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: t=y
On Nov 9, 2007, at 7:46 AM, Dave Crocker wrote: [EMAIL PROTECTED] wrote: A better question is how many domains will move signing into production without the testing flag, then fix the inevitable issues. Given that most protocols do not have a 'testing' flag -- and they manage to move into production quite nicely -- a different question might be why such a flag is needed... Ayup. I never had a good rationale for it either. I originally put it into DK on the behest of others in spite of personal reservations. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] The (really) latest SSP draft
On Oct 22, 2007, at 1:37 PM, Jon Callas wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So if he said i=subdomain.example.com, then surely the From/Sender can be expected to be from that subdomain; and if he said [EMAIL PROTECTED], then surely recipients can assume that 'someone' had indeed played some part in sending it. Absolutely not. DKIM is a protocol in which one administrative domain speaks primarily to other administrative domain. It's not a domain-to- user protocol nor a user-to-anything protocol. The i= parameter can be anything the signing domain wants it to be. It is unlikely to be an outright lie (for example, I mark all mail coming from alice with bob), but it may be. I liken i= to IDENT (RFC1413). The values *may* be meaningful to the administrative domain, but that's all that can be said about it. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New issue: Upward query vs. wildcard publication
John L wrote: percentages are "normal" vs. "unusual", but my cursory look a long time ago suggested that it met the 80-20 rule. You are certainly correct that most zones are pretty flat, but this sounds like a DOS attack waiting to happen, send out junk with long bogus addresses I'm just raising this as a discussion point; what if we said that the SSP record must (at least) exist at the registry cut-point? It's not particularly pretty, but you (only) need about a 1,000 entry database to define all the registry cut-points today. I know the size because we've built this sort of database for other reasons. I think SpamAssassin has something similar as well. That "root" SSP record could tell us max-depth within it's balliwick, if that's of use. I'm kindof a fan of the registry cut-point because that segues nicely into a responsible and hopefully knowable entity. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: LWSP in base64-encoded public key TXT RR
maybe Eric could still do a s/LWSP/[FWS]/g in AUTH48 eliminating LWSP everywhere (?) Absolutely not. This is a technical change. It's IMO more in the direction of an erratum. Nobody could claim with a straight face that they need lines consisting only of white space for their folding magic. Even if true, it is still a technical change. dkim-base is a standard *today*, even before the RFC is issued. Implementations of *the standard* have already been deployed. You are proposing a change to the way an implementation needs to act. This argument has been brought up at nearly every change made. If pre-standard compatibility is so important then DK signatures would still be valid. They aren't. So would IIM signatures. They aren't. So would early DKIM signatures. They aren't. Current DKIM deployment is infinitesimal compared to DK, so I find the "already deployed" argument bogus in the extreme. Besides, as I understand it, most implementations will serendipitously work anyway as the presence of WS in Selectors is uncommon. > If we tried that, the document would have to go through IESG review again. I thought that this depends on the AD or the shepherd (?) It is up to the RFC Editor. Of course I don't want a new IESG review or other delays. Why not? What's the rush? DKIM has been alive for at least a year and DK has been alive for at least two years? I don't understand why a small delay to get something right is considered so negatively by a technical standards group. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Re: 1368 straw-poll :
Michael Thomas wrote: been deprecated. To permit a graceful transition, both the deprecated algorithm (whatever that might be) and some shiny new algorithm must now be included with the message. Once your verifier adopts the shiny [ Two valid signatures in the message ] Wasn't this always the transition plan? The only crucial point is that the Selector associated with the "weaker" signature has to tell the verifier to expect the presence of "stronger" signature. If the verifier doesn't understand the "stronger/newer" signature or can't find it, then it has a risk decision to make about the weaker verification. Selector-embedded SSP could give guidance to local policy here. At least I can see the potential issue here. With the solution or the problem? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: 1368 straw-poll
Dave Crocker wrote: The proposed mechanism incurs an additional lookup for every signed message. Whatever algorithm policy you embed in a separate SSP can just as easily be embedded in the Selector of the weakened key. But maybe that just means I don't get any of the discussion about downgrade attacks or weakened keys needing a separate SSP. As others have said TTL is irrelevant because they are always going to be many orders of magnitude smaller than the response time of human administrators. Heck most administrators haven't even heard of DKIM yet alone the discovery of any algorithmic weakness. I was under the impression that a separate SSP can only add value for domains *not* verified by the signature. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [Fwd: Re: [ietf-dkim] canonicalized null body and dkim]
Charles Lindsey wrote: Anyway, here is some wording: The "simple" body canonicalization removes empty lines from the end of the body until either the last line is non-empty, or no lines remain. An empty line is a line of zero length after removal of any terminating CRLF. If the body is not now empty and the last line is not already terminated by CRLF, a CRLF is added to it. INFORMATIVE NOTE: Following [RFC 2822}, the CRLF which separates the header fields from the body is NOT part of the body, and therefore is never presented to the signing or verification algorithm. I think I agree with the effect, but I wish I could offer something terser, but that seems hard since this is dealing with the interaction of potentially different header canon and body canon. Does the INFORMATIVE NOTE imply that the following two emails canonicalize to the same thing? --- Last-Header: blahCRLF CRLF lineOne: blah1CRLF lineTwo: blah2CRLF --- --- Last-Header: blahCRLF lineOne: blah1CRLF lineTwo: blah2CRLF --- And yes, I purposely have a body that matches the header syntax. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [Fwd: Re: [ietf-dkim] canonicalized null body and dkim]
(Did you mean to include Last-Header: in the following examples?) Sure. In which case the answer is that the canonicalized output of 2-5 should be: --- --- Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [Fwd: Re: [ietf-dkim] canonicalized null body and dkim]
Charles Lindsey wrote: Now apply simple canonicalization to all those cases, using: "In more formal terms, the "simple" body canonicalization algorithm converts "0*CRLF" at the end of the body to a single "CRLF"." Making the entirely reasonable assumption that "body" means exactly what RFC 2822 defines it to mean, then here is what gets hashed in all of those cases: (Did you mean to include Last-Header: in the following examples?) 1) ordinary message with of 1 non-empty line: - barbazCRLF - 2) consisting of 2 empty lines - CRLF - 3) consisting of 1 empty line - CRLF - 4) containing no lines - CRLF - 5) message with absent - - That is undoubtedly what the "formal terms" in dkim-base undoubtedly SAY. It is NOT what the "informal" words in dkim-base say. It is NOT what version -01 of DK says. It is NOT what version -06 of DK says. It is NOT what Eric's three examples claim. It is entirely possible that is is NOT what dkim-base was INTENDED to say. I believe the intent is that 2, 3, 4 and 5 all canonicalize to the same content for c=simple, namely to match 5) as: --- Last-Header: foobarCRLF --- Mark. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[Fwd: Re: [ietf-dkim] canonicalized null body and dkim]
Tony Hansen wrote: (Sorry for the truncated message previously. I hit "send" accidentally.) You're missing this statement: "In more formal terms, the "simple" body canonicalization algorithm converts "0*CRLF" at the end of the body to a single "CRLF"." This states *how* the blank lines at the end of the message are to be discarded. FWIW, this problem was similarly discovered in DK. The early text read: -01 o All trailing empty lines are ignored. An empty line is a line of zero length after removal of the local line terminator. The empty line that separates the header from the body is a to be included in this process. and the later text read: -06 o All trailing empty lines are ignored. An empty line is a line of zero length after removal of the local line terminator. If the body consists entirely of empty lines, then the header/body line is similarly ignored. In short, if the last empty line of the email is the header/body separator, then it should not be fed into the canonicalization. The "simple" in DKIM, as I understand it, is merely re-codifying the same function. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC2822.Sender
On Wed, Aug 09, 2006 at 10:30:21PM -0400, Tony Hansen allegedly wrote: > Stephen Farrell wrote: > > > > Michael Thomas wrote: > >> Tony Hansen wrote: > >>> add RFC2822.Sender > >>> > >> I'm not the chair, but I've seen considerably less consensus about > >> anything other than rfc2822.from. I'm frankly not sure I understand > >> it very well. > > > > I know I don't understand it! > > > > Maybe a more detailed use-case would help? (Tony?) > > I want to make certain that what we're building with policies doesn't > prevent eCard senders or News agencies from doing what they currently > do. They should be able to 1) send a message to someone on my behalf > while 2) marking themselves as the sender and 3) being able to sign the > message. According to 2822, this minimally requires support for > RFC2822.Sender as well as RFC2822.From. Why does DKIM need to support these directly? They can continue to send like this just fine and rely on their domain reputation or the good graces of receivers. Better yet, eCard senders could put their own From: address in and put your email in the content: From: [EMAIL PROTECTED] Howdy. mailto:[EMAIL PROTECTED] allegedly sent this card to your for your birthday... It seems bizarre to me that we want to explicitly allow an unauthenticated 2822.From to be treated as authenticated. One option: att.com could advertise that hallmark.com can put @att.com in the 2822.From: and have it authenticated via hallmark.com. Is that what you're asking for? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] How to reconcile passive vs active?
On Sun, Aug 06, 2006 at 10:53:21PM -0700, Michael Thomas allegedly wrote: > Hector Santos wrote: > > > > >Even then, the main issue are the potential damages that are being > >ignored. > >My wife said it best when asked why even the BIG companies like WALMART, > >YAHOO, CISCO, AOL.COM, BIGBANK should also support strong policies: > > > > > I can say with little hesitation that Cisco will never publish the "strong" > policy as envisioned by Mark for our user population. I'd be interested > to hear from Mark whether Yahoo-inc ever would for their corporate > users. The question is whether there is a useful subset of domains that want a "strong" policy. All indications on this list are that a good number of us think "yes", so the "strong" policy position needs comprehensive coverage in your requirements I-D. Have you got that covered in your draft or would additional text be of use to you? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] How to reconcile passive vs active?
> From: "Dave Crocker" <[EMAIL PROTECTED]> > why is is not sufficient to leave things with the simpler -- albeit > more passive -- stance that a sender talks about themselves but > refrains from telling the evaluator what to do with the information? > Yes, that is at odds with a classic model of protocol specification, > but we are juggling among constraints, here. As one of the chairs pointed out, we are probably circling at this stage and are consequentially not covering much new ground. (I quote Dave solely because he encapsulates the differences succinctly). It obvious that there are two relatively strong viewpoints: one the passive that Dave describes and one the active that, amongst others, I describe. If we take the high ground and accept that both viewpoints are valid then our job is no longer to argue our differences, rather it's to work out how we accommodate those differences. So how do we do that? Do we try and settle on one perspective? My guess is that that seems unlikely. Do we try and accommodate both? If so, how? Or, is this mostly a matter of semantics with the end result being pretty much the same SSP syntax, but a different set of semantics in the specification? If so, can we work on the syntax and defer on the semantics as a means of moving forward? If it's agreeable to others, I'd like to suggest that as a way of moving forward, we focus on the meta-issue of how we resolve this difference rather than focusing on the details of the difference. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "I sign everything" is not a useful policy
> If I choose to deliver unsigned mail that purports to be from a domain that > says > it signs everything, but I mark it up with flashing lights that say "spoofed" > do > you want that to be a protocol violation? What about my choosing to send it to > my sysadmin for special handling for spoofed mail? What about... Well sure, but how about treating it the same as an IP checksum failure? You may divert it to some port for analysis - especially in the early days - but what sort of stack delivers a known damaged packet to the end point when the transmitter/protocol says to discard known damaged packets? DKIM+SSP is defining "damaged". Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "I sign everything" is not a useful policy
On Sat, Aug 05, 2006 at 06:06:59PM -0700, Dave Crocker allegedly wrote: > Seriously. SSP can be entirely useful when stated in terms of the sender's > perspective. It does not need to pretend that is knows enough to give > directions to an evaluator. Sorry for being dense, but I have to ask the question again. Who is the target audience for the "sender's perspective" if not the evaluator? Put in my blunt language. Why publish an SSP if no one listens? Dave, I know you are subtle about such things and the purposeful disconnect that is lost on me, clearly has merit to you. Can you use simple words and help me out? Of course SSP can only be advisory at best, but is their more to your perspective than that? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] SSP requirements
On Sat, Aug 05, 2006 at 07:05:16PM -0400, Hector Santos allegedly > Having SSP still in play will not serve your business well. Hector. Most of us on this list are in the email business - including you - as I understand it. If we start slinging arrows at anyone who has a business connection, most of us would have to recuse ourselves, would we not? John has a business interest, you have a business interest, I have a business interest. So what? I expect that we're all smart enough to recognize technical merit over business interest and respond accordingly. Let's face it, this is a list chock full of cynics. John has a zero (or less) chance of coercing you, me, or the other hundred folk on the list. John is not so dumb, he knows the obvious. I will say that that I think that John's DAC venture is exactly what we had hoped would be an outcome of this process. May there be many more DAC competitors emerging as DKIM is deployed. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "I sign everything" is not a useful policy
On Sat, Aug 05, 2006 at 04:57:23PM -0700, Dave Crocker allegedly wrote: > > > John L wrote: > >> Your assertion in the subject is an opinion. I find the statement below > >> to be useful. > > > > I think we have a subtle point here. > > > > "I sign everything so please discard unsigned mail apparently from me" > > could be useful to recipients. > > > > Plain "I sign everything" isn't. > > > Having the signer or the ssp publishes tell the evaluator what they should do > with a message is not a good idea Why do you say that Dave? If SSP is not giving guidance/information to receivers/evaluators, who then is the target audience for SSP? And what do we want them to do with the information? An interesting twist to "telling evaluators", as you put it, is that SSP is a negative indicator. It's telling evaluators *not* to deliver unless the right conditions are met. Why would an "evaluator" be suspicious of a domain that encourages non-delivery of its own traffic when in doubt? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
