From: Andriy G. T. <dk-...@sp...> - 2004-07-17 03:18:35
|
Hi, As I understand - the weakest part of DomainKeys are canonization and signature verification. Canonization is not trivial and signature verification is CPU expensive (IMHO, not so expensive, virus scanners and current spam filters burn even more CPU cycles). In case if we will be unable to find correct canonization algorithm - a lot of legit emails modified during transit will go to "DomainKey-Status: bad" category. I would like to avoid this. As a work-around I would like to add additional (possibly optional) header DomainKey-Hash and category "suspect" Proposed categories are: Ok Suspect (most likely okey, user have to check) Unknown (nothing known to program about this) Bad Based on my understanding of cryptography - signature created for hash code calculated, not for entire message text (correct me if I'm wrong, cryptography is not main specialization area). As result we can avoid hash code recalculations using pre-calculated value from header. Proposal summary: a) Add "DomainKey-Hash: a=rsa-sha1; c=simple; HasHcOdEVaLuEGoeShErE==" header with hash code for message calculated. It's possible to have multiple headers in message for different canonizations and hash algorithms. It's possible to not have any; recalculation of hash code will be required, but this will possibly save space if bulletproof canonization will be developed and widely installed. b) Add "DomainKey-Timestamp: 2015-07-15 05:29 FLE" optional header to define or override "Date:" header value. Use this timestamp to prevent hash code signature reuse. Outdated signatures will be marked as suspect. c) Add "DomainKey-To: us...@do..." optional header to define or override "RCPT TO" (or vendor-specific headers like X-MDaemon-Deliver-To:, X-MDRcpt-To: ) data with email of recipient. Email not addressed to known user addresses will be marked as suspect. New algorithm to validate signature will looks like: // By default no information status := "unknown"; // Not a DK email, unknown If NotFoundHeader(DomainKey-Signature) { return; } // DK email If FoundHeader(DomainKey-Hash) { // Validate signature against hash code precalculation If(Not ValidateSignature(GetAllHashes(DomainKey-Hash) + To + Timestamp)) { // Signature is invalid Somebody failed to sign it correctly Status := "bad"; return; } // Check if message signed not so long time ago // MAX_SUSPECT_AGE are 7-10 days. It must be over maximum delivery time for legit email If(GetDateOrTimestampValue() + MAX_SUSPECT_AGE < Now()) { status := "bad"; message += "Timestamp expired. Too old message"; return; } // MAX_VALID_AGE are 1-3 days. It's based on average delivery time for legit emails If(GetDateOrTimestampValue() + MAX_VALID_AGE < Now()) { status := "suspect"; message += "Timestamp expired but looks like still valid"; } // Check if message was addressed to us // BTW, Currently DK does not perform such a check // I can resent valid DK signed by others people messages anytime I wish to anybody If(not GetRecipientOrTo() in myAddressesList) { status := "suspect"; message += "Message was not addressed to you"; } // Our server is paranoid It's nice to be paranoid if you have CPU resources // Validate if any or hashes/canonisations will calculate correctly for message we recieve If(Paranoid && NoOneHashCanonizationPassedValidation()) { status := "suspect"; message += "Message was modified in transit or wrong hash/canonisation used"; } else { status := "ok"; message += "Warning: No hash code validation performed"; } // If nothing bad or suspect found - looks like valid message // But here can go additional validations if we already recieved message with same signature // during MAX_AGE time // It's suspect to recieve the same message more then one If(status=="unknown") status := "ok"; return; } else { // No precalculated hash-code // Use regular DK pass or fail validation. Nothing in middle if(ValidSignature()) { status := "ok"; } else { status := "bad"; } return; } Tradeoff - space consumed by hash code. To make it possible to get rid of this tradeoff in future we can mark Hash as an optional header. In future then realible canonisations will be developed or MTAs will not modify emails this header will not be activly used. What do you think about this proposal ? -- Andriy G. Tereshchenko TAG Software Odessa, Ukraine http://www.24.odessa.ua |