-----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. - -=-=-=-=-=-=-=-=-=-=-=-=- >> 4.8. Algorithmic dexterity >> >> The specification will require both RSA and elliptic curve be >> implemented. If there is IETF consensus around a "post-quantum" >> scheme then that will also be included. Experience with DKIM1 is >> that everyone supports RSA keys and EC support is very patchy so we >> will emphasize this aspect in bake-offs etc. > >There has been a continuing need to be able to add/replace crypto algorithms. >So the dexterity is a legitimate need, but is not new. And it is already >supported in DKIM. And, really, it has nothing to do with the status of P-Q >concerns. it is mainly about post-quantum if we write MUST for both RSA and EC _and_ enough people use EC to shame the people who ignore that MUST :-) >> Dexterity will become essential if advances in cryptanalysis cause a >> particular type of algorithm to become deprecated. To allow a phased >> switch away from such an algorithm we will make provision for more >> than one signature to be present in a single DKIM2 header. Systems >> capable of checking both signatures will require both to be correct. >> If only one signature is correct then email will be rejected with a >> clear message -- allowing interworking issues to be easily debugged. >> >> 4.9. Reducing crypto-calculations >> >> Experience at large mailbox providers is that incoming messages can >> have large numbers of DKIM signatures all of which need to be >> checked. > >But, do they really /all/ have to be checked? Seriously, why can't there be >some selectivity? They all need to be checked because of feedback loops -- and also it can simplify the way that DMARC is dealt with. >> For DKIM2, in the common case where email has not been >> altered by earlier hops, it will only be necessary to check the first >> DKIM2 signature, the one applied by the previous hop and, if >> "feedback" is to be provided, the signatures of any entities that >> have requested feedback. > >huh? This does not seem at all obvious. nevertheless I believe it to be a correct statement ... which other signatures do you think need to be checked and to what purpose ? >Also, it is not obvious that the current use of DKIM requires checking all the >signatures. Please explain why. see above >> If DKIM-replay is felt to be an issue (and some providers will detect >> this by identifying non-unique signatures) > >Non-unique signatures? Since I am quite sure this does not mean two different >signatures that produce the same value, what does this mean and how is it a >problem? I discuss DKIM-replay in another of these emails so I will not repeat that commentary here >> then more DKIM2 headers >> may need to be processed to establish the veracity of an alleged >> forwarding path. Additionally any attempt to do forensics or to >> assign reputation to intermediates will require more signatures to be >> checked. > >What is meant by forwarding path? the path taken by the email to arrive at the current machine >How is it specified? in the DKIM2 headers >What does it me to >'establish the veracity' of it? is there a correlation between RCPT-TO:<n-1> and MAIL-FROM:<n> ? note that systems which know there is not a correlation can generate a DKIM2 header to show the correlation -- the entity that signs that DKIM2 header will be taking some responsibility (to coin a phrase) for that >As for needing to check signatures by intermediaries, before performing >reputation analysis... yup? What is the problem? - -- 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/l1hmHfC/FfW545EQJTQACeMKA1kmCiECCBRRiFBPbrLzYJitQAoM+I ZXe5VYrnDrnrdx8wekuG73Ac =sUhh -----END PGP SIGNATURE----- _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
