mta-hashcash October 2004

mta-hashcash@lists.lysator.liu.se

4 participants
20 discussions

Updated draft. MTA identification?
by nisse＠lysator.liu.se 24 Jun '26

24 Jun '26

I've updated the draft now (see http://www.lysator.liu.se/~nisse/misc/draft-nisse-hash-cash.txt), trying to address the issues raised by Simon and during the meeting. It now uses per-MTA keys. Then an important question is how an MTA is identified. Ideally, all border-MTA-s belogning to the same administrative domain should have the same identity (except perhaps secondaries). It's not clear if a mail server that accepts mail for multiple domains should have a single id, or one id per domain. I tried to write this down in section 4. Do we need new terminology for the things we identify? It's slightly confusing to say "MTA" when we are talking about not a single mail server, but a fuzzy group of them? Other notable changes: Authentication means signing a challenge string, of the same form as the hash cash challenges. Hash cash challenges now use hmac-sha1, with the string to be search for in the key argument, in order to make the construction somewhat more cryptographically sound. Most of the text on name-key semantics is deleted. /Niels

2 1

Key exchange
by Linus Nordberg 03 Nov '04

03 Nov '04

Should XHASHCASHNEWKEY be accepted only after MAIL and before RCPT, as the draft says? We want a way of charging lots of hash cash for accepting keys. Accepting as non-tentative, that is. We also want accepting of keys to depend on other criterias. But this is all policy. What should the draft say and what are the ideas on how to implement some of the foreseeable policies?

2 6

Forward path vs. recipient
by Linus Nordberg 21 Oct '04

21 Oct '04

What's the relation between the terms "forward path" and "envelope recipient"? The draft says "forward path" nowadays.

2 2

Initial reactions
by Simon Josefsson 21 Oct '04

21 Oct '04

Hello all, I read your draft, belated. I'm sure you have discussed and solved these issues already, but just for reference, below were my initial thoughts on the proposal. I am not fully convinced by section 6 and 9.2, in particular: that it is impossible to abuse the MAC key management scheme. If a spammer can somehow fool you into talking to them, it seem the scheme is ruined. There may be subtle technical issues here. There may even be non-technical concerns with the approach; i.e., merely because you talk to someone doesn't mean you want them to talk to you. If the idea and server implementation mature, I can probably be fooled into implementing some basic support for this in Emacs' smtpmail.el. Thanks. Secondary mail servers ---------------------- There is no discussion how primary and secondary MX's interact, if they do at all. If they are intended to interact, I believe that may be a serious deployment issue. My experience is that secondaries cannot be assumed to have useful out of band communication with the primaries. Inventing and deploying a protocol to keep some information synchronized between MX's appear to me complicated. One of nice properties of the mail system design is that different MX's for a domain can be separated to a big extent, making them interact more closely seem like an unwanted direction. To illustrate the degree of separation between MX's: some secondaries may not even know the complete list of which domains they are secondaries for (see sendmail FEATURE(`relay_based_on_MX')). If however the MX's for a domain are not intended to interact, I guess I do not understand how the secret key authentication is going to work. As far as I understand, the keys are stored in a database indexed on SMTP envelope addresses corresponding to recipient and receiver. Consider then a client that is sending mail to user@domain via mail1.domain and mail2.domain. Which keys are used, and how are they negotiated? One idea: Instead, have the keys be shared between two MTA's, and index the database on MTA names. MTA "A" share a key with MTA "B". Since MTAs can be known under many names, the canonical name should be used, i.e., the <Domain> field of the 220 initial response. Note that policy matters, such as one disabling the use of MAC keys per-user, is still possible with this approach, as far as I can tell. Input to MAC computation ------------------------ The draft says: If a key is found, it is used to form a MAC on data consisting of sender and receiver id (in that order), selected headers, and the message body. The header lines included are From, To, Cc, Date, Content-type and Message-id. They are followed by an empty line, and then the message body, without transport encoding (to allow MTA's to change the transport encoding of messages in transit). The resulting MAC is provided to the receiver during the SMTP transaction. What do you mean by "transport encoding"? MIME Content-Type-Encoding? If so, that appear to require a MIME decoder in the MTA, which is complex. Further, decoding a large e-mail may require large amounts of storage. Not all MIME libraries are written to make one-pass MAC computation easy. Finally, the format of decoded MIME objects is not well defined, which seem to be required for MAC computations. Only the MIME encoding is well defined. One idea: Do the MAC on the data that is actually sent on the wire. Security properties of the MAC ------------------------------ There should be a security section on the highly specialized property required from the MAC: that it is computationally infeasible to produce a prefix MAC value with given value. As far as I am aware, existing MACs are not designed for this property. I suspect this property may collapse into more well known MAC properties. It would be neat if there was a nice reduction from this special property into more well studied properties. I.e., "if you can break the MAC for this property, you can break the same MAC for common MAC properties". Btw, what kind of MAC's are you thinking of? HMAC-SHA1 may be the simplest choice, even though I would prefer something based on a block cipher. The choice of MAC seem critical to get "fair" computation costs, i.e., it should be difficult to optimize the MAC much more compared to typical implementations. MUA discussions --------------- In an ideal world, MUAs don't talk to MTAs, they talk to MSAs. See RRC 2476. There may be some consequences for how the MUA discussions are phrased. One might even consider introducing special protocol elements for MUA<->MSA, to specify policy matters. I'm not sure that is a good idea, though.

3 2

Minor comments to draft
by Linus Nordberg 21 Oct '04

21 Oct '04

In section 5, the terms challenge message and prefix seem to mean the same thing. Typo fixes in attached patch.

2 2

Seminar on spam in Stockholm next tuesday
by Linus Nordberg 19 Oct '04

19 Oct '04

ISOC-SE inbjuder alla intresserade till seminariet ************************************************** SPAM - Vad görs åt det från stat och tekniker? Vilket är värst - plågan eller botemedlet? ************************************************** Alla klagar på vädret men ingen gör något åt det, brukar det heta. Alla klagar också på nät och brevlådor igenslammade med SPAM; vi skall få höra vad som görs åt detta med lag och teknik som verktyg. Ola Svensson, handläggare på Konsumentverket med uppgift att bekämpa SPAM med marknadsföringslagen som medel skall berätta om Konsumentverkets regeltillämpning på området. Amar Andersson, Internetprofil m m på TeliaSonera kommer att berätta om hur spammers agerar idag, hur nätoperatörer gör för att hindra SPAM, och om vilka problem SPAM innebär för nätoperatörerna som ISPer. Slutligen kommer Henrik Nilsson, jurist på advokatfirman Bird & Bird och styrelsledamot i ISOC-SE att reflektera över frågan om botemedlen är nog så illa som plågan vad avser SPAM. Finns det alls förutsättningar för lagregleringar kan ge önskat resultat eller stör de kommunikationerna mer än hjälper? Mer information om seminariet finns på www.isoc.se/ Seminariet är kostnadsfritt och öppet för alla. Inbjudan får vidarebefordras i oförändrat skick. Tid: 26 oktober kl 17.30 - ca 20.00 Plats: Lärarhögskolan i Stockholm, Kyrksalen, Hus Q plan 3. Vägbeskrivning: www.lhs.se/organisation/kartor.html Anmäl dig senast den 22 oktober på e-post <anmalan-sth(a)isoc.se> eller använd anmälningsformuläret på www.isoc.se/ Smörgås och dryck serveras i anslutning till seminariet. Varmt välkomna! ISOC-SE ********************************************************* Björn Ohlsson, Medlemsansvarig Arb: 08 - 737 98 98 Bjorn.Ohlsson(a)isoc.se Mobil: 070 - 539 97 95 ISOC-SE Bost: 08 - 640 75 64 Box 7559 http://www.isoc.se/ 103 93 Stockholm

1 0

Mail flow overview by paf
by nisse＠lysator.liu.se 18 Oct '04

18 Oct '04

While searching for something completely different, I stumbled upon paf's presentation at the marid-bof in February (http://www.imc.org/ietf-mxcomp/Seoul/PatrikFaltstrom/marid-bof.pdf, link also added on our homepage). It contains both an clear list of mail flow cases (relaying, forwarding, etc), and observations like : I am of the view people attack the spam problem from the wrong angle : : Look for a solution : Fine-tune it : Look for a problem the solution solves Regards, /Niels

2 1

Yahoo domainkeys?
by nisse＠lysator.liu.se 18 Oct '04

18 Oct '04

This proposal seems related to our work: http://www.shaftek.org.nyud.net:8090/blog/archives/000148.html http://antispam.yahoo.com/domainkeys Summary, after a quick browsning of the draft: An MTA (usually a border MTA) signs all outgoing mail. The signed data includes the message body and selected headers. Signature is added as a message header. The receiver examines the signature-header, looks up the corresponding public key in DNS, and verifies the signature. The Sender: and From headers are also involved in the verification in some way, but I don't understand precisely how. Potential problems: * MTA have to generate signatures for all outgoing email. (But a mailing list can use the same signature for all copies; that's the traditional scaling advantage of public keys. list-bots usually insert a Sender:-header, right?) * They sign message contents, hence need canonicalization of headers and body. Not kosher from an SMTP-point of view. * I think they have the same problems as us with people using unrelated MTA:s for in- and outgoing email. * Potential patent sillyness, I haven't tried reading Yahoo's patent license carefully. Like spf, I don't think it's particularly useful in itself, but it may be another way to let mail from white listed domains bypass hashcash. Regards, /Niels Möller

1 0

Filtering headers draft
by Linus Nordberg 14 Oct '04

14 Oct '04

Here's the draft I mentioned yesterday: http://millenix.zemos.net/asrg-filtering/draft-irtf-asrg-filtering-header.h…

1 0

Issues identified during todays meeting
by nisse＠lysator.liu.se 13 Oct '04

13 Oct '04

For the record, I'll list the most important issues identified during today's meeting. 1. It's undesirable that the MAC is computed over the message body. One possible alternative is to compute the MAC over a string constructed from envelope sender + receiver + salt, where the salt is chosen randomly by the receiving MTA. This is analogous to the things that go into a hash cash challenge string. 2. Asymmetric transport, where an email and a reply are relayed through different administrative domains. Example: Home user with a vanity domain and email address user(a)vanity.org. There's an MTA for vanity.org than handles incoming mail, but all outgoing mail is relayed by an ISP MTA acting as a relay, e.g. mail.telia.com, totally unrelated to vanity.org. If this user subscribes to a mailinglist, the mecahnism for automatic key setup will fail. 3. Communication between MTA and MUA. Current plan is that the MTA inserts a header analogous to the Received:-header, saying which authentication have been used. The MTA should also have a control-address, which users and MUA:s can use for configuring the MTA. These control messages need some kind of authentication. 4. The hash cash protocol probably needs a way that lets a client MTA disconnect, solves the challenge off-line, and reconnect and provide the answer later. Perhaps we can use confirmation emails, analogous to those used by mailing list software. In general, it's preferable that the MUA and MTA communicate by email, rather than by SMTP or by some other protocol directly on top of TCP. Regards, /Niels

1 0

2026

2025

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