Howdy folks, Here's some feedback after a reading of the draft at https://datatracker.ietf.org/doc/draft-ietf-dkim-dkim2-motivation/02/
*1. "ARC describes a separate "Seal" header which which never gets"* which which -> which *2. 3.2. Backscatter* Privacy-preserving forwarding services will also see every bounce > from any dkim2-supporting destination mailbox, allowing them to strip > off the details of the further hop(s) and generate a bounce as if > they had been the terminal node of the delivery and were just making > a delayed decision. Is this saying that a message goes through a -> b -> c -> d, d generates a bounce back up the chain, and b can pretend it was the one generating the bounce? If so, won't that make debugging bounces so much harder? *3. 4.1. Algorithmic dexterity* The final specification will require both RSA and elliptic curve be > implemented for algorithmic agility. However this document > acknowledges the long standing lack of adoption of elliptic curve > ,and elliptic curve support may not be needed for development. That ',' on ",and" is in the wrong place *4. 4.2. Sender indications of intent* Having a way to indicate "this message will be useless after time X" > will be useful for things like confirmation codes which have limited > validity, allowing intermediate systems to return the message if they > haven't been able to complete delivery by the expiry time. This is useful for senders maybe, but if the recipient never even receives the message because it was delayed and then returned, they can't themselves see that it's working, just really slowly, and figure things out themselves. That would be frustrating, since in the end it will look to them like the messages were lost somewhere. *5. 4.4. Simplification of signed header list* Currently DKIM signatures list a particular number of copies of each > header field which are included in the signature, and the signer can > choose exactly which headers to sign. > > It is both valuable to mandate a set of headers, and the existence of > a change algebra will allow us to insist that all copies of a named > header field are always signed, reducing the risk of header stuffing > attacks. What is a header stuffing attack? A link to documentation could be useful. *6. Two other minor nits/thoughts:* * “Algorithmic dexterity” section also mentions “algorithmic agility", should we stick to one phrase? * “algebra” - This is used in a few places where I feel like “algorithm” would work just as well and be less odd? Thanks, -- Matthew Horsfall (alh)
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
