mta-hashcash October 2004

mta-hashcash@lists.lysator.liu.se

4 participants
20 discussions

Re: Hantering av felaktig hash
by Linus Nordberg 08 Oct '04

08 Oct '04

nisse(a)lysator.liu.se (Niels Möller) wrote 04 Oct 2004 15:17:12 +0200: | > | Sen finns det ju ett till felfall, som vi behöver lösa: Om servern | > | verkligen kräver autenticering eller hash-cash för en mottagare, och | > | klienten inte tillhanda håller något sånt. Hur förklarar man för | > | klienten att den här mottagaren tänker jag inte leverera till? | > | > Just. Hur pekar man ut en falerande av flera mottagare så sent i | > proceduren? Risken finns att SMTP förutsätter att man vet det redan | > när man besvarar RCPT. Kanske tolkas svaret på DATA som ett svar för | > hela transaktionen? | | Jag tror man definitivt *vill* ge felkoden före DATA. Om det krävs för | att kunna ge rätt felkoder, så får vi nog organisera om protokollet | och göra hash-cash-grejerna före RCPT. Före RCPT? Jag hänger inte med. Menar du "före DATA"? För hash-cash funkar det, men det blir kruxigt att göra MAC på header och body innan DATA, för autenticering. | Det är inte bra att generera studsar för saker som troligen är spam. Sant. Relevant avsnitt i RFC 2821, ang. DATA: The SMTP model does not allow for partial failures at this point: either the message is accepted by the server for delivery and a positive response is returned or it is not accepted and a failure reply is returned. In sending a positive completion reply to the end of data indication, the receiver takes full responsibility for the message (see section 6.1). Errors that are diagnosed subsequently MUST be reported in a mail message, as discussed in section 4.4. | > Man bör också tänka på att snabba sig på med svar på <CRLF>.<CRLF> för | > att undvika duplicerade meddelanden (RFC 1047). | | Ganska gammalt dokument, status UNKNOWN. Hur relevant är det? Att man | inte ska vänta flera minuter innen man svarar är ju rimligt, men vi | borde väl inte införa några längre fördröjningar där? Vi ska bara | beräkna en MAC på brevet, och huvuddelen av jobbet kan vi i princip | göra medan vi tar emot det (lite beroende på hur kommunikationen | mellan smtp-servern och local-delivery-program ser ut). Men jag tycker | inte det känns som att det borde vara ett stort problem, min laptop | kan processar drygt 60 MB/s med sha1. Du har rätt. | > Förresten, har du funderat på om det finns några problem med bcc? | | bcc tror jag är lugnt, men jag har inte tänkt så noga på det. | Forwarding är lurigare. Har jag redan skrivit om det här? Annars tar | jag och skriver om det på mailinglistan istället. Du har inte pratat om forwarding ännu.

3 15

Forwarding, and per-user keys
by nisse＠lysator.liu.se 08 Oct '04

08 Oct '04

How does forwarding fork, and why is it a problem? Assume that mail for fred(a)f.com forwards mail (via a .forward or aliases file) to ron(a)r.com, and stay stan(a)s.com sends an email to fred. There will be two smtp transactions. The first between the s.com and f.com MTA's, which will use MAIL FROM <stan(a)s.com> RCPT TO <fred(a)f.com> The next is between the MTA's for f.com and r.com, which will use MAIL FROM <stan(a)s.com> RCPT TO <fred(a)f.com> The problem here is that the f.com MTA sends mail on behalf of a user that "really" belongs to a different MTA, for s.com. So this is just a special case of relaying. So which keys should be involved? The first transaction involves a key for <s.com, f.com>, no problem there. The second transaction, between f.com and r.com, must use a key shared by those two mail servers (since the key for <s.com, r.com> is not known to f.com). So we use a key that has no obvious relation whatsoever with the address given in MAIL FROM. And we must make this case work. We also need to make more general relaying work. Consider the organization "Telia home users" which have a border MTA telia.com or some such, handling all out-going email. The users have arbitrary from addresses, unrelated to telia.com, which acts as a relay or "smarthost". The natural conclusion is that we must drop the notion that the keys can be used to authenticate the from address. A key can only be used to authenticate the MTA which owns it. And following this way of thinking, we have no use for per-user keys. (End-to-end per-user authentication is still a nice thing to do, but it can't work out-of-the-box with forwarding. When setting up a forward, the user must transfer his or her keys from the old place to the new place. Fortunately, that's not the MTA's problem). And one more forwarding comment: It would make sense to have an SMTP reply code that means "temporary redirect", 451 address forwarded to <some(a)where.else> and make it the clients responsibility to contact the right MTA server. This is analogous to 251 and 551, which are rarely used, and to HTTP redirects, which are used quite a lot. This could be done independently from our hash cash work, but I don't think it is worth the effort, since (i) it helps forwarding, but it can't replace general relaying, (ii) nobody uses 251 and 551 anyway, why would they use 451?, and (iii) it's probably too common with forwards that go to internal addresses and mail servers that aren't reachable from the Internet Regards, /Niels

2 2

Which recipient are we authenticating for?
by Linus Nordberg 07 Oct '04

07 Oct '04

We need a way to express which sender/recipient pair a given XHASHCASHAUTH is authenticating, in the case of multiple RCPT TO. The verifying server could calculate MAC for all recipients and try to match each an every one but that feels a bit annoying.

2 1

#mta-hashcash @ freenode
by Linus Nordberg 06 Oct '04

06 Oct '04

Are any of you into this IRC thing? We could meet at #mta-hashcash @freenode.net. I'm quite fond of that kind of communication.

2 2

Authentication header format
by Linus Nordberg 06 Oct '04

06 Oct '04

Draft, section 5 suggests that a header is added to messages that are successfully authenticated. o Add a header field, recording the result. If no MAC is provided, or the MAC is invalid, the server may require a hash cash transaction, and it should delete any possibly faked header in the incoming mail, that says the MAC was valid. Any ideas on what the header should look like?

2 1

[Niels Möller] Re: Auth efter challenge?
by Linus Nordberg 06 Oct '04

06 Oct '04

For the record. In swedish, unfortunately.

1 0

Typo in draft?
by Linus Nordberg 06 Oct '04

06 Oct '04

Index: draft-nisse-hash-cash.xml =================================================================== RCS file: /cvsroot/mta-hashcash/mta-hashcash/doc/draft-nisse-hash-cash.xml,v retrieving revision 1.1 diff -c -p -c -p -r1.1 draft-nisse-hash-cash.xml *** draft-nisse-hash-cash.xml 29 Sep 2004 19:10:16 -0000 1.1 --- draft-nisse-hash-cash.xml 6 Oct 2004 13:22:34 -0000 *************** *** 217,223 **** <figure> <preamble>Syntax:</preamble> <artwork> ! challenge = "XHASHCASHRESPONSE" SP method SP text CRLF </artwork> <postamble>The method must match the given challenge, and the text depends on the method. --- 217,223 ---- <figure> <preamble>Syntax:</preamble> <artwork> ! response = "XHASHCASHRESPONSE" SP method SP text CRLF </artwork> <postamble>The method must match the given challenge, and the text depends on the method.

1 0

Reference list
by nisse＠lysator.liu.se 05 Oct '04

05 Oct '04

For convenience, I've put together an html-version of Linus' reference list, as well as links to our files etc, at http://www.lysator.liu.se/~nisse/misc/mta-hashcash.html The files are also in the doc-directory in the cvs, feel free to add more references, or comment on the scope and relevance of the documents. Updating the files on the web requires a manual cvs update && make install-www WWWDIR=webdir on the right machine, so prod me whenever the www version seem out of sync. Regards, /Niels

1 0

Re: Test-implementation
by nisse＠lysator.liu.se 04 Oct '04

04 Oct '04

Linus Nordberg <linus(a)nordberg.se> writes: > nisse(a)lysator.liu.se (Niels Möller) wrote > 28 Sep 2004 09:16:35 +0200: > > | resource bör nog innehålla avsändare och mottagare (från > | smtp-kuvertet) och slumpmässigt salt (som bestäms av servern). > > Behöver vi plocka isär resource igen, tro? I sådana fall behöver vi en > separator mellan komponenterna. Inte ':'. Some answers to related questions: * The client must check that the resource string is constructed according to the rules, in order to avoid interleaving attacks. * I think the most robust way to achieve that is to let the client construct the resource string independently. The server only sends the salt in the challenge message. * I think it's good cryptographic practice to have the function that constructs the resource string from its inputs be collision free. I.e. there should not be two sets of input that results in the same resource string. The simplest ways to do that is to either use unique separator (if a suitable character exists), or add explicit length prefixes to each component. > | Datumet tror jag inte spelar så stor roll för oss. Men ska det > | verkligen bara vara två siffror för årtalet? > > Det är tydligen default. Man kan visst välja mellan 6, 10 och 12 med > `-z'. What does the ten-chracter format look like? 6-character dates is just too stupid for this millennium. > Skall epost-listan hållas på engelska tycker ni? English makes some sense, even if at the moment you and I are the only two subscribers. One other comment: I noticed that you refer to RFC 821 in the comments in your code. You should also look at the updated version, RFC 2821. /Niels

2 5

Re: Avskräckt?
by nisse＠lysator.liu.se 04 Oct '04

04 Oct '04

Linus Nordberg <linus(a)nordberg.se> writes: > http://www.cl.cam.ac.uk/users/rnc1/proofwork.pdf Now I've read that article. I didn't really try follow all the juggling and hand-waving with numbers. As I understand the conclusions, these are the important points as they apply to us: 1. We must be prepared to use challenges that take several minutes to solve. 2. To make things work for legitimate email, one must use a some "hybrid system" where hash-cash is used only occasionally for legitimate email. 3. The effectiveness depends on many hard-to-estimate factors, such as to number and cpu power of machines "0wned" by spammers. As for 2., that's exactly what we're doing. For 1., it seems we will make SMTP transactions take considerably longer time, and that "smarthost" MTA:s will easily get into trouble if for some reason the authentication mechanism doesn't work. Regards, /Niels

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mta-hashcash October 2004