**** BEGIN LOGGING AT Sat Feb 28 19:02:46 2004

19:02:46 -->	You are now talking on #srs
19:15:40 <freeside>	the woodhouse attack exploits the short-circuiting feature of SRS to fool Victim into sending mail to Yahoo.
19:15:40 <freeside>	previously, SRS short-circuiting would leave A and B in the address, and allow D to replace C and E to replace D.
19:15:41 <freeside>	A->B->(C->D->...X-1)->X
19:15:51 <freeside>	only A, B, and X are preserved in the first form of SRS1 shortcutting.
19:15:51 <freeside>	the new proposal is to preserve A, X-1, and X.
19:15:51 <freeside>	if X is victim and X-1 is the attacker, it becomes X-1's responsibility to send mail to A.
19:15:52 <freeside>	a bounce received by X would be sent to X-1.
19:15:57 <freeside>	now, of course, the attacker can always just forge X-1 to be yahoo.
19:15:57 <freeside>	but that is no different from the existing joe-job loophole in SMTP without SPF.
19:15:57 <freeside>	to close the existing joe-job loophole, we recommend that yahoo publish SPF records.
19:15:58 <freeside>	if they do so, then the spammer is unable to make X-1 appear to be Yahoo.
19:16:10 <freeside>	 
19:16:24 <freeside>	The conch passes to ... Shevek!
19:28:49 <grumpy>	Right now, to prevent joe-jobbing someone, you can reject the message during the SMTP session.
19:29:20 <grumpy>	with SRS1, you always accept the bounce from someone else, and then send it.
19:29:46 <grumpy>	also, if X is also the badguy, an unlimited number of bounces can be sent back through x-1
19:35:18 <freeside>	no you don't.
19:35:24 <freeside>	you do SPF before SRS when receiving an SRS return.
19:35:48 <freeside>	i'm assuming we want to protect X, as the victim.
19:36:01 <freeside>	if you assume the victim is the badguy then we're talking about a differnet situation.
19:36:28 <grumpy>	hmmm
19:36:31 <grumpy>	ok
19:37:13 *	freeside installs the latest Mail::SRS.
19:37:36 <freeside>	http://dumbo.pobox.com/~mengwong/tmp/srsattack.html
20:16:57 <Shevek>	freeside, are you here?
20:21:59 <Julian>	freeside: I don't yet see the fundamental difference with regard to security in preserving H1 (Hop 1), H2, and Hn as opposed to preserving H1, Hn-1, and Hn.
20:23:18 <Julian>	H1 can always be forged if not *all* of H2..Hn-1 can be trusted by Hn.
20:24:03 <Shevek>	Julian, what's your email address?
20:24:18 <Julian>	(Assuming that only H1 can judge the legitimacy/validity of a "H1 was the original origin of that message" statement.)
20:24:24 <Julian>	Shevek: <julian@mehnle.net>
20:24:57 <Shevek>	Thanks.
20:26:46 *	Shevek mails you.
20:27:41 *	Shevek goes to get food.
20:33:01 <grumpy>	Julian: among other things, preserving Hn-1 instead of H2 means that it is Hn-1 that is claiming that it is ok to send them the bounced SRS1 email, rather than Hn-1 claiming it is ok to send H2 the SRS1 email
20:33:35 <grumpy>	Since Hn-1 can't tell if H2 really supports SRS1 or if it is being abused, this is more secure
20:34:28 <grumpy>	(This assumes that Hn-1 knows whether they support SRS and whether they use a catch-all email account.)
20:37:06 <Julian>	"preserving Hn-1 instead of H2 means that it is Hn-1 that is claiming that it is ok to send them the bounced SRS1 email, rather than Hn-1 claiming it is ok to send H2 the SRS1 email" -- You mean that in the H1, H2, Hn case, Hn-1 claims that H2 is a valid hop for a given forwarding route, while in the H1, Hn-1, Hn case, Hn-1 claims that Hn-1 is a valid hop?
20:37:34 <Julian>	How can any hop claim that itself is a valid hop?
20:37:46 <Julian>	That's exactly what any attacker could do.
20:38:28 <Julian>	Of course, this only provides a useful attack vector if the attacked domain isn't SPF-protected.
20:39:06 <Julian>	I'm still trying to understand the fundamental difference between the H1, H2, Hn and the H1, Hn-1, Hn case.
20:41:41 <Julian>	In the H1, H2, Hn case, an attacker would claim to be any of H3..Hn-1 when sending a doomed-to-bounce message to Hn -- is that correct?
20:42:42 <Julian>	Uhm, no, I think I got something wrong. Let me thing about it some more minutes. I need to understand the original attack vector.
20:51:27 <Julian>	freeside, grumpy, shevek: The 3rd graphic on <http://dumbo.pobox.com/~mengwong/tmp/srsattack.html> says: "dob@fourth.com sees SRS1 and shortcuts pobox out, *if* third.com passes SPF." -- What happens if third.com does *not* pass SPF? Isn't SPF assumed to be *always* applied when accepting and forwarding messages?
20:52:26 <Julian>	And shouldn't a message that fails an SPF check always be rejected, not only if SRS1-to-SRS1-shortcutting is performed?
20:53:29 <Julian>	I don't understand why the sentence I quoted has explicitly been made *conditional*. Is it *meant* to describe a conditional behavior?
20:54:08 <freeside>	good point.
20:54:44 <freeside>	i think it might be useful for SRS1 hosts to *not* do SRS1 rewriting if the incoming hop domain has no SPF.
20:56:48 <Julian>	If a domain doesn't have SPF, are messages "from" (envelope sender) that domain considered to "pass" or "fail" in the scope of the sentence I quoted from the graphic?
20:56:58 <freeside>	considered to fail
20:57:33 <freeside>	i should say if it lacks spf entirely
20:57:37 <freeside>	if it fails, you reject.
20:57:42 <freeside>	if it passes or is unknown you do the rewrite.
20:58:06 <Julian>	So, the message is considered to "not pass", in the scope of that sentence. Is that correct?
20:58:13 <freeside>	yes
20:59:09 <freeside>	but then later i thought maybe it could be worth rewriting always.
20:59:12 <Julian>	Ok, so in the case of SPF=none, the sentence can be reduced to "dob@fourth.com sees SRS1 and shortcuts pobox out, if NOT." -- So the sentence doesn't state what is being done. It only states what is *not* being done.
20:59:22 <freeside>	let me fix that.
20:59:23 <freeside>	one sec.
20:59:44 <Julian>	I don't want to be picky, I just don't understand the scenario perfectly. :-)
21:03:21 <freeside>	i don't either now.
21:03:24 <freeside>	what's the attack scenario, shevek?
21:03:28 <freeside>	there are more than one.
21:05:16 <Julian>	To see whether the old attack vector(s) can be translated to the new SRS scheme, we need to fully understand the old scheme, the old vector(s), and the new scheme.
21:07:40 <freeside>	okay, the last time i tried to read woodhouse's description of the attack in srs-discuss, i got a headache.
21:07:44 <freeside>	have you read it?
21:17:16 <freeside>	yeah.
21:17:19 <freeside>	okay, reload.
21:18:58 <freeside>	yeah.
21:18:59 <freeside>	so.
21:23:46 <Julian>	freeside: I reloaded. What does happen if third.com does not have SPF (i.e. SPF=none)?
21:27:30 <freeside>	we need to split into two parallel universes here.
21:27:42 <freeside>	universe 1: fourth.com does not rewrite the header at all, and passes it on unchanged.
21:27:59 <freeside>	universe 2: fourth.com rewrites the header anyway.
21:28:17 <freeside>	i believe the two universes are functionally equivalent, but i need to think through the scenarios.
21:29:02 <freeside>	in universe 1, it passes the buck.  if we move to slide 4, if fifth.com becomes responsible for doing a bounce, it will bounce directly to third.com.
21:29:06 <Julian>	Universe 1 is invalid in an SPF world.
21:29:32 <freeside>	right, therefore Universe 1 is not an SPF world.
21:29:49 <freeside>	it is always possible for a domain to not have an SPF record.
21:30:01 <Julian>	I just want to know the following:
21:30:03 <freeside>	i don't think we need to concern ourselves with whether SPF is widely deployed or not.
21:30:14 <Julian>	Shouldn't a message that fails an SPF check always be rejected, not only if SRS1-to-SRS1-shortcutting is performed?
21:31:00 <Julian>	"that fails an SPF check" meaning SPF=fail, and maybe SPF=error.
21:32:29 <Julian>	The sentence "dob@fourth.com sees SRS1 and shortcuts pobox out, *if* third.com has SPF." must *not* be a conditional sentence, IMO.
21:33:07 <Julian>	Otherwise you'd have to specify what happens if the condition is not true.
21:34:17 <Julian>	I think we can safely imply (in all of the diagrams) that SPF failures (SPF=fail, or SPF=error) cause messages to be rejected, and anything else cause messages to be accepted. Can we not?
21:42:49 <freeside>	okay.
21:42:53 <freeside>	yes.
21:43:09 <freeside>	a message that fails an spf check must always be rejected.
21:47:03 <Julian>	Ok. Maybe you should mention this implication on the diagrams page.
21:47:27 <Julian>	And then drop the condition in that sentence.
21:53:00 <freeside>	ok.
21:55:23 <freeside>	done.
22:04:46 <Julian>	freeside: Ok, great. I'll continue trying to understand the original attack vector.
22:05:07 <freeside>	have you read woodhouse on srs-discuss?
22:06:17 <Julian>	No, I'm still busy catching up with all the mailing lists.
22:07:52 <freeside>	ok
22:10:17 <Julian>	freeside: Wouldn't it make sense to move "We assume that at each forward stage, SPF is checked, and if SPF fails we reject." right up to the very top of the page?
22:13:05 <freeside>	ok.
22:24:03 *	Julian sets mode: +thinking
22:28:21 <freeside>	have you read the woodhouse papers?
22:28:51 <Julian>	No, not yet. I will do that shortly.
22:31:17 <Julian>	<http://archives.listbox.com/spf-discuss@v2.listbox.com/current/>, which is linked to from <http://spf.pobox.com/mailinglist.html>, is dead.
22:31:36 <Julian>	Is there an archive for the various lists, in particular for srs-discuss?
22:34:56 <freeside>	the box is having nfs issues right now.
22:34:59 <freeside>	we are fixing.
22:35:04 <freeside>	try again now.
22:35:22 <freeside>	er, or in aminute.
22:39:07 <freeside>	yeah.
22:39:12 <freeside>	maybe we need to do A, B, and X-1, and X
22:39:15 <freeside>	how awful.
22:39:22 <Julian>	I don't think so.
22:39:42 <Julian>	I think you cannot safely perform shortcutting at all.
22:40:19 <Julian>	I need to think a bit more about it, but I do have some very good ideas on how to prove this mathematically.
22:40:44 <Julian>	s/mathematically/logically/
22:42:20 <freeside>	hrhrhrm
22:43:46 <Julian>	If I just were able to catch up on the lists. The volume is so high, it's almost insane. Argh.
22:51:38 <freeside>	yes.
22:52:01 <freeside>	no, i really think A, B, X-1, and X will do it.
22:52:36 <freeside>	we need to redefine the fault away from the spammer towards irresponsible domains that do not publish SPF.
22:52:58 <freeside>	we have to remember the axiom that if a domain does not publish SPF, it is liable to get all kinds of bounce messages from all kinds of places.
22:53:20 <freeside>	domains that do publish SPF should be able to expect they will not get random bounce messages.
22:53:35 <freeside>	SRS has to check SPF.
22:56:14 <Julian>	I'm not sure that even in a "every domain has an SPF record" world, SRS shortcutting is safe.
22:56:25 <Julian>	s/is safe/can be safe/
22:56:43 <Julian>	I need to think about it, though.
22:56:58 <freeside>	i really think the crux comes at the injection from X-1 to X.
22:57:10 <freeside>	X doesn't trust X-1.  so X will always forward the bounce back to to X-1.
22:57:28 <Julian>	Why doesn't X trust X-1?
22:57:38 <freeside>	because i don't know who's sending me mail.
22:57:59 <freeside>	hrrm.
22:58:02 <freeside>	you might be right.
22:58:08 <freeside>	let me run through a scenario with a, b, x-1, and x.
22:58:11 <Julian>	Well, *none* of the forwarders can trust its predecessor in that regard.
22:58:47 <Julian>	But we *need* to establish some rules when a hop (forwarder in the chain) can be trusted.
22:59:09 <Julian>	Otherwise, SRS (and bounce returning) is pointless.
22:59:10 <freeside>	but forwarders don't necessarily know anything about who's forarding in to them.
22:59:16 <Julian>	True.
23:01:18 <Julian>	In my current thoughts, I assume that Hk-1 (Hop k-1) is trusted by Hk if and only if the forwarded message does not fail the SPF check.
23:01:59 <Julian>	I'm not sure that penalizing domains without an SPF record is a good idea until SPF gets *widely* adopted.
23:02:42 *	Julian sets mode: +thinking
23:02:45 <freeside>	the penalty is not very strong.
23:02:55 <freeside>	we just don't rewrite; we don't put ourselves on the line for somebody we don't know.
23:02:57 <freeside>	the buck stays with them.
23:03:36 <Julian>	But a domain having an SPF record doesn't mean that anyone knows that domain or who's behind it.
23:03:45 <freeside>	in fact, we may want to require that the message *pass* an SPF test before we rewrite.
23:04:11 <freeside>	if it fails, we reject; if it gets a neutral or softfail, we don't rewrite, under the assumption that subsequent hops won't get a fail either.
23:04:29 <Julian>	That's not a bad idea.
23:04:34 <freeside>	this really is all devilishly complex.
23:04:48 <freeside>	problem with the white-arrow shortcutting is the hash gets broken on the reverse.
23:05:08 <Julian>	I wonder what our expectation of the best-case SRS security is.
23:07:32 <freeside>	mmmm.
23:08:40 <Julian>	We need to define what rewriting implies. As you said, one might not want to vouch for a 3rd party's messages by taking them into one's domain, if they are not SPF-protected.
23:09:19 <freeside>	yes.
23:09:23 <freeside>	suppose we add that rule.
23:09:32 <freeside>	that only an SPF explicit PASS domain will cause rewriting.
23:10:07 <Julian>	On the other hand, making "the 3rd party publishes an SPF record" a criterion for vouching for that 3rd party might be logically independent.
23:10:11 <freeside>	can an attacker still game the system and cause victim to send mail to tetchy?
23:10:30 <freeside>	with shortcutting still allowed.
23:11:25 <Julian>	I think vouching, as a forwarder, for an unknown 3rd party's messages is a bad idea in the light of domain-based black-listing, which is suggested by the SPF concept.
23:11:33 <Julian>	Generally.
23:12:40 <Julian>	Hmmm.
23:13:32 <freeside>	Hmmmm.
23:13:33 <Julian>	But it's no more a bad idea than vouching, as an ISP (which basically isn't anything other than a forwarding service itself).
23:13:46 <freeside>	mmm.
23:15:13 <Julian>	Vouching is always done for the message sender. The difference is, an ISP (or mail service provider)'s message senders are its clients, while a forwarder's message senders are *not* its clients.
23:15:56 <Julian>	(message senders = message senders in forwarding processes)
23:17:38 <Julian>	An ISP can be a forwarder in the classic sense, too. I.e. an ISP usually forwards messages from non-clients to its clients' mailboxes.
23:17:38 <freeside>	mmm.
23:18:23 <Julian>	(But that's not really relevant, I just pointed it out so my definitions don't have a loophole.)
23:19:47 <freeside>	ok.
23:23:33 <Julian>	We need to find a good criterion for when to vouch (by rewriting) for a message. As I said, I don't think that "the envelope sender domain does have an SPF record" is a good criterion. It just doesn't have much to do with the sender's trustworthyness.
23:24:33 <freeside>	okay.
23:24:40 <freeside>	only if it's an SPF pass.
23:24:52 <Julian>	"The forwarded message implicitly passes (by not failing) or explicitly passes an SPF check" cannot *easily* be a good criterion, either. Maybe it can, but not easily.
23:25:42 <Julian>	The problem is, there aren't many good criteria left to choose from. But a forwarder needs to have some.
23:26:55 <freeside>	mmm.
23:26:58 <Julian>	"The forwarded message implicitly passes (by not failing) or explicitly passes an SPF check" could be a good criterion in interaction with a domain-based reputation register (AKA black/grey list).
23:27:31 <Julian>	(or white list, of course)
23:27:42 <freeside>	mmm.
23:27:58 <Julian>	Forwarding is awful, did I mention that? ;-))
23:28:45 <Julian>	ISPs, as forwarders for their immediate clients, can easily maintain a reputation register for their clients.
23:28:56 <Julian>	At least implicitly.
23:28:59 <freeside>	there are always scaling problems though.
23:29:08 <Julian>	In what regard?
23:30:15 <Julian>	I should stop drinking Jolt. My mind is getting way too sharp, and I need to get to sleep soon.
23:32:10 <Julian>	Ok, let's assume we use "The forwarded message implicitly passes (by not failing) or explicitly passes an SPF check", coupled with some sort of reputation register, as a vouching criterion.
23:32:15 *	freeside imagines Julian's mind as a buzzsaw spinning out of control.
23:34:29 <Julian>	The problem is, each forwarder can only vouch for its immediate predecessor.
23:34:45 <Julian>	...preceding hop in a forwarding process, that is.
23:36:27 <Julian>	The quality of a vouch (is "voucher" a good word?) drops as the distance of the vouched for hops grows.
23:37:33 <Julian>	I.e. if I am Hk (hop k), and I vouch for Hk-s, the quality of that vouch is worse than the quality of a vouch for Hk-r, if s>r.
23:37:57 <freeside>	so ultimately Hk ends up sending a message to B which it knows nothing about.
23:38:09 <freeside>	so shevek is correct.
23:38:27 <freeside>	no short circuiting.
23:38:37 <freeside>	damn.
23:39:01 <Julian>	Simple expample: k=3, s=2, r=1. So I'm H3. If I vouch for H1, the vouch cannot be as good as if I vouch for H2.
23:39:36 <freeside>	and the bad spammer has found a way to get messages from victim (x-1) to srs1@tetchy (B).
23:40:45 <Julian>	Well, the scale of the vouches' quality difference depends on the probability that any direct vouch (H2 vouches for H1, and H3 vouches for H2) is illegitimate.
23:41:16 <Julian>	We cannot make any general assumptions about that probability, so let's not even try that.
23:42:21 <Julian>	Given a good vouching criterion, we *can* allow short-circuiting, but only if we accept an increased risk (depending on the number of skipped hops) for vouches being illegitimate.
23:42:51 <Julian>	And that's provided that we have a *good* vouching criterion!
23:43:30 <freeside>	mmm.
23:43:31 <Julian>	"The forwarded message implicitly passes (by not failing) or explicitly passes an SPF check" can only be as good a criterion as the quality of the reputation register used permits.
23:44:10 <Julian>	So that's my conclusion.
23:44:31 <Julian>	Shall I make this into a mail message directed to srs-discuss?
23:45:08 <Julian>	Hmm.
23:45:16 <freeside>	mmm.
23:45:21 <freeside>	i wonder if shevek is going to come back.
23:45:24 <Julian>	I made one central assumption in my run-down:
23:45:51 <Julian>	"The quality of a vouch (is "voucher" a good word?) drops as the distance of the vouched for hops grows."
23:46:44 <Julian>	No. I mean another one:
23:47:10 <Julian>	"The problem is, each forwarder can only vouch for its immediate predecessor."
23:47:47 <Julian>	I'm pretty sure that this is true by definition. What do you think?
23:47:57 <freeside>	yes.
23:48:05 <freeside>	and that is an argument for no-short-cuts.
23:48:17 <Julian>	Any indirect vouches can only be derived from direct vouches.
23:49:19 <Julian>	Thank god it seems I haven't gone mad! I had that feeling all the time, but didn't take the time to logically examine it.
23:50:01 <Julian>	One more thing.
23:51:44 <Julian>	Theoretically, trusting an indirect vouch spanning a distance of s isn't any worse than trusting a direct vouch that trusts a direct vouch that trusts a direct vouch etc. over a total distance of s.
23:53:53 <freeside>	mmm, but you don't know anything beyond x-2
23:56:16 <Julian>	The central question is, is the probability of an indirect vouch of distance s being illegitimate in at least *one* of the spanned hops significantly higher (or higher at all) than the probability of a direct vouch being illegitimate combined with the probability of that vouch's implicit vouches?
23:56:37 <freeside>	mmm.
23:58:22 <Julian>	I.e. assume I am H3. Let p(v2) be the probability of the vouch from H2 to H1 being legitimate, and p(v3) the probability of the vouch from H3 (me) to H2.
23:58:38 <Julian>	...being legitimate.
00:01:54 <Julian>	p(v2)*p(v3) is of course always equal to p(v2)*p(v3), regardless of whether I (H3) *explicitly* only vouch for H2 (which of course means I implicitly also vouch for H1, if H2 has vouched for H1 before) or whether I *explicitly* vouch for H1 (by shortcutting and dropping H2 from the generated address).
00:03:25 <Julian>	Let's assume I (H3) know something about p(v3), even though I (Julian, the SRS think tank member) don't.
00:03:57 <Julian>	...using the supposed reputation register mentioned above.
00:05:41 <Julian>	I think it all depends on whether any of my preceding hops use a custom (i.e. not publicly known and *reproducible* (by me)) vouching policy.
00:06:01 <freeside>	mmm.
00:06:12 <freeside>	well, that's where we get into attack scenarios.
00:07:40 <Julian>	If all of my predecessors use a standardized, or at least somehow reproducible, vouching policy, I can reproduce the trustworthyness for all preceding hops, and base my vouching decision upon that.
00:09:01 <Julian>	So I can drop preceding hops and *explicitly* pronounce an *indirect* vouch for any indirect predecessor I wish.
00:09:35 <Julian>	...with the same probability of legitimacy as if only *direct* vouches were pronounced by each hop.
00:10:48 <Julian>	I hope I haven't been thinking nonsense for the last few minutes. I'm not exactly sure about what I said.
00:11:52 <Julian>	Doh. That's it!
00:12:54 <Julian>	If a forwarder is allowed to drop preceding hops from the generated SRS address, the next forwarder cannot *by definition* reproduce the preceding hops' trustworthyness.
00:13:42 <Julian>	Ah, I like logic.
00:13:45 <Julian>	qed.
00:15:27 <Julian>	Proof by contradiction.
00:16:01 <Julian>	freeside: Is there an archive for srs-discuss?
00:18:40 <Julian>	Conclusion: The only way to achieve a maximally accurate probability for legitimacy (and thus for the vouching decision) is by not allowing indirect vouches.
00:22:02 <Julian>	Still, we may accept inaccurate probability statements for legitimacy for the benefit of allowing short-cirtuiting.
00:23:55 <Julian>	So the next question is, what ramifications with regard to forwarders' trustworthyness do arise from allowing short-circuiting?
00:28:06 <Julian>	We already saw that allowing preceding hops to be dropped by Hk (hop k) from generated SRS addresses causes the dropping forwarder's successor (Hk+1) to be unable to know anything about Hk's predecessors (H1..Hk-1) or even their legitimacy.
00:30:12 <Julian>	In fact, Hk+1 can *never* know anything about Hk's predecessors or even their legitimacy, assuming that these predecessors are not included in the SRS address generated by Hk.
00:30:44 <Julian>	(I think this assumption is valid, since we don't want to list all the preceding hops in the SRS address.)
00:32:11 <Julian>	So, Hk can only possibly be a successful attacker if he is deemed trustworthy enough by Hk+1 to be vouched for by Hk+1.
00:33:12 <Julian>	Otherwise, any messages sent by Hk would be rejected by Hk+1 anyway.
00:33:16 <freeside>	mmm.
00:33:41 <Julian>	(Actually, this seems like an obvious statement to me.)
00:34:45 <Julian>	...*if* the message is meant to be forwarded by Hk+1.
00:34:49 <freeside>	grrrk
00:35:47 <Julian>	What about if the message sent by Hk is meant to be backwarded (i.e. SRS reverse bounced) by Hk+1?
00:36:04 <freeside>	m.
00:36:25 <Julian>	Has that kind to attack ever been a real issue with SRS addresses being hash-protected against replay attacks?
00:38:01 <freeside>	see, once you start shortcutting, you lose the hash protection.
00:38:15 <Julian>	You're right. Hmm.
00:40:09 <Julian>	Ok, so what if an attacker Hk states a predecessor of Hk-1 as the target of the alleged bounce (i.e. the spam victim).
00:40:11 <Julian>	?
00:40:34 <freeside>	i always think of the victim as Hk, but in your case the victim is Hk+1, right?
00:40:42 <freeside>	well, there are two victims.
00:40:48 <freeside>	there's the victim sender and the victim receiver.
00:40:52 <freeside>	which do you have in mind?
00:40:53 <Julian>	I consider the spam recipient the victim.
00:41:01 <Julian>	The final spam recipient.
00:43:05 <Julian>	If Hk is trusted by Hk+1, Hk+1 would in particular trust the "original sender" specified by Hk in the stated SRS address.
00:43:48 <Julian>	From Hk+1's perspective, Hk actually would be Hk+2.
00:44:05 <freeside>	mmm.
00:44:06 <Julian>	So let's reverse positions so as not to confuse things. You're right.
00:45:34 <Julian>	Let's assume Hk+1 is the attacker, Hk is the hop abused by Hk+1, and H1 (or Hj, j=1..k-1) is the intended final spam recipient (AKA the spam victim).
00:46:03 <Julian>	Hj <-- ... <-- Hk <-- Hk+1
00:46:35 <Julian>	The arrows point in reverse (i.e. bounce) direction.
00:47:52 <Julian>	So, the attacker Hk+1 would specify Hj to be the original sender of the message, which Hk+1 tells Hk to bounce.
00:51:11 <Julian>	Hk only knows Hk-1, its immediate preceding hop, and from the hash (validated by Hk when receiving the bounce) covering the vouch vk (the vouch from Hk to Hk-1), he knows that he actually had vouched for Hk-1.
00:52:30 <Julian>	Hk cannot know whether he actually had vouched for Hj, though. Hk can only know whether he *would* vouch for Hj.
00:54:56 <freeside>	right.
00:55:04 <Julian>	But when backwarding (forwarding bounces in reverse direction), is trusting Hk-1 really the same as trusting Hj?
00:55:19 <freeside>	that'd be reversing, really.
00:55:31 <freeside>	well, with shortcutting, do you ever get to Hk-1?
00:55:40 <freeside>	isn't it stripped by the time Hk+1 gets to it?
00:56:01 <Julian>	Yes.
00:57:39 <Julian>	Allowing short-cutting means allowing the attacker Hk+1 to specify a hop for Hk to backward the bounce to *different* than Hk-1.
00:58:34 <Julian>	I.e. if Hk+1 states "Hj was the original sender", under what conditions can Hk trust it and send the bounce directly to Hj?
00:59:03 <Julian>	It can only do this if it knows that Hj was *really* the original sender.
00:59:22 <Julian>	It cannot know this in any case.
01:01:06 <freeside>	mmmhum.
01:01:31 <Julian>	Its only change is to trust Hk-1 (which it trusted before, because there's a valid hash covering the vouch for Hk) to know that it knows a *reliable* (AKA non-abusable) way to direct the bounce to the *true* original sender.
01:01:53 <Julian>	Hk-1 cannot directly know that Hj was *really* the original sender.
01:02:37 <Julian>	Its only chance is to trust Hk-2 (...) to know a *reliable* way to direct the bounce to the *true* original sender.
01:02:54 <Julian>	Hk-2 cannot directly know that Hj was *really* the original sender.
01:03:18 <Julian>	etc. ad infinitum, until Hk-x == Hj.
01:03:51 <freeside>	yes.
01:04:01 <freeside>	so we need to never shortcut.
01:04:21 <Julian>	Does that mean that the hashes added by each hop need to be preserved when forwarding?
01:05:11 <Julian>	That's a real question to you. ;-)
01:09:32 <Julian>	One assumption I made was this: "It cannot know this in any case." -- That is, to re-add the context from above, Hk cannot know in any case whether Hj was *really* the original sender (as stated by Hk+1). I'll add the following: Hk can generally not know the validity of any hops before (but not including) Hk-1. To prove this, just see that Hk, like *any* hop, can only validate its own hash.
01:09:55 <Julian>	...by definition of the hash.
01:11:30 <freeside>	yes.  we need to keep all the hashes.
01:11:31 <freeside>	suck.
01:11:38 <Julian>	freeside: Well, that's all I have to say by now. Any questions left?
01:11:42 <freeside>	well, i think we can leave it up to the adopters.
01:11:59 <freeside>	they can make the decision whether they want to do shortcutting or not.
01:12:03 <Julian>	We should definitely recommend against shortcutting.
01:12:16 <Julian>	But as you said, leave it up to the adopters.
01:12:51 <freeside>	maybe we can just say, well, if you forward through more than three or four hops, you have to be prepared to violate the 64 char limit.
01:12:57 <freeside>	more than one hop, even.
01:13:09 <Julian>	More than zero hops, actually.
01:13:22 <freeside>	yeah =)
01:13:33 <freeside>	unless the forwarder wants to use a DB.
01:15:02 <freeside>	meanwhile, hadmut danisch is frothing at the mouth.
01:15:19 <Julian>	Yes. Which I'd definitely recommend. But I fully understand that this will be undersirable to some due to real, technical reasons, and to many due to general aversion against the use of a database.
01:15:34 <Julian>	What's that about Danisch?
01:17:21 <freeside>	see the thread starting at
01:17:22 <freeside>	http://news.gmane.org/gmane.ietf.asrg.smtpverify/
01:17:24 <freeside>	er
01:17:30 <freeside>	http://article.gmane.org/gmane.ietf.asrg.smtpverify/148
01:17:51 <freeside>	yuck.  gmane sucks.
01:17:57 <freeside>	okay, start at the main smtpverify/ url
01:18:35 <freeside>	near the bottom, see my post of 13:10 'SPF and the need for SRS'
01:18:38 <Julian>	BTW, as a reminder, there's is an advantage to *not* allowing short-cutting other than not risking being abused as a relay: when forwarding, the probability of trustworthyness can be determined from all preceding hops. This isn't a very strong incentive, though.
01:19:04 <freeside>	then see hadmut's response.
01:19:22 <freeside>	he seems a little bit ... i dunno.  unreserved?
01:22:21 <Julian>	To make forwarding work, all we have to do is ensure that the envelope sender domain matches (by the defined SPF record for that domain) the sending IP address. s/we/everyone/ ;-))
01:23:59 <freeside>	yeah.  what a pain in the ass.
01:24:47 <freeside>	hadmut seems well on his way to becoming a usenet.kook.
01:25:50 <Julian>	"I suspect more and more that this all is just about keeping Pobox's business model alive and not to protect against spam." -- Whatever.
01:26:14 <Julian>	SPF is not primarily a protection against spam.
01:26:26 <freeside>	he should know this, being the author of RMX.
01:26:34 <Julian>	Does Hadmut actually claim his proposal to be an anti-spam solution?
01:26:46 <freeside>	i don't know what he's proposing any more.
01:27:00 <freeside>	i'm going to stop responding on that thread and let other people deal with him.
01:27:13 <freeside>	i think it's good mailing list policy never to reply more than twice to the same person in a thread.
01:27:22 <freeside>	continuously.
01:28:47 <Julian>	"But I do suspect that this is just to keep the pobox forwarding alive against anti-spam measures." -- So what's the problem with that? Does he really want to push RMX as an "anti-spam" measure, declaring all forwarding services obsolete on the way?
01:29:16 <Julian>	Well, let's ignore him for now.
01:30:35 <freeside>	yeah, he's pretty much a kook.
01:30:55 <Julian>	Shall I sum up the chat log as a message to srs-discuss? I won't get to doing that until Monday, though.
01:31:11 <freeside>	well, what's the conclusion?
01:31:22 <Julian>	We could just post the chat log somewhere and mail the URI.
01:31:24 <freeside>	there's no way to do shortcutting that doesn't expose you to the woodhouse attack?
01:32:11 <Julian>	If "the woodhouse attack" == "SRS reverse relay attack", then yes.
01:33:21 <Julian>	It couldn't harm, though, if someone proofread my drivel... ;-)
01:33:27 <freeside>	grargh.
01:33:43 <freeside>	let's just demonstrate the attack scenarios and ask people what they consider an acceptable level of risk.
01:33:52 <Julian>	Ok.
01:41:30 <Julian>	In short: Hk+1 (hop k+1, the attacker) backwards (sends in reverse direction as an alleged bounce) a spam to Hk (hop k, being abused as a relay), claiming H1 (the final spam recipient targeted by the spammer) to be the original sender. Hk cannot determine itself whether the alleged H1 was actually the original sender, because every hop can only validate its own hash.
01:42:28 <freeside>	ok.
01:42:48 <Julian>	So Hk has to trust Hk-1, which has to trust Hk-2, which has to trust Hk-3, etc. until the *actual* original sender (the real H1) is reached or a hop determines that the hash it's responsible for is invalid.
01:43:02 <Julian>	That's it.
01:43:09 <freeside>	no shortcuts.
01:43:37 <freeside>	unless you think it is an acceptable tradeoff to be used by an attacker to target messages to srs1 at random sites.
01:43:42 <Julian>	Yes.
01:44:26 <Julian>	It would be good to mention my proposed definition of "trustworthyness" for vouching, too.
01:44:38 <Julian>	It all somehow builds upon that.
01:45:03 <freeside>	yes.
01:45:35 <Julian>	freeside: Would you send a message summarizing the conclusion? I really need to get to bed now. I can send a full message tomorrow or so, explaining my findings in sufficient detail.
01:46:43 <Julian>	I just subscribed to srs-discuss. Let's hope my mailbox won't overflow. ;-)
01:47:59 <Julian>	Is there an srs-discuss archive?
01:49:01 <Julian>	Yawn. Good night.