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

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

On 23August2013Friday, at 11:04, John Levine wrote:

>>>> 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.
> 
> 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.

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

> 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.

	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)

> 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.

	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?

> R's,
> John

---

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: [email-masked]
Date: Sat, 24 Aug 2013 17:43:10 +0000

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

	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.

> automatically advance towards that particular end state.

	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.

> 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...

> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

---

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:

> > >         the question is not that "nobody" checks type 99, the question
> is
> > > "is the rate of adoption

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.

>         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.

>         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?