Subject: Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 2 Sep 2013 08:54:32 -0400

On Thu, Aug 29, 2013 at 12:30 PM, Dan Schlitt <[email-masked]> wrote:

> As the manager of a modestly large network I found the TXT record as a
> useful tool in management of the network. Such a use was even suggested by
> other system managers. That was a time when the Internet was a friendlier
> place. Today I might do things differently and not make some of the TXT
> records visible on the public Internet. But they would still be useful for
> internal management.
>

TXT records can be useful for ad-hoc local configs and the SPF use has made
this harder. But it is hard to see how the SPF record makes that situation
any better.

Probably a better solution would be to take a chunk of the reserved RR code
space and stipulate that these have TXT form records so folk have 10,16 or
so records for this use.

In the longer term, the problem with the SPF RR is that it is a point
solution to 'fix' only one protocol. It is an MX record equivalent. Which
was OK given the circumstances when it was developed.

A shift from TXT to SPF records is not likely to happen for the niche SPF
spec. But may well be practical for a wider client/initiator policy spec.

We are not going to get rid of the defective US style Edison screw
lightbulb socket either, certainly not for incandescents even though the
Swan bayonet design is clearly superior, less risk of damage to the bulb,
safer and does not come undone. But that Edison screw style will eventually
disappear as installation switches to low voltage (12V) DC distribution etc.

The engineering solution to this deployment problem is to generalize the
problem and use a new record for that.

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

---

From: "John Levine" <[email-masked]>
Date: 2 Sep 2013 13:47:03 -0000

>problem and use a new record for that.

Either that or figure out how to make it easy enough to deploy new
RRTYPEs that people are willing to do so.

The type number is 16 bits, after all.  We're not in any danger of running out.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: David Conrad <[email-masked]>
Date: Mon, 2 Sep 2013 06:56:51 -0700

John,

> The type number is 16 bits, after all.  We're not in any danger of running out.

We have been told on numerous occasions that one of the primary reasons for continued use of TXT is because middleboxes, etc., do not allow new RR types (something deprecation of the SPF RR would seem to only encourage). The number of bits in the type field would not seem to be particularly relevant to this.

Regards,
-drc

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 2 Sep 2013 11:49:13 -0400

On Mon, Sep 2, 2013 at 9:56 AM, David Conrad <[email-masked]> wrote:

> We have been told on numerous occasions that one of the primary reasons
> for continued use of TXT is because middleboxes, etc., do not allow new RR
> types (something deprecation of the SPF RR would seem to only encourage).
> The number of bits in the type field would not seem to be particularly
> relevant to this.
>
> Regards,
> -drc
>

Which is a problem that I think can only be solved if there is a general
solution of the policy distribution problem and an expectation that at
least new middle boxen will support it.

I have been pushing for some sort of 'Internet 2.0' branding for equipment
that meets a comprehensive set of nextgen needs, i.e. IPv6, port
forwarding, DNSSEC, border policy enforcement for that very reason.

But it has to be a two way street. The reason DNS Choices fell flat is that
it just told people what not to do to solve their problems, it did not
provide a proposal that actually solved their problems.

---

From: S Moonesamy <[email-masked]>
Date: Tue, 03 Sep 2013 14:56:14 -0700

Hello,

This is a rough summary of the comments which 
have been made on the Last Call for 
draft-ietf-spfbis-4408bis-19 since I emailed Pete Resnick [1].

There were comments about the RFC 5507 concerns 
from Patrik Fältström [2], Dave Crocker [3], Mark 
Andrews [4] and John Klensin [5].

There were comments from Dan Schlitt [6] in which 
he provided his perspective of the SPFBIS 
discussions.  In his opinion "it is unwise to 
have a standards track protocol which overloads 
the TXT record".  He suggested that the 
specification should be published as 
Informational.  The comments provided by Dave 
Crocker [3] [7] and John Klensin [5][8] may also 
be related to the intended status of the 
specification.  Phillip Hallam-Baker commented about the design objections [9].

I'll ask the Responsible Area Director for 
guidance about the above instead of suggesting that the SPFBIS WG address them.

Joe Abley commented about the usage of "messages 
sent over UDP" [10].  This issue has been raised 
by Douglas Otis.  My suggestion to the SPFBIS WG is to address this issue.

Please email me if you consider your comments as 
not having been addressed correctly.  I suggest 
waiting for Pete Resnicks to send a message to 
the mailing list if you sent Last Call comments before August 24.

Regards,
S. Moonesamy (as document shepherd)

1. http://www.ietf.org/mail-archive/web/ietf/current/msg81877.html
2. http://www.ietf.org/mail-archive/web/ietf/current/msg81887.html
3. http://www.ietf.org/mail-archive/web/ietf/current/msg81889.html
4. http://www.ietf.org/mail-archive/web/ietf/current/msg81891.html
5. http://www.ietf.org/mail-archive/web/ietf/current/msg81912.html
6. http://www.ietf.org/mail-archive/web/ietf/current/msg81939.html
7. http://www.ietf.org/mail-archive/web/ietf/current/msg81923.html
8. http://www.ietf.org/mail-archive/web/ietf/current/msg81924.html
9. http://www.ietf.org/mail-archive/web/ietf/current/msg81927.html
10. http://www.ietf.org/mail-archive/web/ietf/current/msg81862.html

---

From: Douglas Otis <[email-masked]>
Date: Tue, 10 Sep 2013 14:45:46 -0700

On Sep 2, 2013, at 5:54 AM, Phillip Hallam-Baker <[email-masked]> wrote:

> As the manager of a modestly large network I found the TXT record as a useful tool in management of the network. Such a use was even suggested by other system managers. That was a time when the Internet was a friendlier place. Today I might do things differently and not make some of the TXT records visible on the public Internet. But they would still be useful for internal management.
> 
> TXT records can be useful for ad-hoc local configs and the SPF use has made this harder. But it is hard to see how the SPF record makes that situation any better.
> 
> 
> Probably a better solution would be to take a chunk of the reserved RR code space and stipulate that these have TXT form records so folk have 10,16 or so records for this use.
> 
> In the longer term, the problem with the SPF RR is that it is a point solution to 'fix' only one protocol. It is an MX record equivalent. Which was OK given the circumstances when it was developed.
> 
> 
> A shift from TXT to SPF records is not likely to happen for the niche SPF spec. But may well be practical for a wider client/initiator policy spec.

Dear Phillip,

It seems many of the larger providers are unwilling to process SPF macros due to inherent risks and inefficiency.  Rather than accessing data using the DNS resource selectors of Name, Type, and Class, SPF uses mechanisms above DNS to utilize an additional domain, IP address, and email address input parameters merged with results generated from a series of proscribed DNS transactions.  The macro feature was envisioned as leveraging these additional inputs to influence query construction. It seems lack of support by large providers has ensured scant few macros are published.

in the beginning, there were several wanting a macro language to  managing DNS processing with little idea where this would be headed.  At the time there was already a dedicated binary resource record able to fully satisfied the information now obtained and used from SPF.  Policy aspects of SPF are largely ignored due to exceptions often required.   An SRV resource record resolving the location of a service could include an APL RR with CIDR information of all outbound IP addresses.  This would offer load balancing and system priorities, while mapping outbound address space within two DNS transactions instead of the 111 recursive transactions expected by SPF.  If one were starting over, DANE TLS or DTLS is a better solution that should be even easier to administer since it avoids a need to trust IP addresses and NATs.   As with PKI, there are too many actors influencing routing's integrity.

Regards,
Douglas Otis