Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14

[Scott Kitterman <[e-mail]>]

On Friday, May 17, 2013 10:54:52 AM Murray S. Kucherawy wrote:
> On Fri, May 17, 2013 at 10:04 AM, Scott Kitterman <[e-mail]>wrote:
> > On Wednesday, May 08, 2013 02:09:24 PM Murray S. Kucherawy wrote:
> > > On Wed, May 8, 2013 at 10:14 AM, Scott Kitterman <[e-mail]>
> > 
> > wrote:
> > > > > The last paragraph makes the claim that domain reputation is likely
> > to be
> > > > > more accurate than IP reputation.  Is it worthwhile to add a
> > sentence or
> > > > > two explaining why this is true?
> > > > 
> > > > I don't think so.  First, it's speculation and I don't think enough of
> > a case
> > > > for it can be made without being too long/distracting.  Second, it's
> > not part
> > > > of the protocol, so it not something we should worry about overmuch.
> > > 
> > > I think a simple, brief addition would do it:
> > > 
> > > This is advantageous because reputation of domain names is likely to
> > >    be more accurate than reputation of host IP addresses since domains
> > > are more likely to be stable over the long term.
> > >  ...or something like that.
> > 
> > I think that would have been fine.  I already took it out.  Do you think I
> > should put it back?
> 
> I do.

OK.  Done.

> > > > Section 2.1:
> > > > > I think someone else already mentioned this, but how does
> > encouraging a
> > > > > second check decrease DNS resource use?
> > > > 
> > > > I did reply to this already.  It's a matter of HELO records generally
> > > > being
> > > > much 'cheaper' than mail from records.
> > > 
> > > As long as the document explains that in a sentence or two, we're good.
> > 
> > Here's what I added:
> > 
> > ... (if a conclusive determination about the message can be made based on
> > a check of "HELO", then the use of DNS resources to process the typically
> > more complex "MAIL FROM" can be avoided).
> 
> I suspect that's better as its own sentence rather than something
> parenthetical, but the text is right.

OK.  Changed.

> > > > > Section 2.3:
> > > > > 
> > > > > The second paragraph is loaded with negatives "no... neither...
> > > > > nor."
> > > > > Suggest: "ADMDs can publish SPF records that authorize no hosts to
> > 
> > use
> > 
> > > > > their DNS domain names in HELO or MAIL FROM commands during SMTP
> > > > 
> > > > sessions."
> > > > 
> > > > I added that, because it's a good point, but it doesn't replace the
> > > > existing
> > > > text which attempts to (without being too pointed about receiver
> > 
> > policy)
> > 
> > > > say
> > > > that if you want receivers to be able to reject mail that didn't come
> > 
> > from
> > 
> > > > authorized hosts, you need a -all record.  Some senders care about
> > > > supporting
> > > > these negative assertions, others don't.
> > > 
> > > My comment wasn't so much to correct the text, but to point out that the
> > > sentence is hard to read with so many negatives.
> > > 
> > > Doesn't the sentence I proposed say the same thing?
> > 
> > Almost.  It loses the nuance that this is only appropriate for hosts that
> > send
> > no mail.  You'd think that'd be obvious, but it's not.
> 
> So:
> 
> ADMDs that wish to declare that no hosts are authorized to use their DNS
> domain names in the HELO or MAIL FROM commands during SMTP sessions can
> publish SPF records that say so.

Based on this, I changed it to:

          ADMDs that wish to declare that no hosts are authorized to use their 
          DNS domain names in the HELO or MAIL FROM commands during SMTP 
          sessions can publish SPF records that say so for domain names that 
          are neither used in the domain part of email addresses nor expected 
          to originate mail.

> > > Section 2.4:
> > > > > Isn't the fourth paragraph implicit in any standards specification?
> > > > > That
> > > > > is, do we really need it?
> > > > 
> > > > I see your point, but I think it should actually stay.  Consistency of
> > > > evaluation across multiple implementations is key to the success of
> > > > the
> > > > protocol.  IIRC, you said during the debate that if you were
> > 
> > implementing
> > 
> > > > SPF,
> > > > you'd ignore the macro requirements.  You're, of course, free to do
> > 
> > that,
> > 
> > > > just
> > > > don't say you implemented SPF.
> > > 
> > > I would agree with all of that except the need to say it in a Proposed
> > > Standard.  Any other opinions?
> > 
> > I didn't here much in the way of opinions on this.  Since it's carried
> > forward
> > from 4408, I'll leave it for now.
> 
> Rats.  Since we're looking for text to slash in response to the bloat
> complaint, this is a prime candidate.
> 
> > > > > Section 2.6.7:
> > > > > 
> > > > > Does "permerror" also result when permanent DNS errors occur?
> > > > 
> > > > Tell me how to figure out when a DNS error is permanent and then
> > > > maybe.
> > > > 
> > > >  Given
> > > > 
> > > > what's described in 4.4 Record Lookup, I think only extended SERVFAIL
> > 
> > (if
> > 
> > > > the
> > > > receiver has implemented the temperror -> permerror promotion option)
> > 
> > can
> > 
> > > > currently get a permerror.
> > > 
> > > RCODEs 1, 3, 4, and 5 all look permanent to me as defined in RFC1035, in
> > > that a retry is unlikely to yield a different result absent an operator
> > > changing some configuration or zone data.  0 is "no error" and 2 is
> > 
> > "server
> > 
> > > failure"; the latter is obviously permanent (but desirable), leaving 2
> > 
> > for
> > 
> > > the case where a timeout or some other transient thing occurred.
> > 
> > This is a good point.
> > 
> > 3 is permanent, but it's not an error.  It's no data.  Currently the draft
> > says anything other than 0 or 3 is a temperror.
> 
> True, NODATA isn't an error, but it is final.
> 
> > 5 could be temporary, I'd think (query refused due to overload maybe?)
> 
>  Overload is supposed to be SERVFAIL, I think.  Andrew?
> 
> I think 5 is used for policy things like "You're not allowed to know that."
> 
> > Looking at
> > http://www.iana.org/assignments/dns-parameters/dns-parameters.xml#dns-para
> > meters-6, I agree that many of these DNS errors could
> > be permanent, but the spec calls for temperror in these cases.
> > 
> > The only temporary errors that turned out to really be permanent that I've
> > seen in the wild are some SERVFAIL (2).
> 
> As in a server that constantly returns SERVFAIL?  I imagine that just like
> in any context, a temporary error that's constantly returned is eventually
> de facto treated as permanent insofar as the client gives up and goes away.
> 
> > If we were starting from scratch, I'd probably classify many of the other
> > rcodes as permanent errors, but we aren't.  Absent some evidence of this
> > causing real world problems, I think we need to leave it the way it is.
> 
> I think this is an error that warrants correction.  It might be interesting
> to know what some implementations have done here, e.g., if implementers
> decided to implement based on RFC1035 rather than RFC4408.

All of the ones I know of make anything not 0 or 3 a temperror.  I agree it's 
wrong, but is it an error that, in operation, causes any problems?  If not, I 
don't think we should fix it.

> > > > > Why 20 seconds for the overall run time?
> > > > 
> > > > This is carried forward from RFC 4408.  It was moved from section 10.1
> > 
> > to
> > 
> > > > 4.6.4 as part of issue #6, but the value is unchanged.  I'm not aware
> > 
> > of
> > 
> > > > any
> > > > issues with what's defined in 4408.
> > > 
> > > I don't have an issue with 20 specifically.  I'm just anticipating the
> > 
> > "Why
> > 
> > > 20?" question from someone else.
> > 
> > Because it's been that way for a long time and seems to work.  IIRC, at
> > the
> > time, it was the shortest time we could get some agreement around.  If it
> > were
> > just me, I'd pick a number closer to 2 than 20.
> 
> I suggest a sentence saying this was chosen arbitrarily, or based on the
> fact that SMTP sessions that take longer than this are quite unusual, or
> something.

The number was extracted from the usual location.

OK, not that.

Is it common to justify design decisions like this in the draft of the text?  
Might this be better for sm's write up than the actual draft?

> > > > > The second-last paragraph is weirdly wrapped.  Is the XML ok there?
> > > > 
> > > > I think I fixed that already based on John Levine's comments.   Please
> > > > double
> > > > check the new draft.
> > > 
> > > Will do when it comes out.
> > > 
> > > > > Section 5.6:
> > > > > 
> > > > > For IPv4, shouldn't the CIDR be 1*2DIGIT?  For IPv6, shouldn't the
> > 
> > CIDR
> > 
> > > > be
> > > > 
> > > > > 1*3DIGIT?
> > > > 
> > > > I don't know.  It's unchanged from RFC 4408 right now, but I'd like
> > 
> > other
> > 
> > > > opinions on changes here (ABNF makes my head hurt).
> > > 
> > > It's probably not harmful to leave it, really.  It's just an observation
> > > that 1*DIGIT allows 000000024 (which is probably fine) but also allows
> > > 1048576 (which probably isn't).  1*2DIGIT would limit it to 00-99 at
> > 
> > least.
> > 
> > > You could also cover this in prose by saying 1*DIGIT and then in either
> > 
> > an
> > 
> > > ABNF comment ("; blahblah") or in text nearby say that it has to
> > > evaluate
> > > to an integer from 0 to 32 for v4 and 0 to 128 for v6.
> > 
> > Maybe import the definitions in
> > http://www.ietf.org/rfc/rfc3986.txtinstead?
> 
> I looked through the collected grammar in there and didn't see anything
> that covered CIDR expressions.  Now that my eyes have un-crossed, did you
> have specific one(s) there in mind?

I was looking at 3.2.2, which (you are correct) defines IPv4/IPv6, but not CIDR 
(I lost track of which one we were discussing), sorry.

Unfortunately RFC 4632 doesn't have an ABNF.

> > >    macro-letter     =  %x73 / %x6c / ...
> > 
> > We resolved this already, right?
> 
> Yes, disregard.
> 
> > > > The "SPF verifiers MUST make sure..." doesn't seem actionable to me.
> >  
> >  Do
> >  
> > > > we
> > > > 
> > > > > really expect Received-SPF generators to be able to identify and
> > 
> > exclude
> > 
> > > > > malicious data?
> > > > 
> > > > I think you have to.  I've seen people put html pointing to malicious
> > 
> > web
> > 
> > > > sites in SPF records.  Thanks to someone privately pointing this class
> > 
> > of
> > 
> > > > attack out to me, my SPF validator now properly escapes anything
> > > > that's
> > > > retrieved from DNS.
> > > 
> > > It's the "malicious data" part that concerns me because what constitutes
> > 
> > an
> > 
> > > effective data attack is very context-sensitive.
> > 
> > Do you still think it needs a change?
> 
> Yes, but it's not a hill on which I plan to die.  I'd love to hear what
> others think though.

OK.  I'll keep waiting.

Scott K