Subject: Re: [spfbis] Benoit Claise's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT)

From: S Moonesamy <[email-masked]>
Date: Thu, 12 Sep 2013 07:18:08 -0700

Hi Benoit,
At 03:47 12-09-2013, Benoit Claise wrote:
>Benoit Claise has entered the following ballot position for
>draft-ietf-spfbis-4408bis-19: No Objection

[snip]
----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>disclaimer: I've only reviewed the changes compared to the RFC 4088.
>
>Regarding "Appendix J.  Change History":
>    NOTE TO RFC EDITOR: Changes since RFC 4408 (to be removed prior to
>    publication)
>
>Personally, I like it when the new RFC has one section summarizing the
>changes compared to the initial RFC.
>This would be a mix of:
>    Appendix J.  Change History", but no needs to mention the editorial
>changes
>    Appendix C.  Changes in implementation requirements from RFC 4408

Appendix C contains the changes between the draft and RFC 4408.  The 
question of changes was mentioned by Eliot Lear in his AppsDir review 
(see 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10278.html 
).  My suggestion to the SPFBIS WG is to leave this as it is.

Regards,
S. Moonesamy (as document shepherd)

---

From: Benoit Claise <[email-masked]>
Date: Thu, 12 Sep 2013 16:55:33 +0200

> Appendix C contains the changes between the draft and RFC 4408.
Well, maybe "Changes in implementation requirements from RFC 4408"
So my first question is: what are the changes that are not related to 
the implementation requirements?
As a good example, 
http://tools.ietf.org/html/draft-ietf-v6ops-rfc3316bis-04#appendix-B is 
useful.

Anyway, I made my point, up to AD/document shepherd to decide.

Regards, Benoit
> The question of changes was mentioned by Eliot Lear in his AppsDir 
> review (see 
> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10278.html ).  
> My suggestion to the SPFBIS WG is to leave this as it is.
>
> Regards,

---

From: S Moonesamy <[email-masked]>
Date: Thu, 12 Sep 2013 08:09:21 -0700

Hi Benoit,
At 07:55 12-09-2013, Benoit Claise wrote:
>So my first question is: what are the changes that are not related 
>to the implementation requirements?
>As a good example, 
>http://tools.ietf.org/html/draft-ietf-v6ops-rfc3316bis-04#appendix-B is useful.

That is a good question (re. implementation requirements).  I suggest 
following the example you provided if Pete Resnick is okay with that.

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 12 Sep 2013 14:00:41 -0400

There are any number of changes we made that don't affect implementation requirements. An example that comes immediately to mind is that the draft says do not use the "ptr" mechanism.  That doesn't change implementation requirements because it's still part of the protocol for backward compatibility. 

Scott K

Benoit Claise <[email-masked]> wrote:
>).  
>_______________________________________________
>spfbis mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/spfbis

---

From: Douglas Otis <[email-masked]>
Date: Fri, 13 Sep 2013 17:25:20 -0700

On Sep 12, 2013, at 8:09 AM, S Moonesamy <[email-masked]> wrote:

>> So my first question is: what are the changes that are not related to the implementation requirements?
>> As a good example, http://tools.ietf.org/html/draft-ietf-v6ops-rfc3316bis-04#appendix-B is useful.
> 
> That is a good question (re. implementation requirements).  I suggest following the example you provided if Pete Resnick is okay with that.

Dear SM,

I would like to respond to this suggestion.

This suggestion overlooks SPF parameters from email messages combine to form DNS queries using macros in an endless number of ways.  Our data shows spam is largely emitted from compromised systems where SPF offers a covert method of targeting victims.  This form of abuse can increase network amplification by a factor of 3 or more beyond typical DNS attacks. This type of abuse also side steps Source Address Validation BCP38 aimed at disabling source address spoofing as well as UDP Source Port Randomization or even DNS Response Rate Limiting.  

Such an attack is likely well beyond what DNS or DNSSEC can handle by employing usual defenses.  In addition, SPF does not use a dedicated resource record type nor a naming convention and is likely to ignore receipt of large TXT and PTR RRsets.  With so few domains publishing SPF macros, large providers already indicate they ignore SPF records containing macros which reduces this threat.  After all, if this type of abuse were to occur, it would likely require a response from email providers and not DNS operators.  IMHO, the current specification has not kept up with current practices.

Regards,
Douglas Otis

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 13 Sep 2013 20:36:55 -0400

Doug,

I'm writing as co-chair on what I hope are strictly procedural
matters.

On Fri, Sep 13, 2013 at 05:25:20PM -0700, Douglas Otis wrote:
> to ignore receipt of large TXT and PTR RRsets.  With so few domains
> publishing SPF macros, large providers already indicate they ignore
> SPF records containing macros which reduces this threat.

It would be nice if you would produce even one citation for this,
since it's been asked of you repeatedly.

> response from email providers and not DNS operators.  IMHO, the
> current specification has not kept up with current practices.

That is entirely possible.  The WG is not chartered to remove
features that are in use.  By anyone.  We already had that appeal, and
made that decision.  So why does it matter if there is a feature in
here that is falling out of favour?  A later effort can remove it if
it is really unused.  But we can't.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Fri, 13 Sep 2013 20:56:55 -0700

Dear Andrew,

See comments inline.

> since it's been asked of you repeatedly. 

I fully understand a desire to limit discussions about aspects of this protocol.  This will take more time than anyone wants to afford for email.  In my prior response off list copied to Pete, this was agreeing with your statement about the WG skill with DNS.  Also, I am obligated to keep some conversations in confidence.  More than just IETF members are involved.

In my defense, may I ask whether the draft http://tools.ietf.org/html/draft-otis-spfbis-macros-nixed-01 been reviewed?

It contains a reference to a survey by the SPF website http://spf-all.com/stats.html which indicates of all domains publishing SPF records 99.947% contain no macros.  It seems a reasonable person would wonder why.

The issue of the PTR RRset is a matter of record.  There are even recent conversations with Scott where I noted the SPFbis protocol omits limits on the number of PTR RRs unlike limits placed on MX RRs.  I even suggested text to remedy this oversight.  He responded this was not an issue for SPF.  We are also going over language regarding response sizes.  May I point out there are no SPF error conditions caused by a TXT RRset or PTR RRset being too large.

I hope you can imagine what this might mean from the perspective of network amplifications caused by a protocol that recommends resolving two separate names using this highly inefficient protocol overlaying DNS to provide massive automation for unknown entities that lacks any dedicated resource record type or naming convention.  Carefully review the process for the PTR mechanism and estimate the DNS transactions and the resulting network traffic that could be caused for each occurrence. 

The MX mechanism can generate 111 DNS transactions with a recursive server.  This ignores supporting transactions likely needed in a resolution process.  Make that estimate again while assuming EDNS0 with a 1410 octet MTU, and again with a 4096 octet MTU.  As I had mentioned, use of IPv6 and DNSSEC is not within the purview of SPF.  The SPF protocol should not be allowed to ignore its impact on DNSSEC despite a steady insistence SPF does nothing special with DNS and any problem must be considered the fault of DNS.  The only remedy available is for providers to ignore any SPF TXT resource records containing macros.  What else can be done?

As an aside, at the time SPF was developed, there was already the binary APL RR, that when combined the MX record, could define the entire outbound address space within a single transaction.  It seems one vendor remains the major obstacle.  Not surprisingly, this vendor is now seldom used to directly interface with email.  Why should their abstinence be allowed to destroy safe deployment of DNSSEC?  Why should SPF be allowed to blame DNS?

> it is really unused.  But we can't.

At the same time, it seems irresponsible to completely deprecate use of the dedicated RR record type that had a much higher level of use while not deprecating a far more dangerous macro option used by far fewer domains.  Such an oversight  can not be excused by blaming the charter.

If I have said something offensive, allow me once again to assure you this was never my intent.

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 14 Sep 2013 00:18:18 -0400

On Friday, September 13, 2013 20:56:55 Douglas Otis wrote:
..
> The issue of the PTR RRset is a matter of record.  There are even recent
> conversations with Scott where I noted the SPFbis protocol omits limits on
> the number of PTR RRs unlike limits placed on MX RRs.  I even suggested
> text to remedy this oversight.  He responded this was not an issue for
> SPF.  We are also going over language regarding response sizes.  May I
> point out there are no SPF error conditions caused by a TXT RRset or PTR
> RRset being too large.
...
To correct the record, I said it was intentional.  The reason why it's treated 
different is explained on 4408bis.  We had language that treated PTR like MX 
for lookup limits, but that was changed for the reasons explained.  I didn't 
say it was "not an issue".  It was a deliberate design choice based on two 
competing issues.

We debated this in the WG already and I'm not aware of any new information 
that would make re-litigating it a reasonable thing to do.

I'm only commenting on this part to correct what I see as an error relating to 
what I've said in the past.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Fri, 13 Sep 2013 22:31:42 -0700

Hi Doug,
>I would like to respond to this suggestion.

Andrew already commented on the response ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg04180.html ).

I read the two messages from Benoit Claise, as Area Director, (see 
http://www.ietf.org/mail-archive/web/spfbis/current/msg04156.html and 
http://www.ietf.org/mail-archive/web/spfbis/current/msg04160.html 
).  The Area Director  asked about changes and provided an example of 
what he means.  I thought that what I suggested was clear.

The matter is about how RFCs are written.  I read the message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg04178.html and 
I don't see anything relating to how RFCs are written.

Regards,

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 16 Sep 2013 10:41:35 -0400

I've trimmed the ccs.  This is clearly right back to fodder for the
spfbis list.  If I have a hat on below, I'll note it.

On Fri, Sep 13, 2013 at 08:56:55PM -0700, Douglas Otis wrote: 

> In my defense, may I ask whether the draft
> http://tools.ietf.org/html/draft-otis-spfbis-macros-nixed-01 been
> reviewed?

By me?  Yes.  Widely?  Apparently not.
 
> It contains a reference to a survey by the SPF website
> http://spf-all.com/stats.html which indicates of all domains
> publishing SPF records 99.947% contain no macros.  It seems a
> reasonable person would wonder why.

Yes, and it is entirely reasonable that anyone might.  But it doesn't
matter, because there's half a percent that _do_ have macros, and SM
and I (as chairs) already determined earlier in the WG's life that
"unused" meant "not used at all".  Therefore, macros cannot be
deprecated by the WG.  That's a consequence of our charter.
  
> I hope you can imagine what this might mean from the perspective of
> network amplifications 

I am somewhat conversant with network amplifications via DNS.  It is
interesting to me that, despite the attractive nuisance that DNS
provides in terms of amplifications, for reasons totally mysterious to
me I have never once, in any log I have reviewed, seen evidence of an
SPF-based attack of the sort you keep talking about.  That is not to
say that your observations are wrong: SPF clearly provides an
extremely useful attack vector.  But I find it interesting that SPF
does not appear to be central.  This is quite possibly because
mounting the SPF based attack you're talking about requires
considerably more co-ordination among the moving parts than
straightforward amplification via plain DNS spoofing.  (I could come
up with some other explanations, of equivalent degree of rank
speculation if you'd like, but I think one such speculation is enough
for these purposes.)

> At the same time, it seems irresponsible to completely deprecate use
> of the dedicated RR record type that had a much higher level of use
> while not deprecating a far more dangerous macro option used by far
> fewer domains.  Such an oversight can not be excused by blaming the
> charter.

With my chair hat on: the reason RRTYPE 99 is deprecated is _not_
because it's unused, but because there is an interoperability problem
in RFC 4408.  We _had to_ do something, in order to move the protocol
to the standards track, because a standards track document needs to
have no such known and unaddressed flaws.  The same is _not_ true of
the options you're talking about: they may have some negative
consequences, but those consequences are called out in the document.
The WG was chartered on the condition, in effect, that it not change
SPF unless something was totally broken or actually unused.  Since you
note, in your message, that macros and so on _are_ in fact used, and
since there is no analagous problem with the specification _per se_ as
there was in the case of the DNS RRTYPEs, we are not free to deprecate
as you appear to want.

I am pretty sure that has been explained on list more than once.  If
it is even remotely unclear to you, I suggest you contact me off
list so that I can explain it in a way you can understand it.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 16 Sep 2013 12:03:44 -0700

> By me?  Yes.  Widely?  Apparently not.

I reviewed it, though it was admittedly some time ago.  I remember thinking
these things:

1) The draft doesn't identify a single instance of a site that has chosen
not implement macros.  This is in contrast to the numerous applications
that use libspf2 to build their SPF checking applications, and to the two
commercial solutions with which I'm familiar, none of which permit one to
selectively disable macros.  I understand the need to keep client details
confidential, but it leaves me wondering why your client base is so
different than everything else I've observed.  In contrast, RFC6648
revealed numerous details about its survey sources, and its methods could
be repeated today, likely with similar results since they are so clearly
described, so I would argue that it's far more credible work.

2) As Andrew observed, there has also not been a document case of the
amplification attack in the wild.  It seems to me that if this were an
interesting or worthwhile exploit, we'd have seen one happen by now.

3) As Andrew also observed, we are unable to remove it even with the slim
use that's been documented.  People (including me) made a pretty hard push
for it, but we are, at least right now, procedurally constrained against
doing so.

4) Your co-author on this draft (and on the DKIM one, and on the recent
IESG appeal about DKIM) is an awfully quiet person for such a passionate
and potentially serious topic.  Does he not care to help you defend the
position you're taking?

-MSK

---

From: Mark Andrews <[email-masked]>
Date: Tue, 17 Sep 2013 08:04:03 +1000

In message <CAL0qLwbW0d8j-vqqxM=d=[email-masked]>
> interesting or worthwhile exploit, we'd have seen one happen by now.

No.  This is bad reasoning.  There have been lots of theoretical
attacks that have taken a long time to before we see them used in anger.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 16 Sep 2013 18:59:39 -0400

No hat.

> attacks that have taken a long time to before we see them used in anger.

Yes.  That is why I asked about the liklihood of the attack in
question being deployed.  It seems to me that it is quite a lot more
complicated than the attacks that are quite straightforwardly
available to DNS as it stands, and which while individually less
severe are much more easily delivered at large scale.  So, in my
opinion, the concern about SPF-based attacks using vast volumes of SPF
processing triggering events due to macros and so on is misplaced.

Supposing that I'm wrong, however, it seems to me that sites could
trivially protect themselves from this by refusing to process macros
anyway.

So I just don't get what the excitement is about.  It's a
theoretically devastating attack, just like a full-on siege of the
Maginot line with overwhelming force might have been.  As we actually
saw, there was a considerably less taxing path for attack.

Unless there is some new evidence introduced, I'm not interested in
this topic any more.  It doesn't appear to be yielding any new
evidence.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: John Leslie <[email-masked]>
Date: Mon, 16 Sep 2013 19:49:27 -0400

> deprecated by the WG.  That's a consequence of our charter.

   I chose not to question that interpretation -- it's not worth flamewars
for an issue like this one.

> SPF-based attack of the sort you keep talking about.

   My preference would be to note the issue; and comment that such an
occurance has never been observed. (I don't propose to deprecate macros
at this time; but there may be reason to partially or fully deprecate
them at some later time.)

> there was in the case of the DNS RRTYPEs, we are not free to deprecate

   I accept that. Nonetheless, The possible amplification is real, and
IMHO deserves a mention in Security Considerations.

> list so that I can explain it in a way you can understand it.

   Doug is an engineer at heart. He likes to _fix_ problems.

   There is a middle ground, where one documents problems, and leaves
fixing them to some future action.

--
John Leslie <[email-masked]>

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 16 Sep 2013 20:09:36 -0400

> fixing them to some future action.

There is a claimed problem.  To the extent there is an actual problem, it's a 
DNS problem.  There are many ways to get DNS amplification.  This is (maybe) 
one example of a larger issue.  SPF, by definition, inherits all of DNS' 
weaknesses.  We don't document them all and I don't see any benefit in treating 
this one specially.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Tue, 17 Sep 2013 00:34:22 -0700

Dear Andrew,

See comments inline.

> deprecated by the WG.  That's a consequence of our charter.

May I make minor corrections to your comments?

The number of domains publishing macros is not 0.5 percent but 0.05%.  There are 20 times this number of domains publish erroneous SPF records.  Does it really make sense to place DNSSEC at risk to support such a vanishingly small minority?  Removing a seldom used, highly complex, and risky feature should be well within the charter.   

> SPF-based attack of the sort you keep talking about.

This macro feature is not supported by major providers, where its use threatens interchange and places DNS at risk.

> That is not to
> have no such known and unaddressed flaws.

Having a completely indefensible macro feature dumping queries into DNS is not a serious flaw?

Purporting a feature that lacks negotiation in fact not widely supported is not a serious flaw?

If this document gets published, it should be as informational. 

> The same is _not_ true of

"Some negative" is a massive understatement.  The potential, as I understand the situation, is actively being suppressed.  Enabling DNS logging could confirm the level of support. 

Ignoring SPF records that contain macros explains why erroneous SPF records are present in much greater numbers.  It seems everyone knows publishing macros is clearly a mistake.

> SPF unless something was totally broken or actually unused.

If the goal is to support interchange, remove macros.  Assume macros was a bad idea that never found traction or that were actively suppressed.

> Since you

You are comparing an extra query to greatly increased gain enabled through use of macros?  I am at a loss to understand this line of reasoning.   A statement that some future version will remove use of TXT records offers a clear incentive and solution.  Those that don't change receive neutral handling.  Not a major issue.  The same should be true for the 0.053% of domains publishing macros.

> list so that I can explain it in a way you can understand it.

Clearly we see this issue much differently.  Perhaps facing the brunt of DDoS changes one's perspective.  It is not right to suggest the risk being created by this protocol offering automation of a massive sequence of random queries from cached records by unknown entities is somehow up to DNS to solve?  Please describe how DNS can be defended when SPF macros are being abused. 

Regards,
Douglas Otis

---

From: Douglas Otis <[email-masked]>
Date: Wed, 18 Sep 2013 09:07:27 -0700

On Sep 16, 2013, at 12:03 PM, Murray S. Kucherawy <[email-masked]> wrote:

> On Mon, Sep 16, 2013 at 7:41 AM, Andrew Sullivan <[email-masked]> wrote:
> I reviewed it, though it was admittedly some time ago.  I remember thinking these things:
> 
> 1) The draft doesn't identify a single instance of a site that has chosen not implement macros.  This is in contrast to the numerous applications that use libspf2 to build their SPF checking applications, and to the two commercial solutions with which I'm familiar, none of which permit one to selectively disable macros.  I understand the need to keep client details confidential, but it leaves me wondering why your client base is so different than everything else I've observed.  In contrast, RFC6648 revealed numerous details about its survey sources, and its methods could be repeated today, likely with similar results since they are so clearly described, so I would argue that it's far more credible work.

You meant RFC6686.  Several assumptions are being made about the use of macros in these conversations, but this survey ignored SPF macro publication or SPF macro processing.   As such there is no support regarding the use or the problems such use should been expected to cause.  Lack of information does not offer any credible information regarding this aspect of SPF.

> 2) As Andrew observed, there has also not been a document case of the amplification attack in the wild.  It seems to me that if this were an interesting or worthwhile exploit, we'd have seen one happen by now.

Problems with making these assumptions:

1) SPF does not use dedicated resource records or naming conventions to easily identify underlying sources of possible SPF driven queries.
2) DDoS attacks that exploit SPF can make a large number of "normal" queries without identifying their use.
3) Not all DDoS attacks are being reported.  Many are not.
4) Major providers will permit exploitation of their resources via SPF.
     Rather than enduring the massive code size and associated high DNS overhead, 
     major providers are more likely to use SPF to weigh IP addresses beforehand. 

There have been recent massive DDoS attacks so extreme care must be taken in this regard.

> 3) As Andrew also observed, we are unable to remove it even with the slim use that's been documented.  People (including me) made a pretty hard push for it, but we are, at least right now, procedurally constrained against doing so.

An argument can be made that when a very very small number of domains publish a resource record, minimalistic publication should not be considered evidence of use or to represent consensus about a feature becoming part of a standard.  This would suggest instead the document should be considered informational on that basis.  When 0.00053 of domains publishing SPF records publish records containing macro expanded terms this should not be considered evidence of use.  Just the opposite is more likely true.  Secondly, there has not been any interchange testing (even by way of DNS logging of macro derived targets) to confirm whether such publication offers reasonably assured interchange.  Instead, this issue has been ignored by the survey and the WG in terms of use and security considerations. 

> 4) Your co-author on this draft (and on the DKIM one, and on the recent IESG appeal about DKIM) is an awfully quiet person for such a passionate and potentially serious topic.  Does he not care to help you defend the position you're taking?

Does a low rate of emails equate to non-support?

Regards,
Douglas Otis