...for authentication it sure ain't. Supposing I give you a securely locked box for which only you have the key. On top of this box is a loose pile of fine crystelline powder. I told you last week that the powder is sugar, and I added that since the box is locked it's safe to say that the powder hasn't been tampered with. Is there anything wrong with this picture?
PGP. The content assurer. It takes text, and turns it into signed and/or encrypted text, a beautiful testament to the ability of military grade encryption to enable the world to communicate securely and freely. Except... it's processing the wrong stuff. Take e-mail for instance.
If I create an encrypted email, there's one thing that no PGP or S/MIME strategy has ever bothered to address, apparantly. The email headers are not processed. That's the equivalent to locking the box, then pouring the sugar on top! What it means is even if you know that Lucy wrote a certain section of text within the email, you have no way to know where it came from, or even which message it is. I realized this when I was trying to use PGP to prevent an attacker from posting mounds of malicious spam onto the list, in an attempt to drown everyone else out. I realized that there was literally no way to stop an attacker who just copied one of the messages already posted, and reposted it ad-infinitum, forging the headers. The list would fill up with oodles and oodles of identical messages, and the list members could do nothing but walk away in disgust.
This is exactly the sort of thing PGP should be able to prevent though! I should be able to select a key whom the attacker must use, and ban all their messages from the list. Unfortunately though, it's impossible, because PGP does not sign the message headers. It only signs the message body, or worse, pieces of the message body. The only way to be secure though, is for it to sign the entire message, headers, body and all.
...so I propose an extension to RFC 822. A message can be signed, but not encrypted. The entire message is signed using the ASCII plaintext method, and the signature is appended at the end of the message, after the optional " --" style signature. The difference with the current plaintext signing method is, with this method not just the body, but also the headers are included in this signature.
To allow relay servers to add headers without invalidating the signature, all signed messages should have as their first header "Signed:" containing the algorithm used for signing. No intermediary server is allowed to change the order or contents of the headers including or below that, since the signature requires not a bit of data is touched. They can however, refuse messages based on its contents as usual. Not being able to screw with stuff is a Good Thing in my opinion.
The mail client that signs the message MUST include a Message-ID field, and that field must be unique. Uniqueness (and standard RFC 822 header character limits) is the only requirement to this message ID, but I recommend using a timestamp for the Message-ID, possibly extended once the epoch has rolled over.
Anyone not adding headers, or changing headers, can operate normally as before in their role of delivering the message. I recommend that higher headers in the stack take precedence, but that might operate in reverse even, say if for instance a broken, or malicious server adds strange From: lines to the message. Then you'd consider lower From: lines to be more authoritative. Higher Received: lines would be more authoritative however. "From:" for instance would now be unique, and also read-only, so mailing list software would have to leave it alone like they're supposed to.
Any server along the way is free to validate the signature, provided they understand the algorithm in "Signed:". Invalid signatures indicate corrupted or faked messages, and can be either trashed or bounced. Any server along the way is free to record the Message-ID within the signature. If a second message comes through with the same signature and the same Message-ID, it can be considered redundant and trashed.
I think adding a requirement to maintain order of RFC 822 headers is a small price to pay for absolutely assured email transmissions. Also the requirement for the generator to assign a Message-ID isn't very out of line, since if the Signed: header is not present, the MTA is free to assign an automatic Message-ID as the old method is wont to do. This method would be backwards compatible, since the only change to the contents of the message would be a little bit of PGP data appended to the bottom, and the addition of Signed: headers. Old format messages wouldn't be authenticated at all, but they'd still be transmissible.
Clients have the option of adding headers above the Signed: header, just like everyone else. The headers above must NOT be included in the signature however, and are not considered authoritative, merely informative.
Anyone have a better idea? All I've been able to find besides this is that stupid, "Callback your ISP to verify your DNS entry" hackish junk that doesn't really help the problem. I'm curious what holes remain in my reasoning, and what might be done to patch them up and make this into a coherent working draft.
Comment
Index
Previous
(Another Productive Day)
Next
(Burned for Long Hair)