This is the recent traffic on the #SPF-council IRC channel on
irc.pobox.com. Anyone may join the channel, but only council
members can talk.
| 20:30 | <Julian> | grumpy: In which direction would you like this discussion to go instead? |
| 20:30 | <shew_> | At work, so I can't really participate in the dos discussion. |
| 20:30 | <grumpy> | there are lots of things to consider about DougO's I-D... for example, the assumption that you can put the SPF/MX records in cache |
| 20:30 | <grumpy> | (which you can) |
| 20:30 | <shew_> | (At least continnually.) |
| 20:30 | <grumpy> | but then that people will download the emails as the attack comes in and therefore do their MUA lookups after the nTTL has expired |
| 20:30 | <grumpy> | instead of in a clump |
| 20:31 | <Julian> | grumpy: But he bases his scenario on the assumption that the message triggering the DDoS attack gets sent to many different recipients who all use a different cache. |
| 20:31 | <grumpy> | right, which also is unlikely |
| 20:31 | <Julian> | Is it? |
| 20:31 | <willix> | hold on |
| 20:31 | <Julian> | Spammers are doing that today. |
| 20:32 | <willix> | We'll assume that MUA cases are minimum |
| 20:32 | <grumpy> | Julian: I meant that if you send to lots of isp.com customers, each individually, and have those spams spaced out at intervals >nTTL but <TTL(SPF,MX) |
| 20:32 | <willix> | Also would have to assume that people would do SPF checking primarily when email is coming in |
| 20:33 | <Julian> | grumpy: I agree, in this case the isp.com DNS/SPF cache would be a mitigating factor. |
| 20:33 | <grumpy> | right, but most people check their email periodically, so they get several copies of the spam and check them all at once |
| 20:33 | <grumpy> | and that all of the isp.com's customers will likely use a small set of NS which will cache stuff. |
| 20:34 | <shew_> | But the recipients would only use different caches if they did checking at MUA time, (which isn't really the right way to do things to begin with), and as Julian has just said, they'd tend to be using the same cache. |
| 20:34 | <grumpy> | and, of course, you have to get past the ISP's spam checks if you try to create post-DATA attacks. |
| 20:34 | <shew_> | (I've wondered if Doug has thought that %l refers to the recipient's local-part.) |
| 20:34 | <grumpy> | shew_: yeah, probably... |
| 20:35 | <grumpy> | uh, no |
| 20:35 | <grumpy> | it refers to the mailfrom local part |
| 20:35 | <willix> | yes, he's doing it on purpose - apparently he thinkgs in this way to determine if same email would or would not be checked twice |
| 20:35 | <grumpy> | his attack depends on that. |
| 20:35 | <willix> | i.e. that spammers would do it |
| 20:35 | <shew_> | Right, but some of his emails have referred to doing an spf check for every different recipient if %l is used. So I'm wondering if he's confused on that point. |
| 20:35 | <willix> | also its a way to achieve further amplification while minimizing SPF record |
| 20:36 | <Julian> | Let's put the DoS scenario back into perspective. I know that grumpy doesn't like the following kind of reasoning, but I really wonder why one would want to employ an SMTP message (possibly sent out many times using the usual spammer mechanisms) in order to make SPF clients send bogus DNS packets to a victim when they could just as well use a bot net to drown the victim in UDP packets (of any kind) directly? |
| 20:36 | <grumpy> | Julian: that is a valid point |
| 20:37 | <grumpy> | I *don't* think we have to make SPF have an amplification factor of <=1.0 |
| 20:37 | <Julian> | LOL, no, certainly not. |
| 20:37 | <willix> | Because botnet locations get blocked through specialized lists and BGP communities |
| 20:37 | <grumpy> | right |
| 20:37 | <willix> | He wants attack to come from servers that would normally not be easily blockable |
| 20:37 | <grumpy> | while SPF checks allow you to hide |
| 20:38 | <grumpy> | which is part of why DDoS attacks use DNS reflectors |
| 20:38 | <Julian> | If bot nets were being blocked on a regular basis, there wouldn't be a spam problam as big as it is today. |
| 20:38 | <Julian> | problEm |
| 20:38 | <Julian> | A bot net lets you hide pretty nicely. Command it via IRC, and you're hard to catch. |
| 20:39 | <grumpy> | part of Doug's nTTL attack can be eliminated by simply updating your SOA record to have a larger nTTL. |
| 20:39 | <willix> | this is separate topic... it basicly means ISPs don't react all that well and a lot are not doing what they could to block bad traffic |
| 20:39 | <grumpy> | or publish a wildcard so that you get a regular TTL |
| 20:39 | <Julian> | grumpy: Who is "you" in your last sentence? The victim? |
| 20:39 | <grumpy> | the victim |
| 20:40 | <grumpy> | the victim's name servers get tons of DNS lookups on names that don't exist |
| 20:40 | <Julian> | I know. |
| 20:40 | <grumpy> | put a wildcard in, and the names suddenly exist, and you no longer have a short nTTL problem |
| 20:40 | <Julian> | About the wildcard, you can't be serious? |
| 20:40 | <grumpy> | why not? |
| 20:41 | <Julian> | I mean, it might be an appropriate short term solution if you're currently being attacked, but you don't want to run a wildcard record permanently, do you? |
| 20:41 | <grumpy> | right |
| 20:41 | <Julian> | Think about what it does to the implicit-MX problem. |
| 20:41 | <grumpy> | it is a way of stopping an attack, not a recommendation for everyone to do now as a defense |
| 20:42 | <Julian> | So, the big picture question is, do we acknowledge (internally) his scenario and plan to work on an amendment RFC with tightened limits, or what? |
| 20:43 | <Julian> | Or do we agree that the scenario isn't a real problem? |
| 20:43 | <willix> | I need to move to different room, it'll take few minutes |
| 20:44 | <grumpy> | what do you mean by "internally"? |
| 20:44 | <frank> | If you / we have an idea it belongs into the errata draft |
| 20:44 | <Julian> | I mean that we shouldn't acknowlege any issues until we have properly analyzed them. And we certainly can't do that in an IRC session right now. |
| 20:46 | <Julian> | We could agree on continuing and intensifying our analysis, though. |
| 20:47 | <Julian> | But perhaps all of us already understand the issue and we don't think that anything serious should be done about it? |
| 20:47 | <Julian> | What do any of you think? |
| 20:47 | <frank> | Would an overall MX triggered query limit help substantially? |
| 20:47 | <Julian> | Why only for MX? |
| 20:48 | <frank> | Only MX multiplies queries (ptr is boring) |
| 20:48 | <grumpy> | well, I guess my position for years has been that SPF has a DoS potential, that the SPF specs before I got ahold of them were seriously flawed in this respect, that I think the process limits I put in make things much better, and that having seen DougO's I-D, I haven't changed my mind about anything. |
| 20:49 | <Julian> | grumpy: So you think that there isn't a real problem that requires a significant reaction? |
| 20:49 | <frank> | re grumpy: ACK. Shoul we make it better than better? |
| 20:49 | <Julian> | That's where I'm currently leaning toward, anyway. |
| 20:49 | <grumpy> | frank: the mx: mechanism doesn't really increase the ratio. It each mx: lookup requires one lookup from the attacker to generate 10 lookups on the victim. each a: mechanism requires zero additona lookups from the attacker. |
| 20:50 | <Julian> | I think that specifying additional processing limits would be a good idea in theory but probably isn't going to affect most of the implementations out there., |
| 20:51 | <grumpy> | I think that there *may* need to be additional limits, but it is certainly not clear to me. |
| 20:51 | <Julian> | shew_, willix: Any comments from you? |
| 20:51 | <willix> | reading |
| 20:51 | <grumpy> | I think the current process limits in RFC4408 make things much better. I'm still open to the question "are they good enough?" |
| 20:51 | <shew_> | reading here as well. |
| 20:51 | <willix> | I think we'd benefit from maximum dns limits |
| 20:52 | <willix> | and from tools that can calculate maximum dns record limit given certain record |
| 20:52 | <willix> | dns lookup limits |
| 20:53 | <grumpy> | again, using a: mechanisms, you get one attacker lookup on the SPF record, and ten vicitim lookups |
| 20:53 | <grumpy> | using the mx: mechanism, you have the same 1:10 ratio |
| 20:53 | <Julian> | OK, here's an idea. The biggest problem probably is that there are implementations out there that don't even implement the processing limits specified in RFC 4408. So we would have to reach out to implementors to get them change their implementations and notify users/customers. But if we do that, we can just as well specify additional limits beforehand and recommend that they be implemented. |
| 20:53 | <shew_> | So that means at most 100 lookups per top check_host(), right? |
| 20:54 | <willix> | More like 25-50 lookups probably |
| 20:54 | <grumpy> | shew: yeah, that is the approximate max DNS lookups right now |
| 20:54 | <shew_> | Then looking at Doug's "RR x MHS x Domain-Names x Recipients x DNS/SMTP = Gain", |
| 20:54 | <shew_> | I don't know what "MHS" is, and it looks to me that "Recipients" should just be "1". |
| 20:54 | <Julian> | shew_: Forget those formulas. They're duious. |
| 20:55 | <grumpy> | MHS == Mail Handling System |
| 20:55 | <Julian> | "MHS" = mail handling system = ( MTA | MUA ) |
| 20:55 | <frank> | message handling system |
| 20:55 | <grumpy> | ha! I typed quickest for once! |
| 20:55 | <Julian> | I gave the most information, though. |
| 20:55 | <shew_> | Okay. So that should really be at most two--one for the recipient doing spf checking, and one for senders doing egress checking. |
| 20:55 | <Julian> | :-P |
| 20:55 | <shew_> | (heh.) |
| 20:55 | <willix> | Doug's point was that if you put overall limit you might cause some records to no longer validate |
| 20:55 | <grumpy> | shew: no |
| 20:55 | <grumpy> | it can happen on each forwarder hop, and it can happen at the MUA |
| 20:56 | <Julian> | shew_: I guess Doug would argue that forwarding may lead to MHS > 2. |
| 20:56 | <willix> | I want to say that not only wou'd we do it but also provide tools to verify that maximum record limit is not reached for somebody doing SPF record test |
| 20:56 | <frank> | A limit per victim would be nice, but without zonecut it won't fly |
| 20:56 | <Julian> | willix: Agreed. |
| 20:56 | <Julian> | (I'm really in favor of an overall DNS lookups limit.) |
| 20:56 | <shew_> | It *shouldn't* happen at each forwarder hop or at the MUA. That would represent a bad use of spf checking imho, in that it's best used at the first receiver's MTA. |
| 20:57 | <grumpy> | ScottK's verifier already does that, IIUC |
| 20:57 | <willix> | good |
| 20:57 | <grumpy> | shew: we discussed that on the spf-discuss... |
| 20:57 | <willix> | what else can be said? |
| 20:57 | <Julian> | I agree that each forwarder doing the same check is unrealistic, and that count(forwarders-in-a-row) > 1 is rare. |
| 20:57 | <grumpy> | most hops will do spam checking, most hops will not trust the spam checking done by the previous hop |
| 20:58 | <shew_> | Proper forwarder whitelisting shouldn't cause another spf check, (which is a thing discuss in more detail elsewhere I suppose.) |
| 20:58 | <frank> | grumpy: bad idea, if they get this right they do SRS |
| 20:58 | <willix> | For example I can say that as it is you can create SPAM email that would generate lots of dns lookups. THis is done simply by adding number of different domains in the Header and in the body and many anti-spam systems would try to check on those domains (i.e. URL validation, etc) |
| 20:59 | <grumpy> | willix: right |
| 20:59 | <Julian> | shew is right. You can't blame wget for people doing `while true; do wget $URL; done`. |
| 20:59 | <shew_> | I just am not convinced about adding dns query counter limits, in that it's..harder to validate and more confusing. I don't see that it's really necessary. |
| 20:59 | <grumpy> | but that gets back to "yeah, but SPF isn't as bad as others", not "SPF is safe as is". |
| 21:00 | <shew_> | I'm actually fine with that answer, grumpy. |
| 21:00 | <frank> | SURBL has don not querry lists |
| 21:00 | <Julian> | grumpy: No, it's a fundamental issue. It's people shooting people, not guns shooting people. |
| 21:00 | <grumpy> | SURBL can't be used to attack an arbitrary victim. |
| 21:01 | <Julian> | It can't? |
| 21:01 | <Julian> | Right, it can't. |
| 21:01 | <frank> | Yes, that was about URI checking and how they manage that |
| 21:01 | <grumpy> | I think SPF needs to be safe as designed. |
| 21:01 | <shew_> | If the ddos risks of spf are far outshadowed by other ddos risks, (and those other risks aren't likely fixable in <10 years), then I don't see the need to lower spf ddos risks. |
| 21:01 | <Julian> | grumpy: Define "safe". Apart from that, I agree. |
| 21:02 | <Julian> | "safe" is a very relative category. |
| 21:02 | <willix> | I also want o say that Doug's ovestates amplification factor. Is it safe to say that? If so how much should we say is possible? |
| 21:02 | <frank> | 10 |
| 21:02 | <Julian> | That's a question that grumpy should answer. |
| 21:02 | <shew_> | (However, I wonder if macros could simply be removed in spf3.) |
| 21:02 | <grumpy> | I think DougO greatly overstates the amplification factor, but I'm not certain by how much. |
| 21:03 | <grumpy> | Julian: why should I answer the question? |
| 21:03 | <Julian> | shew_: Macros aren't a general problem. It might suffice to remove %{l}. |
| 21:03 | <shew_> | Grumpy: You agreed earlier that there are a maximum of 100 lookups per top-level check_host now.. |
| 21:03 | <Julian> | grumpy: Because you produced the scenario some time back and I thought you had some realistic numbers on the amplification factor? |
| 21:04 | <grumpy> | Julian: ok... well, I don't entirely trust my analysis and would like to see others try to reproduce it. |
| 21:04 | <Julian> | I might be able to reproduce the scenario in the lab using Mail::SPF and Net::DNS::Resolver::Programmable. |
| 21:05 | <Julian> | (That would relieve me of having to use tcpdump.) |
| 21:05 | <grumpy> | right now, my greatest concern is that there are too many SPF implementations out there that do not implement RFC4408 process limits and maybe more than a few that don't even implement mengwong-spf-01 limits |
| 21:05 | <Julian> | I totally agree with grumpy on that. |
| 21:05 | <grumpy> | and, worse, people like Hector think that it is crazy to implement RFC4408 limits and won't do it. |
| 21:06 | <grumpy> | speaking of which, has anyone seen Hector lately? |
| 21:06 | <frank> | oops, never heard that, where did he say that? |
| 21:06 | <Julian> | I think the RFC 4408 limits are reasonably safe given various circumstances. |
| 21:06 | <grumpy> | I haven't seen Hector post to DKIM or SPF... |
| 21:06 | <Julian> | They ought to be tightened eventually, but it's not urgent. |
| 21:06 | <grumpy> | frank: look in spf-discuss from last may |
| 21:07 | <frank> | It's bben weeks that I talked with him about his HEAD draft |
| 21:08 | <grumpy> | I think a serious study needs to be conducted on the DoS potential of SPF. That it shouldn't be done by me alone. And, that we need buy-in from folks like Hector, sendmail and MS. |
| 21:08 | <Julian> | Buy-in on the study? |
| 21:09 | <grumpy> | and on implementing the results. |
| 21:09 | <grumpy> | *IF* DougO could be counted on to be non-trollish, I think we should include him. |
| 21:09 | <grumpy> | but I really doubt that would be productive. |
| 21:09 | <Julian> | OK, noted. |
| 21:09 | <Julian> | Are there any other questions for now? willix, do you feel confident about the issue and its severity? |
| 21:09 | <willix> | no I dont feel confident |
| 21:10 | <shew_> | I am still a bit confused. |
| 21:10 | <frank> | I couldn't bear the "SPF script" stuff, sorry |
| 21:10 | <Julian> | Then please ask more questions. |
| 21:10 | <grumpy> | I think it is easy to show that SPF can generate something in the realm of 10x increases... |
| 21:10 | <shew_> | Basically, if we do start from the assumption of a maximum of 100 dns queries per top-level check_host(), (which I think was agreed on here), then does that in and of itself represent aproblem? |
| 21:10 | <willix> | We do not seem to have good plan to go about it and how to explain it in public |
| 21:10 | <grumpy> | I think that going beyond that is much harder. |
| 21:11 | <Julian> | I know we can't be absolutely confident right now, because we're still lacking a thorough analysis, but at least we should understand the attack vector properly and which of DougO's arguments are certainly bogus. |
| 21:11 | <shew_> | ie, do we agree that's the worst-case scenario, and if so, is that a problem? |
| 21:11 | <willix> | Obviously I'll say what I think (i.e. my personal opinion) about Doug's draft |
| 21:11 | <grumpy> | shew_: 100 DNS queries is not quite right. It is the ratio that is important. |
| 21:12 | <Julian> | grumpy: What ratio exactly? |
| 21:12 | <grumpy> | the 100 DNS queries sent to the victim requires 11 DNS lookups sent to the attacker |
| 21:12 | <shew_> | grumpy: Does the max of 100 DNS queries represent a ratio of 10? (One record with 10 dns-query-causing mechanisms, each referring to an spf record with 10 dns-query-causing mechanisms)? |
| 21:12 | <grumpy> | assuming neither can be cached, you get a ratio of 100/11 |
| 21:13 | <grumpy> | shew_: right |
| 21:13 | <frank> | I never understood 1.38*(500+100)/1000 - is that a problem?= |
| 21:13 | <Julian> | I think the "10 TCP packets for a single SMTP message"-to-"bytes of UDP traffic in the victim's direction" ratio is bogus. |
| 21:13 | <grumpy> | frank: I never understood that one either. |
| 21:14 | <Julian> | That formula is up to DougO to explain. |
| 21:14 | <frank> | Okay, I ignore it for the moment |
| 21:14 | <shew_> | Ahh, okay. So the ratio is a "total dns queries versus dns queries to the attacker", with an assumption of no DNS caching whatsoever. |
| 21:14 | <grumpy> | I think exploiting DNS caches is harder than it first appears because lots of DNS caches flush things too quickly, don't flush things quick enough, or can be changed by updating the SOA record. |
| 21:15 | <shew_> | I actually hadn't understood that. |
| 21:15 | <Julian> | Here's a hint: in order to understand DougO's I-D, you need to distinguish between the "rough estimate" that he makes in the main text and the "hard numbers" implied by his example setup and tcpdump in the appendix. Those are two separate things. |
| 21:16 | <grumpy> | there two more points to ponder: is the amplification factor related to the total number of bytes sent *and* received, or just the max(sent,received), or just sent, or just recievied? |
| 21:16 | <grumpy> | Julian: right |
| 21:16 | <grumpy> | that is very critical |
| 21:16 | <Julian> | I think the rough estimate formulas are based on bytes. |
| 21:16 | <Julian> | ... sent and received. |
| 21:17 | <frank> | whose bytes, victim/attacker or victim/amplifier? |
| 21:17 | <grumpy> | Ok, point 1) was can you really reasonably combine sent and received bytes when calculating? The second point is 2) should it be bytes or packets that get counted? |
| 21:17 | <Julian> | victim/attacker |
| 21:17 | <Julian> | grumpy's (2) is a good question. |
| 21:18 | <Julian> | OK, guys, I need to be gone now. Will pop my head back in later. |
| 21:18 | <Julian> | (sorry) |
| 21:18 | <grumpy> | Julian: but usually the sending and receiving channels are independant. So, if you send Xs bytes, and receive back Xr bytes, and neither Xs nor Xr exceed the channel limits, there isn't a problem. |
| 21:18 | <willix> | Lets assume amplification factor would be A/B where |
| 21:18 | <shew_> | Argh. My numbers are completely wrong--I was back at thinking 10 includes with 10 lookups in each one. |
| 21:19 | <willix> | A: bytes received by the victim |
| 21:19 | <Julian> | Last comment: Well, the victim doesn't really send many bytes. |
| 21:19 | <grumpy> | willix: but it appears that DougO's numbers count both. |
| 21:19 | <shew_> | And attacker can be assummed to cache his record. |
| 21:19 | <willix> | B: bytes sent by the attacker which is B1+B2 where B1 are bytes in original spam and B2 bytes in DNS query to attack's dns servers |
| 21:19 | <grumpy> | willix: I tend to agree with that. |
| 21:20 | <grumpy> | willix: do you really think that it should be bytes, not packets? |
| 21:21 | <willix> | So what is acheivable based on example provided by Doug |
| 21:21 | <grumpy> | I've seen a lot of DDoS attacks described both as packets-per-second and bytes-per-second |
| 21:21 | <grumpy> | I think somewhere around 10:1 |
| 21:21 | <willix> | Thanks |
| 21:22 | <willix> | BTW - that is based on that mx operator would generate 1 mx lookup to attacker's controlled DNS and then certain number (assume 10) of lookups for each listed MX, right? |
| 21:23 | <grumpy> | right |
| 21:23 | <grumpy> | the MX DNS lookup generates a slightly larger packet than the individual A record lookups that get sent to the victim. |
| 21:23 | <grumpy> | also, you need to account for the SMTP session, which I think Doug underestimates |
| 21:24 | <grumpy> | at least my recollection was that it was larger than the 1k he claims |
| 21:24 | <willix> | What happens when any mail server wants to send bounce? |
| 21:24 | <grumpy> | what do you mean? |
| 21:24 | <willix> | Can attacker create such spam that where bounce needs to be sent a result would also be 10 lookups? |
| 21:25 | <grumpy> | Uh, I can't think of a way to do that |
| 21:25 | <willix> | i.e. using specially bogus MAILFROM? |
| 21:25 | <grumpy> | the MAILFROM should be <> for a bounce |
| 21:25 | <willix> | when somebody is trying to figure out where to send the bounce but has not verified incoming MAILFROM as being valid (i.e. has not used SPF)? |
| 21:26 | <grumpy> | Uhmmmm... I don't think I quite understand your scenario... |
| 21:27 | <willix> | MAIL FROM: <x@attacker.com> |
| 21:28 | <willix> | $ORIGIN attacker.com |
| 21:28 | <willix> | mx s1.victim.com. |
| 21:28 | <willix> | mx s2.victim.com. |
| 21:29 | <willix> | etc |
| 21:29 | <willix> | name specified are the ones that don't have mail server running |
| 21:29 | <willix> | s/names/dns hostnames in mx/ |
| 21:30 | <grumpy> | uh, yeah, that could be used to attack people too... but I don't see it as being SPF related. |
| 21:31 | <willix> | It is not, I just want to point this simple scenarios out as one also having about 10:1 amplification and generated with attacker sending SPAM and controlling dns of MAILFROM domain |
| 21:32 | <grumpy> | I mean, you could fill up mail queues of various ISPs trying to send email to x@attacker.com, and then they would keep retrying |
| 21:32 | <grumpy> | oh, yeah, I agree |
| 21:33 | <grumpy> | and since MTAs probably don't limit you to 10 MX lookups, they may well try many more than 10 each time. |
| 21:33 | <grumpy> | but, again, that gets back to "SPF isn't as bad as others", rather than "SPF is safe" |
| 21:34 | <grumpy> | another one is to send email that contains javascript that causes all MUAs to DoS the victim, or to have lots of URLs to the victim's website. |
| 21:34 | <willix> | Yes, but I want to point out that his attack on spf is just that he chose spf as example for range of similar attacks that can be done by spammers |
| 21:34 | <grumpy> | OK, that is a fair point. DougO isn't out to stop DoS attacks, he is out to stop SPF. |
| 21:35 | <grumpy> | he doesn't want to fix any problems with SPF, he doesn't want to base his attacks on reasonable assumptions |
| 21:35 | <shew_> | willix: Thanks for the clarification of 10x10 on mx queries. (Makes my 10x10 numbers above valid again.) |
| 21:35 | <shew_> | (I was just thinking through that when stepping away.) |
| 21:36 | <shew_> | Looking at Doug's example--technically %l isn't needed. His same attack could be made with just %d's. |
| 21:36 | <grumpy> | shew: yeah... I guess the point is that we can't switch from the 10/10/10 rules that we have to an overall DNS lookup limit without taking into account the MX lookups |
| 21:37 | <grumpy> | right |
| 21:38 | <grumpy> | back when we were discussing process limits, some people suggested removing the 10/10/10 limit with something like a 20 or 50 DNS lookup limit |
| 21:38 | <grumpy> | but that would have made things worse because that would have allowed a 20 or 50 to 1 amplification factor. |
| 21:39 | <grumpy> | allowing 10 A records to be looked up on each mx: is "safe" because it requires another DNS lookup on the attacker. |
| 21:39 | <willix> | How about 10/10/10 with additional max limit of 25? |
| 21:39 | <willix> | max total dns queries |
| 21:39 | <grumpy> | willix: yeah, that was what I was thinking of. |
| 21:39 | <grumpy> | or something along that line |
| 21:40 | <grumpy> | what the 10x10 mx: thing does is reduces the effect of the SMTP session overhead and initial SPF record lookup. |
| 21:40 | <shew_> | That would simply change the max from 100 dns queries to 25, right? |
| 21:40 | <grumpy> | So, with 10 a: mechanisms, you get much less than 10:1 amplification (assuming no caching), while 10 mx: can get much closer to 10:1 |
| 21:41 | <grumpy> | shew: right |
| 21:41 | <shew_> | So then the question would be whether a factor of 4 is worth such an additional limit. |
| 21:41 | <grumpy> | agreed |
| 21:42 | <grumpy> | Or, do we really need to reduce it to 5/5/5 or something? |
| 21:42 | <grumpy> | to answer that kind of quesiton, a serious study needs to be done |
| 21:42 | <shew_> | Agreed. |
| 21:43 | <shew_> | And I do agree with your logic on that way above. |
| 21:43 | <grumpy> | and not one done by someone who is just trying to grind an axe, nor one who may have screwed up the first time and recommended the 10/10/10 limit. |
| 21:44 | <willix> | And as I understand grumpy's library actually impliments 5 limit (at least for MX)... |
| 21:44 | <grumpy> | well, my original library did... I'm pretty sure Shevek changed it to 10/10/10 later on |
| 21:45 | <grumpy> | willix: do you have more questions or things I can help with? |
| 21:46 | <shew_> | So assumming that there was agreement on the need for a serious study, which isn't something that can be done in a day, that would imply then that the right order of thigns would be to go ahead an ask/list which of the current implementations implement the current 10/10/10 limits, and then doing so again for any "updated" limits found as a result of the study. |
| 21:46 | <willix> | Its all have been quite helpful |
| 21:46 | <shew_> | Agreed? |
| 21:47 | <grumpy> | shew_: yeah, that would be good |
| 21:47 | <shew_> | (I'm going into this with a mindset that it's a very bad idea to introduce limits at this point for spf1 unless there's a very, very clear need to.) |
| 21:47 | <willix> | I do have a lot better idea about how to explain's Doug's scenarios and point it as just one of the range of similar attacks with Doug specifically being against SPF |
| 21:47 | <shew_> | Maybe we should have an spf-dos mailing list. :-) |
| 21:48 | <grumpy> | willix: also, as a defense, the victim can set up a name server that gives very *slow* answers, and thus forcing a timeout on the SPF check. |
| 21:49 | <shew_> | Hey, that's a great idea. |
| 21:49 | <grumpy> | So, if someone is attacked, they can 1) change the nTTL in the SOA, 2) publish a wildcard to get a normal TTL, 3) give slow/no answers forcing a timeout. |
| 21:49 | <willix> | ok |
| 21:50 | <grumpy> | attacks that involve MHS > 1 require the sender to get their attack through anti-spam systems and greatly increase the SMTP session requirements |
| 21:50 | <shew_> | That would be an interesting setting for dns servers--requests for nonexistent TXT or type99 records, or any records for nonexistent domains, having a configurable delay. |
| 21:50 | <grumpy> | and, yeah, "there are a lot of systems out there that are worse than SPF, Doug just has an axe to grind" |
| 21:51 | <shew_> | (Well, not for the dns server config itself, but something for named files.) |
| 21:52 | <willix> | Ok, I have to go. |
| 21:52 | <shew_> | Oh, no it wouldn't help--the dns server being attacked would simply have to keep track of a growing queue of responses to reply to after that delay timeout. |
| 21:52 | <shew_> | And that in itself would be an attack. |
| 22:08 | <Julian> | "that gets back to 'SPF isn't as bad as others', rather than 'SPF is safe' " -- I don't find this to be an invalid argument. Is a car "unsafe" just because it doesn't protect you from being crushed by a meteor or from dying from a heart attack? As I said before, "safe" is a relative category, and if the rest of life is at least as dangerous, then where's the point in making one thing extremele safe beyond that? |
| 22:13 | <Julian> | "[slow name server as a defense]" -- "Hey, that's a great idea." -- I don't think it is. It is an _interesting_ idea, but it doesn't really make a good permanent strategy. |
| 22:13 | <Julian> | But perhaps DNS servers should come with some kind of tar-pit feature enabled by default. |
| 22:14 | <Julian> | Here's another idea: A limit on the DNS lookups per second could be specified for SPF. |
| 22:15 | <Julian> | That may not help much against _distributed_ DoS attacks, though. Perhaps an order of magnitude, but not much more. |