Subject: Re: [spfbis] Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT)

From: S Moonesamy <[email-masked]>
Date: Mon, 09 Sep 2013 12:07:23 -0700

Hi Scott,

Could you please address the following DISCUSS and the COMMENT?

Thanks,
S. Moonesamy (as document shepherd)

At 06:55 07-09-2013, Pete Resnick wrote:
>Pete Resnick has entered the following ballot position for
>draft-ietf-spfbis-4408bis-19: Discuss
>
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
>
>
>Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>for more information about IESG DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/
>
>
>
>----------------------------------------------------------------------
>DISCUSS:
>----------------------------------------------------------------------
>
>Holding my own DISCUSS:
>
>Text needs to be created (probably for section 3.1) to better describe
>the reason this document settled on TXT RR only and therefore why no
>precedent is set for future use of the TXT RR.
>
>
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>Clarifications needed regarding size limitations in 3.4, and perhaps some
>clarifications in 4.6.4.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 10 Sep 2013 08:16:03 -0400

> S. Moonesamy (as document shepherd)

Yes.  See text at the end for proposed changes.  I'm proposing changes 
regarding 3.1 and 3.4.  I did review 4.6.4 again and did not determine a 
better way to say it, so no changes are proposed there.  I'm also attaching a 
full rfcdiff of the changes I have locally for the to be 20.  Some predate IETF 
Last Call and some (the ABNF changes) are changes I recommend based on the LC 
discussion.

Scott K

> >http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/

3.1.  DNS Resource Records

   SPF records MUST be published as a DNS TXT (type 16) Resource Record
   (RR) [RFC1035] only.  The character content of the record is encoded
   as [US-ASCII].  Use of alternative DNS RR types was supported in

WAS

<    SPF's experimental phase, but has been discontinued.  See Appendix A
<    of [RFC6686] for further information.

PROPOSED

>    SPF's experimental phase, but has been discontinued.
>
>    In 2003, when SPF was first being developed, the requirements for
>    assignment of a new DNS RR type were considerably more stringent than
>    they are now.  Additionally, support for easy deployment of new DNS
>    RR types was not widely deployed in DNS servers and and provisioning
>    systems.  As a result, at that time, there was no reasonable
>    alternative to using the TXT RR type for SPF records.
>
>    In its review of [RFC4408] the SPFbis working group concluded that
>    its dual RR type transition model was fundamentally flawed since it
>    contained no common RR type that implementers were required to serve
>    and required to check.  Many alternatives were considered to resolve
>    this issue, but ultimately the working group concluded that
>    significant migration to the SPF RR type in the forseable future and
>    that the best solution for resolving this interoperability issue was
>    to drop support for the SPF RR type from SPF version 1.  See Appendix
>    A of [RFC6686] for further information.
> 
>    The circumstances surrounding SPF's initial deploymenta decade ago
>    are unique and very, very unlikely to be repeated.  SPF's use of the
>    TXT RR type for structured data should in no way be taken as
>    precedent for future protocol designers.  Things have changed.

3.4.  Record Size

   The published SPF record for a given domain name SHOULD remain small
   enough that the results of a query for it will fit within 512 octets.
   This UDP limit is defined in [RFC1035] section 2.3.4, although it was
   raised by [RFC2671].  Staying below 512 octets ought to prevent older
   DNS implementations from failing over to TCP,and will work with UDP
   in the absence of EDNS0 [RFC6891] support.  Since the answer size is
   dependent on many things outside the scope of this document, it is

WAS

<    only possible to give this guideline: If the combined length of the
<    DNS name and the text of all the records of a given type is under 450
<    octets, then DNS answers ought to fit in UDP packets.  Records that
<    are too long to fit in a single UDP packet could be silently ignored
<    by SPF verifiers due to firewall and other issues that interfere with
<    the operation of DNS over TCP or using ENDS0.

PROPOSED

>    only possible to give this guideline: If the size of the DNS message,
>    the combined length of the DNS name and the text of all the records
>    of a given type is under 450 octets, then DNS answers ought to fit in
>    UDP packets.  Records that are too long to fit in a single UDP packet
>    could be silently ignored by SPF verifiers due to firewall and other
>    issues that interfere with the operation of DNS over TCP or using
>    ENDS0.

   Note that when computing the sizes for replies to queries of the TXT
   format, one has to take into account any other TXT records published
   at the domain name.  Similarly, the sizes for replies to all queries
   related to SPF have to be evaluated to fit in a single 512 octet UDP

WAS

<    packet.

PROPOSED

>    packet (i.e.  DNS message size limited to 450 octects).

---

From: S Moonesamy <[email-masked]>
Date: Tue, 10 Sep 2013 11:33:43 -0700

Hi Pete,

I'll post some text proposed by Scott Kitterman to address the 
DISCUSS.  I am adding the SPFBIS WG to the Cc.

>draft-ietf-spfbis-4408bis-19: Discuss

[snip]

>precedent is set for future use of the TXT RR.

[snip]

WAS

PROPOSED

3.4.  Record Size

WAS

PROPOSED

WAS

<    packet.

PROPOSED

 >    packet (i.e.  DNS message size limited to 450 octects).

Regards,

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 10 Sep 2013 15:01:19 -0500

On 9/10/2013 1:33 PM, S Moonesamy wrote:

Hi, SM,

> PROPOSED
>
> >    Many alternatives were considered to resolve
> >    to drop support for the SPF RR type from SPF version 1. 

I liked where the proposed text seemed to be headed, but this sentence 
didn't parse for me (missing words?), and it seems like a really 
important sentence ...

Spencer

---

From: S Moonesamy <[email-masked]>
Date: Tue, 10 Sep 2013 13:24:05 -0700

Hi Spencer,
At 13:01 10-09-2013, Spencer Dawkins wrote:
>I liked where the proposed text seemed to be headed, but this 
>sentence didn't parse for me (missing words?), and it seems like a 
>really important sentence ...

Yes, there are some words missing.

Can the SPFBIS WG please review the text in the message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg04104.html and 
suggest text to address the DISCUSS (see 
http://www.ietf.org/mail-archive/web/spfbis/current/msg04099.html ).

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 10 Sep 2013 21:38:01 -0400

> didn't parse for me (missing words?), and it seems like a really

Here's the fixed sentence.  I suspect the truth may be less dramatic than you 
imagined.  I also got a bit more expansive in the last paragraph.  I've 
attached a revised rfcdiff for the total local diff I'm carrying now.  Here's 
what I have now:

   In its review of [RFC4408] the SPFbis working group concluded that
   its dual RR type transition model was fundamentally flawed since it
   contained no common RR type that implementers were required to serve
   and required to check.  Many alternatives were considered to resolve
   this issue, but ultimately the working group concluded that
   significant migration to the SPF RR type in the forseable future was
   very unlikely and that the best solution for resolving this
   interoperability issue was to drop support for the SPF RR type from
   SPF version 1.  See Appendix A of [RFC6686] for further information.

   The circumstances surrounding SPF's initial deploymenta decade ago
   are unique and very, very unlikely to be repeated.  If a future
   update to a new SPF version that could not reuse existing SPF records
   were to be developed, it ought to use the SPF RR type.  SPF's use of
   the TXT RR type for structured data should in no way be taken as
   precedent for future protocol designers.  Things have changed.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Wed, 11 Sep 2013 05:39:22 -0400

>     SPF version 1.  See Appendix A of [RFC6686] for further information.

I would remove the word "fundamentally", fix up or remove the first 
sentence. The only real reason for lack of support is that DNS servers 
across the board were not ready for it.

Consider:

If the DNS servers were ready for it, then this would be a functional 
description correction not a removal.

Consider:

If the DNS Servers were ready for it, then the market would of figured 
out the best query method with minimal overhead, which is SPF first, 
TXT fallback.  Publishers and Receivers would of figured it out and 
that would of been codified.

But its lack of support was 100% related to the market not being ready 
to handle it. Period, and in my view, any future new RR type proposal 
will also be in the same position.

>     are unique and very, very unlikely to be repeated.

I don't think so. All it takes is someone to bring it up, like with DMARC.

>     If a future
>     were to be developed, it ought to use the SPF RR type.

Not until the DNS servers across the board support it.  A future one 
will most likely use a subdomain TXT format.

>     SPF's use of

No it hasn't change.  DNS servers do no support them, period. Like it 
or not, we have to lump Microsoft servers in this support picture. 
Until MS DNS servers support it, we won't get wide support for this 
type99 type or any future new RR type proposal.  We will be in the 
same predicament and it will not be practical to explore any new type 
other than TXT.  Just look at DMARC.  I extremely doubt a primary new 
RR type with a TXT fallback will be acceptable here by the key 
designers of it.

So lets be real about this.  I like the first paragraph. But the only 
reason for removal is lack of infrastructure support.  Keep it simple.

To me, the main lesson learned is that TXT is acceptable for future 
proposals (with a subdomain zone) and thats really all that is 
extractable by all this.  TYPE99 didn't work for a lack for 
infrastructure support -- with Microsoft DNS servers included in the 
lack of support.  Its not just a Bind world.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Sep 2013 06:39:58 -0700

>    RR types was not widely deployed in DNS servers and and provisioning

Drop one of those "and"s.  I don't care which one.

>    significant migration to the SPF RR type in the forseable future was

"foreseeable"

>    The circumstances surrounding SPF's initial deploymenta decade ago

"deployment a"

>    precedent for future protocol designers.  Things have changed.

What about "SPF's use of the TXT RR type located at the domain apex"?  As I
understand it, part of the complaint is the location of the record, not
just its type.  The underscore mechanism used by DKIM, DMARC, ADSP, VBR,
etc. seems to be gaining acceptance, or at least tolerance, because it
avoids query collisions.

Otherwise, looks okay to me.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 10 Sep 2013 19:32:40 -0400

I was pretty fatigued when I wrote that.  I promise it was beautiful in my head.  Sorry for the confusion.  I'll fix it tonight after I'm back with the computer ith the document on it.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 11 Sep 2013 12:54:54 -0400

> Drop one of those "and"s.  I don't care which one.

Fixed.

> >    significant migration to the SPF RR type in the forseable future was

Fixed.

> >    The circumstances surrounding SPF's initial deploymenta decade ago

Fixed.

> precedent is set for future use of the TXT RR.

I think adding something "if you use TXT anyway, use this underscore 
mechanism" isn't germane since it wasn't an option SPFbis could consider.

I can add something along those lines, I guess, but I'm not sure it's needed.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Sep 2013 10:02:57 -0700

> > Drop one of those "and"s.  I don't care which one.

The WG may disagree with the choice you made as to which one you removed.
Be prepared to explain it.

> I can add something along those lines, I guess, but I'm not sure it's
My issue is that the second-last sentence there basically says "don't use
TXT for structured data in the future" as a pretty absolute thing, but in
fact the underscore "loophole" is currently something the community is
tolerating.  It seems incorrect.  I know underscore wasn't an option for
us, but as pedagogy for future protocol developers, it doesn't tell the
whole story either.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 11 Sep 2013 14:02:13 -0400

"Murray S. Kucherawy" <[email-masked]> wrote:
>> > What about "SPF's use of the TXT RR type located at the domain
>apex"?
>>  As I

I agree.  I wasn't trying to to the whole story.  I was trying to address the issue that was raised. 

In case Pete wants to include something about the "underscore loophole", would you suggest text please? 

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Sep 2013 14:26:28 -0700

> would you suggest text please?
 Nevermind, Pete talked me out of it.  I withdraw the suggestion.

-MSK

---

From: Pete Resnick <[email-masked]>
Date: Wed, 11 Sep 2013 16:56:52 -0500

On 9/11/13 4:39 AM, Hector Santos wrote:
>>     they are now.

I think this is reasonable to leave in, Hector's comments 
notwithstanding. It may not have been the primary problem, but it 
certainly didn't help.

>>     As a result, at that time, there was no reasonable

No need to be overly proud here. I suggest, "As a result, proponents of 
SPF found it easier and more practical to use the TXT RR type for SPF 
records."

>>     and required to check.
> I would remove the word "fundamentally"

(*Shrug*) Stylistic choice. I don't think it makes a difference.

> I don't think so.

Yeah, I'd drop the "and very, very unlikely to be repeated." This 
document doesn't need to be in the soothsayer business.

I'd also be OK with s/are unique/were different than the circumstances 
today.

Either way.

>>     were to be developed, it ought to use the SPF RR type.

Not wishing to argue the point with Hector, but also not inclined to 
come down on one side or the other. How about:

"If a future update to SPF were developed that did not reuse existing 
SPF records, it could use the SPF RR type."

> No it hasn't change.

Again, not wishing to argue the point, because it doesn't matter. I'm 
fine with striking "Things have changed". I'd also like to see an 
information reference, like: "Further discussion of design 
considerations when using new DNS RRs can be found in [RFC5507]."

It is not the job of this document to debate or judge the actual state 
of the current DNS infrastructure, only to document what this protocol 
did in the past and give pointers for future debate.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 11 Sep 2013 18:01:31 -0400

On Wednesday, September 11, 2013 16:56:52 Pete Resnick wrote:
> >>     assignment of a new DNS RR type were considerably more stringent
> >> 
> >> than
> >> 
> >>     they are now.
> 
> >>     update to a new SPF version that could not reuse existing SPF
> >> 
> >> records
> >> 

I think all of Pete's suggestions are good.  Should I go ahead and update my 
local copy of the to be -20?

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Wed, 11 Sep 2013 15:09:37 -0700

Hi Scott,
>local copy of the to be -20?

Okay.  Please go ahead and update your local copy.  Please do not 
post a new revision of the draft.

Could you please send me the text or post the text to the SPFBIS 
mailing list so that this change is clear to everyone?  This was the 
main issue raised during the Last Call.  It would make the rest of 
the work easier if we can get this one out of the way.

Regards,

---

From: Mark Andrews <[email-masked]>
Date: Thu, 12 Sep 2013 08:21:27 +1000

Why don't we just be honest and state that the working group did
not proceed with the migration because Microsoft failed to supply
a RFC 1304 compliant resolver (no support for arbitary type lookups),
and failed to supply a authoritative nameserver that supported
arbitary types despite RFC 3597 (standards track) stating how to
do so for the Microsoft Windows platform.  They also failed to
extend the resolver and nameserver to have type specific support
for the SPF record in RFC 4408.  This is despite all other major
nameserver vendors having support for arbitary types and/or type
specific support for the SPF record.

In message <1623078.iZZXT7WM88@scott-latitude-e6320>, Scott Kitterman writes:
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Sep 2013 15:52:36 -0700

> specific support for the SPF record.
I wasn't aware that this had anything to do with Microsoft in particular.
There have been ample examples presented on these threads of provisioning
systems and the like failing to support type 99 that were not developed by
Microsoft.  I could be completely wrong, but this is the first I've heard
of a specific vendor being identified as "the" problem.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Wed, 11 Sep 2013 15:51:17 -0700

Hi Mark,
>specific support for the SPF record.

I do not have any affiliation with the vendor mentioned above.

The above (see quoted text) are DNS issues.

Here is what Pete Resnick as Area Director wrote:

   "- The document needs to make a statement in the document clarifying why
      the SPF RR is no longer used in the spec and making it clear that no
      precedent should be created by this protocol's continued use of TXT RR."

The SPFBIS WG is addressing the issue raised by the Area Director.  I 
don't think that a specification about the SPF protocol is the place 
to get into an exhaustive discussion about DNS issues.

Regards,

---

From: "John Levine" <[email-masked]>
Date: 12 Sep 2013 01:33:13 -0000

In article <[email-masked]> you write:
>do so for the Microsoft Windows platform.

Because it's not true.  MS may have cruddy DNS software, but that was
not and is not the only or the primary issue.  See the previous
million or so messages on this topic for details.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Thu, 12 Sep 2013 11:59:14 +1000

> million or so messages on this topic for details.

Not having a manditory type was a bogus excuse as we needed to go from
TXT only to SPF only.  It was a MIGRATION.  Having TXT only publisher
not "working" with SPF only checkers was NOT broken.  It should
have been a INTENTED result of successful MIGTATION.

The end state of the MIGRATION was SPF only for both publishers and
checkers which would NEVER interoperate with "TXT only" publishers
and checkers.

Once you swallow the bogus arguement that "ALL publishers have to work
with ALL checkers" you can't have a MIGRATION as it becomes logically
impossible to do.

Then it just came down to pragmatics.  Microsoft's lack to support was
a big part of the pragmatics arguement.

Mark

---

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

On Wednesday, September 11, 2013 15:09:37 S Moonesamy wrote:
> >I think all of Pete's suggestions are good.  Should I go ahead and update
> >my local copy of the to be -20?
> 

Done.  rfcdiff of the full post -19 diff attached.  I've applied the changes due 
to Barry's comments as well.

> the work easier if we can get this one out of the way.

Here is the revised section 3.1:

    SPF records MUST be published as a DNS TXT (type 16) Resource Record
    (RR) [RFC1035] only.  The character content of the record is encoded
    as [US-ASCII].  Use of alternative DNS RR types was supported in
-   SPF's experimental phase, but has been discontinued.  See Appendix A
-   of [RFC6686] for further information.
+   SPF's experimental phase, but has been discontinued.

+   In 2003, when SPF was first being developed, the requirements for
+   assignment of a new DNS RR type were considerably more stringent than
+   they are now.  Additionally, support for easy deployment of new DNS
+   RR types was not widely deployed in DNS servers and provisioning
+   systems.  As a result, developers of SPF found it easier and more
+   practical to use the TXT RR type for SPF records.

+   In its review of [RFC4408] the SPFbis working group concluded that
+   its dual RR type transition model was fundamentally flawed since it
+   contained no common RR type that implementers were required to serve
+   and required to check.  Many alternatives were considered to resolve
+   this issue, but ultimately the working group concluded that
+   significant migration to the SPF RR type in the foreseeable future was
+   very unlikely and that the best solution for resolving this
+   interoperability issue was to drop support for the SPF RR type from
+   SPF version 1.  See Appendix A of [RFC6686] for further information.
+
+   The circumstances surrounding SPF's initial deployment a decade ago
+   are unique.  If a future update to SPF were developed that did not
+   reuse existing SPF records, it could use the SPF RR type.  SPF's use
+   of the TXT RR type for structured data should in no way be taken as
+   precedent for future protocol designers.  Further discussion of
+   design considerations when using new DNS RR types can be found in
+   [RFC5507].

I am waiting any changes based on the SECDIR review for some responses to my 
last message on that topic.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Wed, 11 Sep 2013 22:54:54 -0700

Hi Pete,

     In 2003, when SPF was first being developed, the requirements for
     assignment of a new DNS RR type were considerably more stringent than
     they are now.  Additionally, support for easy deployment of new DNS
     RR types was not widely deployed in DNS servers and provisioning
     systems.  As a result, developers of SPF found it easier and more
     practical to use the TXT RR type for SPF records.

     significant migration to the SPF RR type in the foreseeable future was

     The circumstances surrounding SPF's initial deployment a decade ago
     are unique.  If a future update to SPF were developed that did not
     reuse existing SPF records, it could use the SPF RR type.  SPF's use
     of the TXT RR type for structured data should in no way be taken as
     precedent for future protocol designers.  Further discussion of
     design considerations when using new DNS RR types can be found in
     [RFC5507].

Regards,

---

From: S Moonesamy <[email-masked]>
Date: Wed, 11 Sep 2013 23:15:46 -0700

Hi Scott,

Thanks for all the work.  I'll wait for Pete's response.  I suggest 
that we focus on the other parts of the draft as from now.

>to Barry's comments as well.

Ok.

>Here is the revised section 3.1:

Thanks.

>last message on that topic.

I'll send the reply to the SECDIR review.  I'll recommend no change 
for the DKIM issue mentioned in the review.  It should be possible to 
address Issue 1 ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg04135.html 
).  The response to Issues 2 and 3 look okay to me.

There is already text from Barry's DISCUSS (Thanks, Barry) to fix 
Section 4.6.  There was a comment from Pete about the size 
limitations in 3.4.  I'll have to go over the discussion again for that one.

As a note to the working group please let me know if I missed any 
part of the draft that requires a change in response to the IESG Evaluation.

Regards,

---

From: Måns Nilsson <[email-masked]>
Date: Thu, 12 Sep 2013 09:14:04 +0200

> The DISCUSS was as follows:

This text is a much more honest and clear description of the design
mishaps and blunderations that led us into the current situation. I do
not think we need do more to describe the state than so in this document.

Having thus praised the editors for their thorough work, I'd like to state that:

Actions speak louder than words, and since we're all (apparently)
reasonably in agreement about the undesirability of another protocol
"simply using TXT" something heavier than "shame on us, ok for this time,
don't do that again!" is needed.

Thus, I am still opposed to deprecating SPF/99. 

By the way, Carthago should be turned into rubble. 
-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
The FALAFEL SANDWICH lands on my HEAD and I become a VEGETARIAN ...

---

From: Pete Resnick <[email-masked]>
Date: Thu, 12 Sep 2013 10:02:03 -0500

Looks good to me. I'll clear my DISCUSS during or just after the call.

pr