-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At the end of January Dave Crocker posted a review of the then current "-01" version of draft-gondwana-dkim2-motivation. This document has now been split into an "-02" and draft-gondwana-dkim2-headers (-01).
Rather belatedly this is a response to that review, albeit spread over 14 (sorry) emails... ">>" is a quote from our document, ">" a quote from Dave Crocker ... lines that do not start with a ">" are me speaking. - -=-=-=-=-=-=-=-=-=-=-=-=- >> DKIM2 Why DKIM needs replacing, and what a replacement would look like >> draft-gondwana-dkim2-motivation-01 > >While the draft might have started with a direction that matches the title, it >is now more of an actual specification than a discussion document. And it is >more than an 'outline design'. > >> Abstract >> >> This memo provides a rationale and outline design for replacing the >> existing email security mechanisms with a new mechanism based around >> a more strongly authenticated email delivery pathway, including an >> asynchronous return channel. >Outline design? > >Note: "replacing email security mechanisms" > >Note: "more strongly authenticated email delivery pathway" The document is now split in two and if adopted by the Working Group will get reissued ... I think that would be a suitable point to fix the title and abstract. >btw, the return channel is always asynchronous. Arguably even direct, single- >hop is asynchronous, since the user client is almost certainly not connected >to >the process. For clarity we could say "a NEW asynchronous return channel" >> 1. Background and motivations >> >> In 2007, [RFC4871] (Domain Key Identified Mail / DKIM) was published, >> outlining a mechanism for a domain to sign email in a way that >> recipients could ensure that the email had come from an entity >> possessing the secret key matching a public key published in the DNS >> by the source domain. For clarity in this document we call this >> established scheme "DKIM1". > > *Again, the defined semantic of DKIM is not to ensure who a message > 'came from'. This confuses common practice with design. * > >It is to identify an entity that takes 'some' responsibility for it. To be ultra-pedantic it merely shows that an entity with a copy of the private key has been able to acquire a copy of (most of) the email which has now come into your possession... In fact RFC6376 expresses this in a different tense "permits [...] to claim responsibility" and the conditionality is I think wise. >This is very different. > > *And the difference is important because an email can get touched by > a lot of entities, each of which might provide a DKIM signature.* I am sure that we can settle on some wording (perhaps by copy paste) that describes DKIM1 appropriately. Or, alternatively, the Working Group could decide that this type of "scene setting" was irrelevant and the documents that we finally produce could just launch into a description of DKIM2. I don't think we need to decide that now before adopting anything. >Like the rest of the email architecture, the design of DKIM is much more >flexible. And this point of confusion sets the stage for an approach to email >that is much more constraining than email is designed to be. The word >Procrustean is apt. > >A casual dismissal with a comment like 'things have changed' is the usual >response to this point. Unfortunately it mostly reflects a lack of effort to >consider tradeoffs, or to embrace the historical IETF bias to retain as much >usage flexibility as supportable. > >> This document has been obsoleted and updated many times since then, >> and a large amount of operational experience has been gained using >> it. However, it has some known weaknesses with some kinds of email >> flow. >> >> If an intermediary alters the email then the original DKIM1 signature >> will no longer be verifiable. > >This is not a 'design weakness'. DKIM was intended to survive simple, classic >MTA-based relaying, but it never had a goal of surviving re-postings. It does >what it was designed to do. I tend to agree ... weakness is probably not the right word for "it breaks completely". No-one is suggesting that the impact of, for example, mailing list alterations to email were unforeseen (and indeed l= is present to try and address the issue). >Re-posting a message can entail arbitrary transformations and a technology >like >basic digital signing never had a goal of surviving that. DKIM was >/explicitly >NOT/ designed to survive these transformations. > >While there is nothing wrong with seeking to provide a mechanism that does >survive, it is a new requirement, not a failure in an existing mechanism. > >So the wording here is finding fault with something that was not a goal. > >Using language that implies or claims failures, for things that were known at >the time and were deemed acceptable or out of scope is not a failure. >Especially not after roughly 20 years. > > *What the above language actually implies is that this new effort > represents a substantially larger and more ambitious goal. One for > which I believe there is little or no technical history and > certainly no operational history.* > >This lack of experience with any mechanism -- other than a basic email object - >- >that works through multiple postings/deliveries makes this aspect of the >design >goal an open research topic. > >And there are no ready proposals that have been developed and discussed and >converged on, ever since the expansion of DMARC use created a problem for >multi- >posting/delivery sequences. /That's quite a few years without landing on a >concrete proposal./ > > *Surviving arbitrary manipulations that might take place, when going > through delivery and re-posting, is another open research topic.* > > > >> In 2019, [RFC8617] (Authenticated >> Received Chain / ARC) attempted to solve this issue. However, it >> does not provide a mechanism for determining whether recipients will >> recognise the ARC signatures or trust the veracity of the systems >> that add them. >There have not been any email-related mechanisms for pre-determining receiving >system support, other than the MX record's indicating support of receiving >mail. So this might be another ambitious goal, depending upon the specifics >of >the requirement, and especially since it needs to work at scale. > >"Trust the veracity" presumably means a receiving system's trusting the >assessment made of an originating DKIM signature which the ARC signer breaks? >The reader should not have to guess. > >That was never a goal for ARC, since assessing trust -- other than whether a >signer was authorized to sign -- has always been a value-add feature for all >of >these mechanisms, and outside of their scope. > > *Trust is an entirely separate and challenging line of reputation, > etc. (research) work.* These points appear to be commentary on the task being taken on, rather than on the documents or the design which we outlined. As such I think they are overtaken by events since we now have a chartered Working Group To the extent that they are taking issue with our verbiage in "scene setting" (where we wanted in particular to mention ARC, which has not in our view been a huge success, but some might believe otherwise) would the Working Group prefer to remove, and or significantly reduce, this material or try and rewrite it to make more clear the specific limits on what DKIM1 achieved ? - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBZ/lz1mHfC/FfW545EQKk2QCfexrXyeE4S/IcsPRjkPCBkP/5hOcAnRfA pdD3AgHN9HPoX6nbdHQggwPI =j6c4 -----END PGP SIGNATURE----- _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
