-----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. - -=-=-=-=-=-=-=-=-=-=-=-=- >> 5. DKIM2 header fields >> >> DKIM2 headers will have the following fields That should of course read DKIM2-Signature header fields will have the following tag values ... >> >> +============+=================================================+ >> | Field | Explanation | >> | identifier | | >> +============+=================================================+ >> | i= | Sequence Number (from 1 to N) | >> +------------+-------------------------------------------------+ >> | t= | Timestamp | >> +------------+-------------------------------------------------+ >> | ds= | Signing key identifier (domain & selector) | > >So this appears to conflate selector with domain name being signed? Why? > >How is the domain name being signed identified separately? Let's turn that round ... why did DKIM1 put the selector and the associated domain into separate fields ? If there is a compelling reason for keeping then apart we should take note it -- otherwise combining them is of minor assistance in handling crypto algorithm dexterity (see email #11) because we will wish to specify two (or more) signing key identifiers and otherwise they would be constrained to be in the same domain. >What is the purpose of the sequence number and how is it used? the purpose is to be able to place DKIM2 header fields in order and to unambiguously tie those header fields to other DKIM2 header fields (such as those used to describe modifications) its use is described in several other places in the document (at least one of which occurs before this text, which as already noted is sub- optimal) >> +------------+-------------------------------------------------+ >> | a= | Crypto algorithm(s) used (unless combined with | >> | | b= to allow for multiple signatures on the same | >> | | email, see discussion of crypto-agility above) | >> +------------+-------------------------------------------------+ >> | b= | Signature over hash value strings (DKIM uses | >> | | b=) | >> +------------+-------------------------------------------------+ >> | bh= | Body hash value (see discussion) | >> +------------+-------------------------------------------------+ >> | h= | Extra headers signed by this hop | >> +------------+-------------------------------------------------+ >> | m= | Indicates if mail has been modified or exploded | > >huh? there's more explanation below ... and exploded is perhaps a poor choice of terminology. Better suggestions welcome (though it does have the advantage of not coming with existing baggage...) >> +------------+-------------------------------------------------+ >> | mf= | RFC5321.mail-from | >> +------------+-------------------------------------------------+ >> | rt= | RFC5321.rcpt-to | > >/both/ of these??? > >btw, Mail From is meant to be a return address, not an author indication, in >spite of the name and in spite of the RFC821, etc. documentation. Also, none >of >that ever required a specific value, such as author address. I don't believe we say otherwise >> +------------+-------------------------------------------------+ >> | fb= | feedback requested for this email | >> +------------+-------------------------------------------------+ >> | n= | a nonce value (could use for database lookup | >> | | for DSN handling) | >> +------------+-------------------------------------------------+ >> >> Table 1 >> >> At the first hop there cannot be any modification, > >Why not? because the email is signed as is and there are no earlier DKIM2 signatures that could be invalidated by a change >> so instead the m= >> field is used to indicate a request by the sender that the email >> never be modified and/or never be “exploded” to multiple recipients. > >This sounds appealing. and look ... we indicate what exploded might mean ! >However a) it's actual purpose, b) its actual efficacy, and c) its likely >enforcement are worth questioning and explaining carefully, lest it otherwise >seem like a solution in search of a problem. I agree here that there is a need for caution ... It may be appealing to a financial institutions to label their email "addressee only" (rather like the paper envelopes some of them still send). This avoids various scenarios in which email is modified (with appropriate technical indications this has happened) but in such a way as to change the meaning of the mail -- and it also avoids the issues that arise when users are compromised and the bad guys leave a "back door" in the form of an automated forwarding rule. So potentially useful... However, the financial instiution cannot really know if one of their customers has decided to forward all such email to every member of the finance committee -- and that would then fail. viz: there is text to be written to discuss the trade-offs here; and the Applicability Statement may be the place for that text, rather than here >> This might be appropriate for some types of transactional email. >> Since it is only a request, intermediaries may, by local policy, not >> honor it, but they SHOULD NOT relay mail where the request has not >> been honored to third parties. > >huh? maybe re-code this with fewer or no negatives? Rewriting for clarity is certainly possible -- but I think the SHOULD NOT will need to remain ... but as noted elsewhere in this set of emails, these handling issues should be collected together and not scattered around. >> We will always hash headers in a "relaxed" mode (to use the DKIM1 >> jargon). For the body we will always use "relaxed" because that is >> the usual scheme for DKIM1. Relaxed is more expensive than "simple" >> but there have been concerns about expressed about interworking. The >> vast majority of DKIM1 email (99%+) uses relaxed/relaxed. I've been doing some experiments on the actual cost of relaxed/relaxed compared to relaxed/simple ... but that is a matter for another email altogether ! >> The hashes of the header and the body can be placed into the DKIM2 >> header field, and then a signature is applied. Alternatively we >> could define a signature over the hashes but not record their values. >> The second is neater but the former does allow an unchanged body hash >> to just be copied and may assist in diagnosing faults. Note also, >> that there is no technical reason for computing two hashes rather >> than one, but the presence of an obviously unchanged body hash may >> again be useful for fault diagnosis and may assist humans in >> reasoning about how and where changes were made to the body. >> >> The nonce value is available for any purpose, but may well be used as >> an index into a database to access meta-data about an email that has >> been handled in the past. DKIM2 signatures expire after a fixed >> period (a week would be appropriate) so that it is not necessary to >> hold information for indefinite periods or to handle DSNs for email >> that was delivered long ago. >> >> Note that we have not included a version number. Experience from >> MIME onwards shows that it is essentially impossible to change >> version numbers. If it becomes necessary to change DKIM2 in the sort >> of incompatible way that a v=2 / v=3 version number would support, we >> recommend using header fields labeled DKIM3 instead. > >indeed > >> For simplicity using single characters before the = would be good, >> but we quickly run out of obvious relevant letters. Where there is a >> match to DKIM1 fields these have been copied (though this is merely >> to assist humans, it's unlikely to affect any code). > >ack. > >> 5.1. Value of rt= >> >> Note that is inherent in the DKIM2 design that emails are only ever >> sent to one recipient at a time. At present some mail servers will >> batch deliveries together if they are going to the same destination >> and issue multiple RCPT TO commands in the SMTP protocol >> conversation. This is not possible with DKIM2 because each email >> must document a single RFC5321 destination in the rt= parameter. >> This may seem inefficient but only about 1% of email is currently >> delivered using multiple RCPT TO commands. > >Consider a bulk-mail packaging option. Something like using the destination >domain name without email address? (Shades of multicasting.) Bulk-email packaging options are used by spammers. They are not used by legitimate senders who need to customise unsubscribe etc >> 5.2. Maximum value for i= >> >> There will be an absolutely maximum value of 255 for i=; though >> realistically we should be able to bring this value back down to >> about 50. > >There has been no explanation of what sequence the i= value is indicating, or >why it is needed. discussed above >Why is 255 a reasonable maximum? excellent question ... 99 might be fine >> 5.3. Maximum age for t= >> >> For a message in transit, the timestamp MUST be less than one week >> ago. For bounces, they MUST be returned to their source within 2 >> weeks of the timestamp on hop i=1. This requires that as the >> destination, you MUST create the bounce within 1 week of receipt.aa > >Again, this seems unlikely to be very useful. it is of significant use for DKIM replay mitigation systems that need to expire their caches of DKIM signature values they have seen before >> 5.4. Registry of values for m= >> >> +==========+==============================================+ >> | Value | Purpose | >> +==========+==============================================+ >> | nomodify | Any hop that adds this requires no | >> | | modifications; anybody later hop must either | >> | | reject it or agree to pass it on unmodified | >> +----------+----------------------------------------------+ >> | header | This hop has modified the headers; a | >> | | separate header lists the algebra to revert | >> | | the changes | >> +----------+----------------------------------------------+ >> | body | This hop has modified the body; a separate | >> | | header lists the algebra to revert the | >> | | changes | >> +----------+----------------------------------------------+ >> | complex | This hop has done something complex and | >> | | there is no way to revert it | >> +----------+----------------------------------------------+ > >what will be done with different values? can I point you at draft-gondwana-dkim2-modification-alegbra >While the choices seem intuitively reasonable, there is a long history of >definitions seeming that, but lacking concrete specification for actual use, >which turn out to be far less useful than expected. > > >> Table 2 >> >> If there is no "m" value then this hop asserts it has not modified >> either the body nor any header covered by a previous DKIM2 signature. >> >> 5.5. Value for the fb= header >> >> Not present, do not send feedback for this email to the signing >> domain >> >> fb=y - this signing domain would like to receive feedback about the >> disposition of this email (e.g. percentage reported as spam). > >To what address? Why not specify the address here? that's our oversight -- and it still needs fixing in header-00, we will address that. We also need text about "alignment" for this value ... we don't want feedback going somewhere random ! - -- 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/l1s2HfC/FfW545EQKotgCgyXCLUBIiB8/PvEFAMCXDsiu5gsMAoMLn Qc9oH1KqX6B2cZ81vP5EgBT7 =Eqmd -----END PGP SIGNATURE----- _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
