Subject: [spfbis] Section 3 of draft-ietf-spfbis-4408bis-06

From: S Moonesamy <[email-masked]>
Date: Fri, 31 Aug 2012 18:03:47 -0700

Hello,

I am commenting on Section 3 of 
draft-ietf-spfbis-4408bis-06.  Section 3 is about SPF records.

   'An SPF record is a DNS TXT (type 16) Resource Record (RR) that
    declares which hosts are, and are not, authorized to use a domain
    name for the "HELO" and "MAIL FROM" identities.'

According to RFC 4408:

   'This document defines a protocol by which domain owners may authorize
    hosts to use their domain name in the "MAIL FROM" or "HELO" identity.'

The protocol is described about hosts authorized to use the domain 
name instead of who is authorized and who isn't.  Note that the text 
I am commenting about is similar to what is in RFC 4408.  I suggest 
keeping the SPF record definition similar to what is used for the 
protocol instead of getting into who is authorized and who isn't.

   "Loosely, the record partitions all hosts into permitted and
    not-permitted sets (though some hosts might fall into
    neither category)."

I suggest remove that to "tighten" the specification.

   'The SPF record is a single string of text.  An example record is the
    following:

       v=spf1 +mx a:colo.example.com/28 -all'

There isn't any information about the record "format" in that subsection.

   "Each SPF record is placed in the DNS tree at the host name it
    pertains to, not a subdomain under it, such as is done with SRV
    records [RFC2782]."

This is tutorial material.

   'The example in Section 3 might be published via these lines in a
    domain zone file:

       example.com.          TXT "v=spf1 +mx a:colo.example.com/28 -all"
       smtp-out.example.com. TXT "v=spf1 a -all"'

As the "format" as not been defined the above comes out as tutorial material.

   "They might cause problems with size limits (see Section 3.4)
    and care MUST be taken to ensure only SPF records are used
    for SPF processing."

There is a new RFC 2119 requirement compared to RFC 4408.

   'ADMDs publishing SPF records SHOULD try to keep the number of
    "include" mechanisms and chained "redirect" modifiers to a minimum.
    ADMDs SHOULD also try to minimize the amount of other DNS information
    needed to evaluate a record.'

Two new RFC 2119 recommendations have been added.

In Section 3.1:

   "SPF records MUST be published as type TXT [RFC1035]"

There is a previous definition for SPF records which already mentions 
that it is a DNS TXT (type 16) Resource Record (RR).  It is not clear 
what the MUST is for.

   'Use of alternate DNS RR types was supported in SPF's experimental
    phase, but has been discontinued.'

I suggest mentioning the SPF RR is considered as deprecated.

In Section 3.4:

   'Note that when computing the sizes for queries of the TXT format,
    one MUST take into account any other TXT records published at
    the domain name.'

This is a new RFC 2119 requirement.

In Section 3.5:

   "Use of wildcard records for publishing is NOT RECOMMENDED."

This is a new RFC 2119 recommendation.

   "SPF records MUST be listed twice for every name within the zone:"

This is a new RFC 2119 requirement.

There seems to be an assumption that DNS is secure.  I suggest adding 
text about DNS Security in the Security Considerations section.

Regards,
S. Moonesamy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 31 Aug 2012 18:20:01 -0700

> I suggest remove that to "tighten" the specification.

How is that an improvement?

> There isn't any information about the record "format" in that subsection.

A forward reference to the formal specification would be adequate.

> This is tutorial material.

I disagree.  It's implementation.

> As the "format" as not been defined the above comes out as tutorial

Two things:

1) The forward reference I suggested above solves it.

2) "The example in Section 3" inside Section 3 is weird.  How about
"The example above?"

> There is a new RFC 2119 requirement compared to RFC 4408.

The issue is use of "must" vs. "MUST".  I believe this is appropriate
clarification (this, or replace MUST with some non-2119 word).

> Two new RFC 2119 recommendations have been added.

Same argument.

> There is a previous definition for SPF records which already mentions that
> it is a DNS TXT (type 16) Resource Record (RR).  It is not clear what the
> MUST is for.

Same argument.  Could change "MUST be" to "are" though.

> I suggest mentioning the SPF RR is considered as deprecated.

Agree, and refer to the experiment document for more detail.

> This is a new RFC 2119 requirement.

Same issue, I believe.  I'll skip further things along those lines.

> There seems to be an assumption that DNS is secure.  I suggest adding text
> about DNS Security in the Security Considerations section.

I'd suggest we get guidance from Andrew or our AD about that.  Seems
like we might need to do that for everything that uses the DNS in any
way, which could get tedious, unless we can rely on the fact that
RFC1034/5 are already marked as updated by the DNSSEC drafts.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Fri, 31 Aug 2012 18:33:17 -0700

>How is that an improvement?

The WG Chairs might say that it is not a clarification. :-)

>A forward reference to the formal specification would be adequate.

Yes.

>I disagree.  It's implementation.

Noted.

>1) The forward reference I suggested above solves it.

Ok.

>2) "The example in Section 3" inside Section 3 is weird.  How about

I'll leave it to WG participants to provide feedback.

>clarification (this, or replace MUST with some non-2119 word).

One "MUST" could be used (re: your comment about the SPF RR).

>like we might need to do that for everything that uses the DNS in any

That's the trend nowadays.

>RFC1034/5 are already marked as updated by the DNSSEC drafts.

I don't think so ( http://www.rfc-editor.org/rfc/rfc1035.txt ).  One 
or two lines about DNSSEC with the appropriate reference would be 
enough.  I'll leave it to Andrew to suggest text.

Regards,
S. Moonesamy

P.S. Thanks for the feedback on the two sections.

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 01 Sep 2012 01:17:32 -0400

> How is that an improvement?

Considering we specifically discussed this text and the working group seemed to 
feel it helped clarify things, I'm disinclined to remove it.

> A forward reference to the formal specification would be adequate.

I don't think this is particularly needed, but added anyway.  It's not like 
this is a single pass compiler where implicit forward references cause 
failures.

> I disagree.  It's implementation.

Absolutely.  There is no interoperation without knowing where records should 
be published/looked up.

> 2) "The example in Section 3" inside Section 3 is weird.  How about

Fixed.

> clarification (this, or replace MUST with some non-2119 word).

This was not an accidental change that I'll revert when I go through and 
double check 2119 changes.  It was converted to a MUST based on expressed 
concern in the working group that non-2119 language was incorrect because this 
is an actual protocol requirement.

> > Two new RFC 2119 recommendations have been added.

These are also not accidental.  These changes are based on post-4408 
deployment experience and are strongly recommended best practices (following 
them avoids interoperation problems).  They are also meant to be part of the 
answer to Issue #24.

> Same argument.  Could change "MUST be" to "are" though.

I changed the language to only mention the specific RR type in one place.  This 
particular section has had a lot of changes, since this is where the no longer 
used Type SPF RR type was defined here.  The operative part of RFC 4408 
relative to this text was:

>    An SPF-compliant domain name SHOULD have SPF records of both RR
>    types.  A compliant domain name MUST have a record of at least one
>    type.

Since we only have one type saying a domain MUST have a record of that type is 
completely consistent with the 2119 requirements in 4408.  In any case I don't 
understand what the objection is, since it's perfectly correct that if you 
don't publish an SPF record as a TXT record you aren't doing SPF.

> Agree, and refer to the experiment document for more detail.

Except it's not.  Please actually read our definition of deprecated.  We didn't 
deprecate type SPF, we removed it.

> Same issue, I believe.  I'll skip further things along those lines.

You do have to do it or you'll publish records that are too big and get 
interoperation failures.  This one seems appropriate to me as well.

> RFC1034/5 are already marked as updated by the DNSSEC drafts.

Sigh.  Did anyone look at the existing security considerations before 
commenting.  Section 10.3 covers this exact issue.  If it's inadequate, please 
provide text, but please check if your comments are already addressed before 
making new ones.

Scott K