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

[Scott Kitterman <[e-mail]>]

On Friday, August 31, 2012 06:20:01 PM Murray S. Kucherawy wrote:
> On Fri, Aug 31, 2012 at 6:03 PM, S Moonesamy <[e-mail]> wrote:
> >   "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.
> 
> 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.

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

> >   "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.
> 
> I disagree.  It's implementation.

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

> >   '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.
> 
> 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?"

Fixed.

> >   "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.
> 
> The issue is use of "must" vs. "MUST".  I believe this is appropriate
> 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.

> >   '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.
> 
> Same argument.

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.

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

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

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

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

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