Subject: Fwd: [dnsext] SPF isn't going to change, was Deprecating SPF

From: manning bill <[email-masked]>
Date: Fri, 23 Aug 2013 10:45:14 -0700

Begin forwarded message:

> Resent-From: [email-masked]
> From: [email-masked]
> Subject: Re: [dnsext] SPF isn't going to change, was Deprecating SPF
> Date: August 23, 2013 10:03:26 PDT
> Resent-To: [email-masked]
> To: John Levine <[email-masked]>
> Cc: [email-masked]
> 
> On Fri, Aug 23, 2013 at 03:14:38PM -0000, John Levine wrote:
>> I counted my queries from a few days ago and got 7086 TXT, 263 SPF, or 3.7%.
>> 
>> Nobody has argued that SPF usage is zero, and the reasons for
>> deprecating SPF have been described repeatedly here and on the ietf
>> list, so this exercise seems fairly pointless.
> 
> 	the reasons for not deprecating SPF have been described here
> 	and on the ietf list repeatedly ... yet there has been little
> 	concrete data regarding deployment uptake. These published
> 	snapshots form a baseline - 201308, and it might be worthwhile
> 	to look again in six months to see if the magnitude and ratio 
> 	have changed.  The results of a second look should bring into
> 	focus the prevaling trends and solidify the argument.
> 
> 	Surely there is no compelling urgency to conclude the current 
> 	LC - given the duration of this work a six month period to 
> 	gain emperical insight would not be a bad thing.
> 
> 	Would it?
> 
> /bill
> 	
>> 
>> R's,
>> John
>> _______________________________________________
>> dnsext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dnsext
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

---

From: "John Levine" <[email-masked]>
Date: 23 Aug 2013 18:04:11 -0000

>> 	concrete data regarding deployment uptake.

Sigh.  We have RFC 6686.  Since this is clearly an issue you consider
to be of vital importance, it is baffling that (as far as I can tell)
you did not contribute to or even comment on it when it was being
written and published.

Those of us in the mail community have a lot of anecdotal evidence,
too.  Most notably, none of the large providers that dominate the mail
world publish or check type 99, and the one that used to check type 99
(Yahoo) doesn't any more.  You don't have to like it, but it's silly
to deny it.

In any event, it's purely a strawman that "nobody" checks type 99.  A
few people do, the WG knows that, and we decided for well documented
reasons to deprecate it anyway.

R's,
John

---

From: manning bill <[email-masked]>
Date: Fri, 23 Aug 2013 12:46:27 -0700

> you did not contribute to or even comment on it when it was being

work assignments occasionally take me away from active engagement in
IETF matters.  sorry for the few years absence.  

> (Yahoo) doesn't any more.  You don't have to like it, but it's silly

	not sure why you think the DNS data presented is anecdotal.  Looked
	kind of empirical to me.   i've not seen a yahoo person describe what 
	they have or have not done or why.  we have no data on why Microsoft
	may or may not support type 99 (see Jay's questions).   Much of the
	mail community data seems anecdotal…  very little first hand, empirical 
	stuff.  (and I thank you for your data)

> reasons to deprecate it anyway.

	demuxing type 16 records is a choice.  using type 99,  which was specifically
	designed for this use, is a choice.  using application specific types have distinct
	technological advantages (see PHB comments).  They may be small, but are real
	and have an impact on the DNS and the application.

	regarding the specific claims regarding adoption, I was asking for a brief period
	to collect more empirical data to track the magnitude and ratio of type 99 v. type 16
	use (noting, as PAF has already noted, that not all type 16 == type 99, so for accurate
	understanding - someone needs to look at type 99 muxed into a type 16 format…  if only
	to correctly understand the change in ratio.

	the question is not that "nobody" checks type 99, the question is "is the rate of adoption
	of type 99 -changing- in relation to type 16?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 24 Aug 2013 08:39:36 -0400

>         of type 99 -changing- in relation to type 16?

As John pointed out, support for checking type 99 has decreased and
continues to decrease rather than increase. So waiting longer is not going
to solve the issue.

Putting a statement in an RFC does not mean that the world will
automatically advance towards that particular end state.

Forcing a WG to adopt a position to suit another constituency is not going
to lead them to advocate for that position in deployment constituencies.
Particularly when the original constituency does nothing to advance
deployment.

-- 
Website: http://hallambaker.com/

---

From: Hector Santos <[email-masked]>
Date: Sat, 24 Aug 2013 12:26:49 -0400

> continues to decrease rather than increase. So waiting longer is not going

However, the interest never disappeared.  The issue is what are we 
waiting for now?  The DNS infrastructure support?  Why it that such a 
problem?  Who goes to these IETF meetings?  Where are the Microsoft 
DNS product managers in these discussions?  What do they have to say?

> automatically advance towards that particular end state.

Thats correct. No one is forced to support RFC 4408bis.  From my 
perspective, there are four basic major changes to BIS - all optional:

   1 - Add Authentication-Result: 5322.header.
   2 - Relax SPF HardFail Policy rejections to Accept-Mark operations.
   3 - If 2 is perform, then add code to separate user failed messages.
   4 - Remove any support for SPF type99 queries and publishing.

For our SPF implementation, we never did #4 for lack of infrastructure 
readiness but are ready to support once the the backbone is ready for 
it. We will probably will do #1 for all non-HARDFAIL result but we 
won't do #2 because it will cause a high redesign cost with #3.  Not 
performing #3 would be a major security loophole is you begin to 
support #2. Until we are ready to do #3 and close that security 
loophole, #2 won't happen.

> Particularly when the original constituency does nothing to advance

+1, but the decision makers really haven't ask the main DNS 
constituencies why they have not advanced their (DNS) software or made 
it flexible enough for another operators and administrators to 
add/manage new RR types or capable of passive and transparent handling 
of unknown type recursive passthru queries.

To me, this should be a project leadership responsibility to make sure 
the protocol requirements are realistic are not.

--
HLS

---

From: Hector Santos <[email-masked]>
Date: Sat, 24 Aug 2013 12:39:52 -0400

Hector Santos wrote:
> it. We will probably will do #1 for all non-HARDFAIL result but we won't 
> do #2 because it will cause a high redesign cost with #3.  Not 
> performing #3 would be a major security loophole is you begin to support 
> #2. Until we are ready to do #3 and close that security loophole, #2 
> won't happen.

I should add:

     5- Deprecate PTR by removing PTR publishing support

We won't advocate this because for our small to mid size market, this 
is the lowest cost setup for them - using a PTR.  For all our domains, 
we use PTR as well.  No need to change it. This is one of those "Set 
it and Forget it" SPF record setups. Using the PTR was the default 
arrangement for most small/mid operations provided by most if not all 
the SPF Web Wizards.  This was removed in Scott's popular SPF wizard 
but not in other SPF wizards.  Note: The overhead concerns are passe 
with the trend of SMTP receivers doing PTR lookups, thus any 
transaction SPF validator will not contribute to any PTR network overhead.

--
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 24 Aug 2013 12:53:59 -0400

Hector Santos <[email-masked]> wrote:
>won't 
>support 

That's not correct.  PTR is not removed from the protocol, so software support shouldn't change.

I don't run an SPF wizard. 

It's not just about overhead. 

Scott K

---

From: Hector Santos <[email-masked]>
Date: Sat, 24 Aug 2013 13:10:09 -0400

> software support shouldn't change.

I believe I stated deprecate above which is the current draft 
recommendations for not recommending PTR publishing in SPF records. 
Is this still incorrect?

> I don't run an SPF wizard. 

I thought you managed this SPF wizard at http://openspf.org/tools ?? 
You don't? Ok I see it was taking down. Ok, sorry, well, you know what 
I mean - it did have the PTR publishing as part of a natural default 
setup and if not all the SPF wizards did as well. Is that not correct?

> It's not just about overhead. 

So why was PTR deprecated?

--
HLS

PS: I am not trying to change anything about the PTR 4408BIS status. 
Just pointing out that a change was made that does touch base with 
operations and thus not supporting (or delaying, forever) this part of 
4408BIS is highly possible.

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 24 Aug 2013 20:24:56 -0400

> setup and if not all the SPF wizards did as well. Is that not correct?

It did.  That's part of why it was taken down.  It made poor recommendations 
and several people finally concluded having nothing was better than continuing 
to provide that one.

> So why was PTR deprecated?

See http://tools.ietf.org/wg/spfbis/trac/ticket/27 and the ML archives.  The 
ticket can give you an idea of the time frame to look in the archives.  Note 
that the final language doesn't use the word "deprecated". 

You might change what you recommend people publish, but nothing in 4408bis 
should affect the code related to PTR.  

Scott K

---

From: Hector Santos <[email-masked]>
Date: Sat, 24 Aug 2013 21:39:06 -0400

> should affect the code related to PTR.  

True, I was among the group of WG participants who felt a full PTR 
deprecation would be incorrect. As it was originally drafted, new 
SPFBIS parsers did not need to code the rDNS logic.

draft-ietf-spfbis-4408bis-00:

    5.5.  "ptr"
    ...
    This mechanism is deprecated and SHOULD NOT be used.

After debates, updated to draft-ietf-spfbis-4408bis-15:

    5.5.  "ptr" (do not use)
    ...
    This mechanism SHOULD NOT be used.  See below for discussion.

After more debates, finally changed by rev 15 as it stands now with 
draft-ietf-spfbis-4408bis-19:

    5.5   "ptr" (do not use)
    ...
    This mechanism SHOULD NOT be published.  See below for discussion.

With other text in the spec codifying it MUST be part of the 
processor, I think its fine. But it could still can give new future 
readers/developers of SPF parsers the idea that it doesn't need to 
parsed.  Just consider relaxed policies are still accepted messages. 
Decreasing amount of records seen with a PTR with anything less than a 
-ALL policy could provide optimizing material to punk on the PTR 
processing.  Just saying.

--
HLS

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 25 Aug 2013 10:07:23 +0100

On Sat, Aug 24, 2013 at 6:43 PM, <[email-masked]> wrote:

> On Sat, Aug 24, 2013 at 08:39:36AM -0400, Phillip Hallam-Baker wrote:
> > >         the question is not that "nobody" checks type 99, the question
> is
> > > "is the rate of adoption
>         that is unclear...  we have second hand reports, but only actual
>         data from very recent DNS logs.   did those numbers increase or
>         decrease?  No evidence has been presented.

We have statements from people who are involved in the industry concerned
and no reason to believe that they are lying.

This is not a reasonable objection and it is really not at all surprising
that people are getting rude when people are refusing to accept what the WG
considers established facts.

>         ain't it the truth.  -BUT- its still worthwhile documenting the
>         best technical path and why it was abandoned.   The issues wrt
>         wildcards (thanks), DNSSEC considerations,  and code overhead to
>         demux type 16  vs.  the temporary problem of two lookups -IF- type
>         99 is not used, plus past guidance from the IAB and the IESG really
>         need to make it into a document in the RFC cannon.

I don't think it was ever about the right technical path. It was about the
DNSEXT group not caring to bother to get their DNSSEC infrastructure
adopted by the constituencies they needed buy in from then trying to make
that effort the problem of the SPF people.

>         Dorthy Parker said: "You can lead a whore to culture, but you
> can't make her think".
>         Point the bias arrow either way youd like.  And as stated
> elsewhere, if Yahoo, Google,
>         Microsoft, AOL, et.al.  were simply waiting for the IETF to
> settle on a solution,
>         I'll raise O'Dells law;  "The installed base does not matter"
>

Its a stupid and wrong 'law'.

The deployed base is all that matters because before you get to the 'viral
marketing' network effects give you the 'chicken and egg problem'.

The reason HTTP and the Web took off was because we actually designed it to
take off fast. Meanwhile IPv6 and DNSSEC are still in the same state they
were 15 years ago, on the cusp of deployment in 5 years time. A large part
of the reason has been that the people pushing those initiatives have acted
as if deployment was inevitable.

I ran simulation studies of adoption to work out how to sell the Web.

The companies you cite have no stake in DNSSEC deployment. So why expect
them to favor a technical measure designed to facilitate DNSSEC deployment?

---

From: [email-masked]
Date: Sat, 24 Aug 2013 17:43:10 +0000

> Particularly when the original constituency does nothing to advance

	Dorthy Parker said: "You can lead a whore to culture, but you can't make her think".
	Point the bias arrow either way youd like.  And as stated elsewhere, if Yahoo, Google,
	Microsoft, AOL, et.al.  were simply waiting for the IETF to settle on a solution,
	I'll raise O'Dells law;  "The installed base does not matter".

	End of the day, the SPFBIS wg is adament in their choice, document, explain
	and move on.  

	Robert Heinlein: Never try to teach a pig to sing; it wastes your time and it
	annoys the pig.

	I think the SPFBIS folks are annoyed enough...