Sender authentication?
Nick Ing-Simmons
I hope this isn't re-hashing old ground but an idea has occured to me
that would, I think, help with the current deluge of mail from worms that
forge From: addresses.
The idea is to "sign" the From: and Message-ID: pair using
a public key scheme, and add the signature as a new header.
The goal is to allow recipient to have some confidence that mail is
really from the sender without collecting the whole mail, but just
by examining the headers. (Signed mail is all very well
but sucking 5M of spam body to allow me to check it isn't helping
with my bandwidth problem.)
(I currently discard any mail which has its Message-ID inserted
by my ISP - this is wonderfully successful for an ad. hoc. hack
e.g. it managed to discard 80% of the 10000 emails I received
in one day of recent MyDoom peak. Snag is that there are
presumably false discards - including mails from my ISP!)
The idea is that the unique Message-Id is a "challenge" for the sender's
key pair.
As many tools also discard mails with duplicate ids then forger
cannot just re-use signature headers from a previous mail.
Issues I can see are where public key comes from (key server or embedded in the
mail) and possible size of key and signature data.
Is this worth discussing further?
--
Nick Ing-Simmons
Andrzej Filip
Nick Ing-Simmons wrote:
>
> I hope this isn't re-hashing old ground but an idea has occured to me
> that would, I think, help with the current deluge of mail from worms that
> forge From: addresses.
>
> The idea is to "sign" the From: and Message-ID: pair using
> a public key scheme, and add the signature as a new header.
How do you want to check signature validity for John Doe ?
Do you want to use it only for "well known friends" ?
> The goal is to allow recipient to have some confidence that mail is
> really from the sender without collecting the whole mail, but just
> by examining the headers. (Signed mail is all very well
> but sucking 5M of spam body to allow me to check it isn't helping
> with my bandwidth problem.)
Only POP offers an option to download headers without body. Well behaving SMTP
servers can not accept headers but refuse to accept body.
Virus on A person host can "reuse" signature of B->A message to fake B->C message.
> (I currently discard any mail which has its Message-ID inserted
> by my ISP - this is wonderfully successful for an ad. hoc. hack
> e.g. it managed to discard 80% of the 10000 emails I received
> in one day of recent MyDoom peak. Snag is that there are
> presumably false discards - including mails from my ISP!)
Viruses get smarter every outbreak.
> The idea is that the unique Message-Id is a "challenge" for the sender's
> key pair.
>
> As many tools also discard mails with duplicate ids then forger
> cannot just re-use signature headers from a previous mail.
>
> Issues I can see are where public key comes from (key server or embedded in the
> mail) and possible size of key and signature data.
>
> Is this worth discussing further?
The idea is good BUT IMHO signing Sender, Recipient, Message-ID, Date makes
more sense.
* "Date:" signing would prohibit "reuse" of signatures.
* Recipient signing is tricky vide signing BCC: recipients
--
Andrzej [en:Andrew] Adam Filip http://anfi.freeshell.org backup: an...@xl.wp.pl
Charles Lindsey
>I hope this isn't re-hashing old ground but an idea has occured to me
>that would, I think, help with the current deluge of mail from worms that
>forge From: addresses.
>The idea is to "sign" the From: and Message-ID: pair using
>a public key scheme, and add the signature as a new header.
Yes, it can be done, and indeed it has been done and is in regular use for
signing Control Messages on Usenet, and less regularly so for signing
moderated articles.
The bad news is that the protocols for the two purposes are different and
incompatible and suffer from various limitations which make them
unsuitable for general use.
1: PGPVerify is used for signing control messages. The signature header
includes a list of the other headers included within the signature. Its
canonicalization is minimal (e.g. doesn't understand folding).
2: PGPMoose is used for signing moderated articles. The list of headers
included within the signature is fixed and non-configurable. Its
canonicalization is a little better.
Both of the above suffer from the disadvantage that they also include the
whole of the article body within the signature. That should have been a
configurable option IMHO (so, for example, changes of CTE en route would
break it, though that is also true of PGP-Mime).
3. www.landfield.com/usefor/drafts/draft-lindsey-usefor-signed-01.txt.
This is unfinished work intended to overcome the problems identified
above. Its most notable feature is an exceedingly comprehensive
canonicalization scheme. Probably too comprehensive in some ways and
insufficiently comprehensive in others. I would probably do it differently
if doing it again. Not implemented, except for on a demonstration basis in
Perl.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: c...@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
Andrzej Filip
Nick Ing-Simmons wrote:
> Andrzej Filip <an...@priv.onet.pl> writes:
>>[...]
>>* Recipient signing is tricky vide signing BCC: recipients
>
> of mail I receive via BCC anyway.
What would you say about mailing lists ?
> [...]
Bruce Lilly
Nick Ing-Simmons wrote:
[...]
> The idea is to "sign" the From: and Message-ID: pair using
> a public key scheme, and add the signature as a new header.
> The goal is to allow recipient to have some confidence that mail is
> really from the sender without collecting the whole mail, but just
> by examining the headers. (Signed mail is all very well
> but sucking 5M of spam body to allow me to check it isn't helping
> with my bandwidth problem.)
> The idea is that the unique Message-Id is a "challenge" for the sender's
> key pair.
>
> As many tools also discard mails with duplicate ids then forger
> cannot just re-use signature headers from a previous mail.
>
> Issues I can see are where public key comes from (key server or embedded in the
> mail) and possible size of key and signature data.
>
> Is this worth discussing further?
Probably. There has been some limited discussion about something like
that here; some issues are mentioned in the message archived
at http://www.imc.org/ietf-822/mail-archive/msg03987.html
and a brief outline of how keys might be handled via an SMTP extension is
in http://www.imc.org/ietf-822/mail-archive/msg03941.html
The hashing method needs to be robust in the face of header field rewriting.
Although message-ids are supposed to be unique, not all systems discard messages
with duplicates, permitting a replay attack. Moreover, if an attacker is able
to replay the fields and signature quickly, such that both a genuine message and
a forgery arrive in the same batch, which one gets discarded by a system that
does discard duplicates may depend on order of retrieval.
The From field is probably not the right source for sender information. It may
contain multiple addresses (which key would you use in that case?). A better
choice would be the sender envelope address, which appears in the Return-Path
field on final delivery. However, the sender envelope address may be an empty
path (e.g. for a delivery status notification), so that's not universally
applicable either.
#################################################################
#################################################################
#################################################################
#####
#####
#####
#################################################################
#################################################################
#################################################################
Bruce Lilly
Andrzej Filip wrote:
> Only POP offers an option to download headers without body.
I believe IMAP has the same capability.
Keith Moore
> I hope this isn't re-hashing old ground but an idea has occured to me
> that would, I think, help with the current deluge of mail from worms that
> forge From: addresses.
>
> The idea is to "sign" the From: and Message-ID: pair using
> a public key scheme, and add the signature as a new header.
You need to sign the message content. Otherwise a worm could take a From and
Message-id from a completely different message and prepend it to its own
message.
You don't want to use From as the sender identity, because there are perfectly
legitimate cases where From is different from the actual sender. You don't
want to use Return-Path either, because that's where bounces go and there are
sometimes good reasons to send bounces to a different place than the address
associated with the sender's identity. The Sender field was originally
intended for this purpose but that's been corrupted due to wide misuse by
mailing lists. So you need a separate identity for "the person who signed the
message".
Of course if you just want to sign messages then S/MIME will do the job. What
you seem to want is to make it difficult for worms to forge messages. That's
very tricky because the sender's machine has already been compromised. So for
instance the worm could set itself up to record the sender's password (or
whatever is used to encrypt the signing key) whenever it was typed in, and the
worm could sign messages on behalf of that person. It could even transmit
that person's public key to other machines so that the other machines could
sign messages from that person.
To really fix the spam problem, and the virus/worm problem, Windows needs to
be eradicated and replaced with something that actually has some degree of
security. That's a bit over-simplistic, but it's close.
Keith