Jonathan Morton | 1 May 2004 01:44
Picon
Picon

Re: 3 (Message Verification) - Viability of hashcash-based signatures (was: E-postage from first principles)

> - The stamp optionally includes a signature to facilitate 
> whitelisting.  This can reduce the hashcash demanded from regular 
> correspondents to as low as 8 bits, which is computationally 
> trivial...
>
> ...If nobody happens to have a Z80 and a compiler to hand, I'll put in 
> some work and try it for the 6502 instead - I have a handful of old 
> BBC Micros lying around.

To answer my own question, I've worked out that a 6502 can process an 
SHA-1 block in about 40000 cycles, which compares surprisingly well to 
the 68030 (and begs an investigation into precisely why the '030 is so 
inefficient).  This is completely untested code - I didn't even type it 
into the machine, just worked out the timing piecemeal from the 
assembly manual - but the ballpark figure should be accurate.

To put this in perspective, it means that my 1982-vintage BBC Micros 
(with 2MHz 6502 chips) should be able to mint 8-bit hashcash in about 5 
seconds on average, and most other 8-bit accumulator machines 
(including the Z80 family) should be comparable.  This, in turn, means 
that my whitelist-grade signature scheme should be computationally 
feasible for pretty much every "computer" capable of running a TCP/IP 
stack.  This encourages me to continue working on a more detailed spec 
for discussion.

Code size may be more of a problem, however, as the 40000-cycle 
performance assumes a fairly unrolled-loop code configuration, which 
consumes a significant portion of a 16-bit address space (exact size 
not calculated, but 4-8KB is possible).  It also assumes a fixed area 
of RAM, including 25 bytes of zero page and 340 bytes elsewhere, is 
(Continue reading)

Chris Lewis | 2 May 2004 05:03

Re: draft-irtf-asrg-bcp-blacklists-00

Matt Sergeant wrote:

> On 30 Apr 2004, at 15:30, Seth Breidbart wrote:
> 
>>> Perhaps 2.2 should say "Failing to meet the criteria for listing MUST be
>>> sufficient grounds for delisting".

>> Why?  I see no problem with a "sticky" list; for instance, to get
>> listed an IP must send >X amount of spam in Y time, to get unlisted it
>> must send <.1X in 10Y.

> Because this is confusing.

> However I don't think it's entirely incompatible with the BCP. The 
> listing criteria could be as simple as "We have detected spam coming 
> from this IP address". How you "detected" it (by spam levels exceeding a 
> threshold) and how you "undetect" it is up to you.

I agree.  The intent was to "frown" on delisting requirements orthogonal 
to the listing.  Like payment of fees, or other things that had nothing 
to do with the listing.

An element of hysteresis (ie: timewise or thresholdwise) is okay, IMO.

I think I prefer Tony's wording.
Yakov Shafranovich | 2 May 2004 09:03

0. General - Chatroom information

I added info on the ASRG chatroom to the homepage:

http://asrg.sp.am/about/chatroom.shtml

Schedule of chats is in the ASRG wiki:

http://asrg.sp.am/wiki?ChatSchedule

Yakov
--
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"Some lies are easier to believe than the truth" (Dune)
Yakov Shafranovich | 2 May 2004 09:07

0. Administrative - Next ASRG meeting

We are planning on holding a physical meeting for the ASRG at the 60th 
IETF in San Diego, CA during the week of August 1-6, 2004. Information 
on the meeting will be posted here:
http://asrg.sp.am/about/meetings.shtml

Information on IETF's 60th meeting can be found here:
http://www.ietf.org/meetings/IETF-60.html

If you want to present, please contact the chairs at <chairs <at> asrg.sp.am>.

Yakov
--
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"Some lies are easier to believe than the truth" (Dune)
Yakov Shafranovich | 2 May 2004 09:47

0. General - ASRG Wiki

There is a wiki now available at the ASRG site:

http://asrg.sp.am/wiki

Yakov
--
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"And this too shall come to pass"
Bill Cole | 2 May 2004 05:36

Re: draft-irtf-asrg-bcp-blacklists-00

At 11:03 PM -0400 5/1/04, Chris Lewis wrote:
>Matt Sergeant wrote:
>
>>On 30 Apr 2004, at 15:30, Seth Breidbart wrote:
>>
>>>>Perhaps 2.2 should say "Failing to meet the criteria for listing MUST be
>>>>sufficient grounds for delisting".
>
>>>Why?  I see no problem with a "sticky" list; for instance, to get
>>>listed an IP must send >X amount of spam in Y time, to get unlisted it
>>>must send <.1X in 10Y.
>
>>Because this is confusing.
>
>>However I don't think it's entirely incompatible with the BCP. The 
>>listing criteria could be as simple as "We have detected spam 
>>coming from this IP address". How you "detected" it (by spam levels 
>>exceeding a threshold) and how you "undetect" it is up to you.
>
>I agree.  The intent was to "frown" on delisting requirements 
>orthogonal to the listing.  Like payment of fees, or other things 
>that had nothing to do with the listing.
>
>An element of hysteresis (ie: timewise or thresholdwise) is okay, IMO.
>
>I think I prefer Tony's wording.

I agree but it remains imperfect.

It is a matter of phrasing of criteria to some extent. e.g. for the 
(Continue reading)

Matt Sergeant | 2 May 2004 21:56
Picon

Re: draft-irtf-asrg-bcp-blacklists-00

On Sat, 1 May 2004, Bill Cole wrote:

> It is a matter of phrasing of criteria to some extent. e.g. for the 
> CBL, if you describe the condition for listing as "having acted like 
> a compromised machine emitting spam within the timeout period and 
> without having since requested removal" then failing to meet the 
> listing criteria does effect a delisting.
> 
> However, this sort of framing of criteria makes room for such things 
> as the SORBS donation requirement.

In designing the BCP we didn't think something like SORBS donation 
requirement should be excluded, so long as this requirement is clearly 
listed on their web site.

Matt.
Walter Dnes | 2 May 2004 23:59
Favicon

Re: draft-irtf-asrg-bcp-blacklists-00

On Fri, Apr 30, 2004 at 03:23:10PM +0100, Matt Sergeant wrote

> Our aim with the BCP was not to fit it around _all_ current practices,
> but to fit it around best practices. If you have good reasons for
> going against the guidelines please state them and we can consider
> the modification of the BCP.

  The BCP document assumes that people are nice, or at least polite.  If
they were, there wouldn't be a need for DNSbl's in the first place.  In
a "kinder gentler" world, paragraph 2.6 MUST-have-a-contact requirement
would make sense.  However, in real life, spammers aren't nice.  Consider
the following...

  - MAPS was sued into uselessness by a bunch of dot-coms flush with
    cash from IPO's who engaged in the lawsuit equivalent of a gang-rape

  - Felstein and company left a bunch of people out of pocket thousands
    of dollars in legal fees, even though the civil complaints were
    dropped and the case never got to trial

  - Scott Richter is currently suing SpamCop

  Unlike British Commonwealth countries (Britain, Canada, Australia,
etc) the USA does *NOT* have an automatic "loser pays" clause for
lawsuits.  The USA gave the world SLAPP.  Would you care to provide
multi-million dollar funds in escrow to defend against such lawsuits and
pay off any stupid judgements awarded by juries?

  And it's not merely a case of money.  I wouldn't be surprised if the
mobsters behind some of the spammers resorted to contract killings to
(Continue reading)

Yakov Shafranovich | 3 May 2004 18:44

0. General - UPDATE on "FCC soliciting comments on mobile spam"

This was sent to me from the FCC.

Yakov

-------- Original Message --------
The initial Comment period for the FCC's wireless spam ruling making
closed on April 30, and the FCC is now accepting Replies to those
comments through May 17. The comments that were submitted can be
reviewed by going to the FCC's Electronic Comment Filing System search
page at http://gullfoss2.fcc.gov/prod/ecfs/comsrch_v2.cgi and searching
on the proceeding "04-53".

General information about the subject of this rulemaking is available at
http://www.fcc.gov/cgb/policy/canspam.html.  This includes a summary of
the questions of interpretation and technical solutions that have been
addressed in the comments received to date.

Individuals or groups interested in filing comments (e.g., in response
to the Comments received to date) can find detailed instructions on how
to file Reply comments in Paragraphs 56-60 on p. 23 of the Notice of
Proposed Rulemaking at
http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-04-52A1.doc.
Comments for this proceeding can also be easily filed using the FCC's
ECFS Express option, at http://gullfoss2.fcc.gov/ecfs/Upload/.

--
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"Some lies are easier to believe than the truth" (Dune)
(Continue reading)

Sauer, Damon | 3 May 2004 19:19
Favicon

News: Postini patents the relay server?

http://www.eweek.com/article2/0,1759,1568961,00.asp

*****
"The information transmitted is intended only for the person or entity to which it is addressed and may
contain confidential, proprietary, and/or privileged material.  Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.  If you received this in error, please contact
the sender and delete the material from all computers."  113

Gmane