Subject: [spfbis] New Issue (#31): Lookup Time Limits

From: Scott Kitterman <[email-masked]>
Date: Tue, 03 Jul 2012 19:07:48 -0400

I'm currently working on issue #6, RFC 4408 Section 10.1 - Processing limits 
needs clarification and reorganization.  I came across one change that I think 
we should make (and can make within the charter), but it's not strictly 
editorial, so I'm raising it here for discussion.

RFC 4408 says this about lookup time limits:

   MTAs or other processors MAY also impose a limit on the maximum
   amount of elapsed time to evaluate check_host(). Such a limit
   SHOULD allow at least 20 seconds. If such a limit is exceeded, the
   result of authorization SHOULD be "temperror".

I think every implementation ought to have some kind of time limit.  It would 
be a DoS risk not to.  I'd like to change the MAY above to SHOULD.  It doesn't 
raise any incompatibilities and reflects common practice (and arguably fixes a 
clear bug in the spec).  The new text would be:

   MTAs or other processors SHOULD impose a limit on the maximum
   amount of elapsed time to evaluate check_host(). Such a limit
   SHOULD allow at least 20 seconds. If such a limit is exceeded, the
   result of authorization SHOULD be "temperror".

Objections, comments?

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 3 Jul 2012 21:56:53 -0400

No hat.

On Tue, Jul 03, 2012 at 07:07:48PM -0400, Scott Kitterman wrote:
> be a DoS risk not to.  I'd like to change the MAY above to SHOULD.

IMO, the purpose of a 2119 SHOULD is not "eat your broccoli; it's good
for you."  A good rule of thumb is, if you have a SHOULD, you ought to
be able to say why it's not MUST (i.e. under what conditions it would
be ok not to do the thing you SHOULD do).  Since the IETF is about
interoperability, this harm should be an interoperability issue.

None of this is to disagree that implementations _ought to_ have a
time limit.  That's not what SHOULD in 2119 means, though, IMO, and as
near as I can tell there is no interoperability reason why
implementations really ought to do this almost always (but not
always).

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 03 Jul 2012 22:20:16 -0400

On Tuesday, July 03, 2012 09:56:53 PM Andrew Sullivan wrote:
> > I think every implementation ought to have some kind of time limit.  It
> > would be a DoS risk not to.  I'd like to change the MAY above to SHOULD.

I was thinking in terms of SHOULD (due to security considerations) do this, 
but not MUST because if you want to get eaten by a DoS attack you're welcome 
to do so.  That's probably wrong thinking in 2119 terms, but OTOH, if you're 
DoS'ed you aren't interoperating with anyone.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 3 Jul 2012 22:29:23 -0700

> DoS'ed you aren't interoperating with anyone.
There are plenty of ways to push hard for something without using 2119
language.  This is one of those.

As you point out, what's being said here has nothing to do with
interoperability, only vulnerability on the part of the implementation.
That sounds a lot like Security Considerations to me.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 04 Jul 2012 02:26:18 -0400

> That sounds a lot like Security Considerations to me.

We'd previously discussed moving the 'how you implement it' bits of section 
10.1 up into the main part of the spec, which is what I'm working on now.  I 
think this flows better with the other functional limits that will now be in 
the record evaluation section (4.6), but if it needs to stay in security 
considerations, so be it.  

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 04 Jul 2012 11:18:11 +0200

On Wed 04/Jul/2012 01:07:48 +0200 Scott Kitterman wrote:
> 
> I think every implementation ought to have some kind of time limit.
> It would be a DoS risk not to.  I'd like to change the MAY above to
> SHOULD.

The interoperability issue derives from the fact that clients MUST
have a time limit.  Hence, a failure to impose a limit would seriously
affect an MTA's ability to serve clients properly.  An example where
it would be ok not to do the thing an MTA SHOULD do is tarpitting a
client who is repeatedly failing helo-checks.

> It doesn't raise any incompatibilities and reflects common practice
> (and arguably fixes a clear bug in the spec).  The new text would
> be:
> 

I'd append to the second sentence:

     and at most 5 minutes, according to the relevant subsection of
     Section 4.5.3.2 of [RFC5321].

That should clarify that, when evaluating multiple identities, the
limit can be understood as global or per-identity according to how the
hosting MTA invokes the evaluation during the SMTP dialogue.
(Time limits imply checking live: they don't apply to, say, manual
postmortem evaluation based on Received: header fields, but only to
the "typical" case, as Section 2.4. puts it.)

BTW, s/to evaluate check_host()/for evaluation/?  Or leave it as is
until #11...

BTW2, the final paragraphs, from "Domains publishing records..." to
the end of the section, should be moved somewhere else, IMHO.  You
made a better example some time ago, and cases like outlook.com
deserve further discussion because they tend to default to permerror
when included from redirected records.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 04 Jul 2012 10:30:34 -0400

>      Section 4.5.3.2 of [RFC5321].

Since having a limit at all is at most a SHOULD, I don't see a reason to 
specify a maximum.  Also there's neither an interoperability nor a security 
considerations reason to specify a maximum.

> the "typical" case, as Section 2.4. puts it.)

Is it unclear now?

> BTW, s/to evaluate check_host()/for evaluation/?  Or leave it as is

One issue at a time.

> when included from redirected records.

Yes.  I'm moving the "here's stuff to think about" parts to section 9.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 Jul 2012 07:50:31 -0700

> client who is repeatedly failing helo-checks.

MTA timeouts are defined in other documents already.  If it makes the
picture more complete we could make reference to those and remind people
they are to be observed when adding SPF checking to an MTA, but I don't
think we need to provide SPF-specific timeouts.

-MSK