Subject: [spfbis] Agenda for IETF83

From: S Moonesamy <[email-masked]>
Date: Wed, 28 Mar 2012 05:56:37 -0700

Hello,

This is the agenda for the IETF83 session:

SPF Update Working Group Agenda

March 30, 2012, 09:00 - 11:00 CET              120 minutes

     Note well                                    1 minute

     Agenda bashing                               4 minutes

     RFC 4408 issues                             35 minutes

     SPF RR Type and TXT RR (issue #9)           20 minutes

     DNS amplification attacks                   10 minutes

     Path authorization/updating SMTP             5 minutes

     Is a deployment document needed              5 minutes

     Adoption of                                 30 minutes
       draft-kucherawy-spfbis-experiment-03
       describing the SPF/Sender-ID experiment
       and discussion

     Any Other Business                          10 minutes

Regards,
Andrew Sullivan & S. Moonesamy, SPFBIS WG chairs

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 28 Mar 2012 18:41:02 -0400

On Wednesday, March 28, 2012 05:56:37 AM S Moonesamy wrote:
...
>      DNS amplification attacks                   10 minutes
...

Didn't roughly everyone who commented on this agenda item suggest we shouldn't 
do it?  I think it would be more productive to end the session 10 minutes 
early and give people more time for informal discussion.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 28 Mar 2012 22:50:46 -0000

>do it? 

That's my recollection.  I'll try to bash it off the agenda.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Wed, 28 Mar 2012 16:25:29 -0700

> That's my recollection.  I'll try to bash it off the agenda.
Dear John,

There were less vocal participants who voiced concerns about ignoring 
this issue.  I'll admit those running MTAs are unlikely to become DDoS 
targets, or notice when they facilitate distributed attacks through 
abuse of SPF macros.  Depending upon implementations, SPF processing 
could permit 400 DNS transactions against victim domains that return 
no-data and still result in message acceptance.  It is also incorrect to 
suggest instantiating supporting records for this type of attack is 
difficult, or requires extensive amounts of malefactor's resources.

A few minor changes could impose reasonable error limits for name an 
no-data errors and thus mitigate this potential threat.

Regards,
Douglas Otis

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 28 Mar 2012 19:27:53 -0400

> Didn't roughly everyone who commented on this agenda item suggest we shouldn't 

Some did, yes.  The time was cut considerably since the earlier
agenda, and there is of course no rule that we have to fill every
moment of allotted time.

Best,

A

-- 
Andrew Sullivan
[email-masked]