Subject: [spfbis] IETF83 SPFBIS minutes - Version 0.2

From: S Moonesamy <[email-masked]>
Date: Tue, 24 Apr 2012 10:01:07 -0700

The SPFBIS WG held a meeting at IETF83.  This is Version 0.2 of the 
minutes.  Please email me any suggested changes to me.

SPF Update Working Group (SPFBIS) Minutes

Meeting : IETF83, Friday 30 March, 2012
Location: Room 252A, Paris, 09:00 to 11:00
Chairs  : Andrew Sullivan <[email-masked]>
Minutes : John Levine
	     Version 0.2

Audio: http://www.ietf.org/audio/ietf83/ietf83-252a-20120330-0855-am.mp3

AGENDA

  A. Meeting Administrivia
     Note well
     Agenda bashing
  B. RFC 4408 issues
  C. SPF RR Type and TXT RR (issue #9)
  D. DNS amplification attacks
  E. Is a deployment document needed
  F. Path authorization/updating SMTP
  G. Adoption of
       draft-kucherawy-spfbis-experiment-03
       describing the SPF/Sender-ID experiment
       and discussion
  H. Any Other Business

A. Meeting Administrivia

Andrew Sullivan chaired the IETF83 SPFBIS Working Group meeting in 
Paris, France.  John Levine was the minute-taker and Murray S. 
Kucherawy and Tony Hansen were the Jabber scribes.  There were 20 
people in the room.

The Chair brought the Note Well to the attention of the meeting 
participants, asked them to sign the blue sheets and bashed the agenda.

Slides: http://www.ietf.org/proceedings/83/slides/slides-83-spfbis-1.pptx

B. RFC 4408 issues

RFC 4408 issues are listed at http://trac.tools.ietf.org/wg/spfbis/trac/report/

Issue #5 is about some ambiguities in the specification.

Issue #7, #8 and #16 are there to be tracked. The working group will 
work on text once it has adopted a draft.  Issue #15 is about MAIL 
FROM.  Some of the issues have not been opened for discussion on the list yet.

Issue #17 is about uric.  There hasn't been any discussion.  Some of 
the issues in the tracker have not been opened for discussion yet as 
the Chairs have been trying to go through a few issues at a time.

Issue #18 is about adding a SMTP reply code for permanent error.  It 
is not clear whether it is within the charter.

Issue #22 is about how to handle invalid domain.  This is linked to 
discussions about various cases having to do with DNS.

The Chair mentioned that SERVFAIL is not an error in DNS and he has 
updated the ticket to say how it will be handled.  Scott Kitterman 
asked via Jabber how can we know whether we are done if there is no 
text to agree on.  The Chair explained that the basic idea is that 
once substantive discussion is done, what needs to be done is to 
agree on text.  Arguing on the details of the text is easier once the 
working group agrees on what it wants to say.

The Chair mentioned that errata have to be addressed in a bis 
document and that it is straight-forward.

Issue #4 was ruled as out of scope.  There wasn't any objection.

The Chair asked the floor for opinions about Issue #10 which is about 
replacing the Received-SPF: header.  Scott Kitterman commented that 
it cannot be deprecated as there are still people using them.  Tony 
Hansen explained that deprecation means not to use it in future 
implementations as it will go away at some point, it does not mean 
that it is no longer supported in the specification.  There were two 
people in the Jabber room in favor of deprecating and using the 
Authentication-Results: header.  Doug Otis commented on having the IP 
address in Authentication-Results: like Received-SPF: does.

The Chair called for a hum for:

  (i)  Received-SPF is deprecated

  (ii) Not to do anything about Received-SPF:

The hum favored deprecation.  As somebody was not in favor of 
deprecation, the Chair asked for the person to explain 
why.  Alessandro Vesely considered that deprecation is the wrong 
word.  The Chair clarified that if people believe that the header is 
useful,it should stay, otherwise, it should go away.  Alessandro 
Vesely stated servers should deprecate Received-SPF, so that their 
clients stop checking it and check Authentication-Results instead, 
i.e. 4408bis can recommend that servers deprecate the old field while 
they add the new.  Scott Kitterman mentioned that things can be 
deprecated for a long time before they actually get removed; the 
working group could state a preference.  S. Moonesamy, as an 
individual, commented that deprecation can be done by clients not 
sending it but receivers supporting it, meaning that things will 
continue parsing the header for some time.

The Chair pointed out that there were three possibilities on the table:

  (i)   Servers complain but clients continue to use it

  (ii)  Clients keep sending it but servers do not say anything when 
they get one

  (iii) We just deprecate it and maybe people get warnings

Pete Resnick, as Area Director, asked for comments about the 
interoperability problem if people continued to use Received-SPF; 
i.e. what the problem with keeping it around is.  He asked that if 
there wasn't a problem with generating them, what's the use of 
deprecating them.  The idea was about long-term simplification.  John 
Levine mentioned that if you were allowed to generate both headers, 
they could disagree.

The Chair suggested that someone send their best arguments to the 
mailing list for deprecating and someone else sends arguments for 
deprecating.  The Chair also suggested that Doug Otis makes the 
argument for "do not deprecate, leave it alone" on the mailing list 
and Doug Otis agreed.

Murray Kucherawy commented on Issue #11 saying that check_host() 
looks awfully lot like an API whereas the IETF does not define 
APIs.  Pete Resnick, as Area Director, preferred to see the 
specification be written in terms of semantics of the protocol 
elements rather than processing.  Murray Kucherawy volunteered to 
write a paragraph to mention that it is merely an illustration.

The discussion on the mailing list about Issue #13 was 
inconclusive.  The Chair asked whether Best-Guess SPF was in scope at 
all and if so what does the working group want to say about it, with 
the default being not to say anything.  Scott Kitterman pointed out 
that it was not left out of RFC 4408 by accident.  Murray Kucherawy 
argued that as there are places such as gmail.com which makes use of 
this, it would help to have some clarifying text about it.

Murray Kucherawy asked whether the IESG has an opinion about "widely 
deployed" or whether it only wants to see whether the working group 
did its homework.  The Chair commented that "widely deployed" can be 
done on a case by case basis and based on the Conclusions that the 
working group draws.  There weren't any objections.

The Chair commented that he did not completely understand what the 
issue was with Issue #14.  Nobody argued that the working group must 
deprecate local-part macros.  The Chair closed the issue with "won't 
fix".  The Chair will reconsider the issue if there is text to go in 
the Security considerations section of the document.  John Levine 
pointed out that as there is only one person in favor of the 
argument, it should be closed.  The Chair stated that if there is a 
legitimate argument, it should go into the Security Considerations 
section.  John Levine revised his previous comment by pointing out 
that there are a vast number other of ways to generate an 
attack.  The Chair pointed out that SPF sucks does not belong in the 
document.

Pete Resnick, as Area Director, explained what he understood from the 
discussion of Issue #14: the working group sufficiently considered 
the issue and agreed not to deprecate the feature; it can add 
clarification in the Security Considerations section.  The Chair 
stated that the issue will be closed with "won't fix" and a new issue 
can be added saying that the working group will add text in the 
Security Considerations section.

Alessandro Vesely asked a clarifying question about whether a domain 
using local-part macros is badly administered.  Scott Kitterman 
objected to adding text about this issue in the Security 
Considerations section.  Pete Resnick, as Area Director, mentioned 
that he can object to the new issue and provide reasons for why the 
text should not be added.  Eliot Lear pointed out that the discussion 
was about two sentences which were non-normative where the risk does 
not even have to be characterized.

The Chair asked whether anyone would like to argue about Issue #16, 
in favor of relaxing the syntax checking.  As there were no 
arguments, the issue was closed with "won't fix".

Issue #27 is about the PTR mechanism and %{p} macro.  There was 
support on the mailing list for adding "SHOULD NOT" text about 
this.  There was support for "SHOULD NOT" from the Jabber room.  The 
issue was closed pending the new document.

C. SPF RR Type and TXT RR (issue #9)

The were people on the mailing list in favor of using the TXT RR 
appeared to be a modest majority and there were people who argued for 
SPF RR Type on the grounds of DNS hygiene.  The Chair explained that 
it appears as an empirical matter, overwhelmingly, the TXT RR is used 
but RRTYPE 99 does not qualify under the unused provision of the 
SPFBIS charter.  Dave Crocker mentioned that we have not had 
consensus about the definition of "unused" and pointed about that the 
definition is hugely required in this case.  Dave Crocker agreed with 
the Chair that there was little adoption of RRTYPE 99 and mentioned 
that functionally, after this many years, it is serving as cruft, it 
is redundant and offers no benefit after this long.  He suggested 
this also as one definition of "unused".

Tony Hansen asked whether any sites publishing RRTYPE 99 were found 
in the surveys done.  Murray Kucherawy pointed out that if this was 
the case, the position stated by Dave Crocker would be false.  The 
Chair reminded the working group about a comment from Scott Kitterman 
stating that if people were publishing RRTYPE 99 only, it is an 
indication of them not knowing what they were doing anyway.  Peter 
Koch suggested changing some of the experimental components into 
production if the experiment was successful.  It pointed out the 
working group does not own the TXT RR or the zone apex and it should 
probably keep that in mind.  He reminded the working group that there 
has been this humongous argument about deployed base within the 
IETF.  He considered it ill-advised to make decisions which may have 
long term consequences based on the results of the experiment 
only.  The Chair mentioned that the evidence suggests that SPF is 
widely deployed, likely more widely deplyed than IPv6.  Scott 
Kitterman mentioned that there was an interoperability issue which 
would have to be clarified.

Pete Resnick, as Area Director, in response to Peter Koch's comments, 
mentioned that in the deal with the IESG, as a general statement, the 
working can removed what is unused and put in what is widely 
deployed.  He pointed out that saying that TXT RR is part of an 
experiment is contrary to the agreement made with the IESG.  His 
opinion is that either way, the proposal is stuck with TXT RR and 
that it is not an issue.  The only issue is whether the proposal can 
remove the SPF RRTYPE as unused.

Eliot Lear did not see the point of keeping the SPF RRTPE given the 
results of the survey.  He mentioned that he did not hear a 
compelling technical argument for keeping the RRTYPE.  Murray 
Kucherawy suggested adding an appendix to the conclusion document 
about the experience in developing the RRTYPE given recent 
discussions on other IETF mailing lists. He proposed that it would be 
better if it was done as an IESG statement.  Pete Resnick, as Area 
Director, did not think that an IESG statement is appropriate.

The conclusion reached by the Chair was that the document will say 
SHOULD NOT publish RRTYPE 99 and MUST NOT query RRTYPE 99.

In the experiment result document that 166 out of 251,000 domains 
surveyed published only RRTYPE 99.  On a procedural point, the Area 
Director stated that he would like the working group to document that 
fact.  The IESG consider that fact should it come up in an appeal.

Tony Hansen commented that when you write a protocol, there is 
definite harm if there is a choice in what you publish and what you 
look for.  He is of the view that there is a definite bug in RFC 4408.

D. DNS amplification attacks

The Chair proposed that the working group asks the DNS Directorate 
whether there is a serious issue (#24) here because there has been 
previous analysis of this issue.  Peter Koch stated as a member of 
the DNS Directorate his preference for the question to be more open 
or more to the point.  He would like a little less ambiguity in the 
question; adding that a straight yes or no answer should not be 
expected.  The Chair commented that he was not expecting a straight 
answer; he would never expect a straight yes or no answer from 
anybody with any question having to do with DNS.

E. Is a deployment document needed

Hector Santos via Jabber raised a concern is that this "Informative" 
RFC can be used to alter the scope of the WG even though it may be 
out of scope.  The Chair mentioned that he does not think the charter 
allows for a deployment document.

The Chair asked for a three-way hum:

  1. Don't do anything at all and let someone else produce deployment guide

  2. Add some deployment notes as an appendix in the bis document

  3. Separate document

There was a little bit for 1, a tiny noise for 2 and a medium noise for 3.

Dave Crocker suggested writing the text and then figuring out where 
it should go and the Chair agreed.

F. Path authorization/updating SMTP

The Chair explained that this is mainly about mail forwarding (Issue 
#12) and that the discussion on the mailing list was completely 
inconclusive.  Alessandro Vesely commented on the important of having 
forwarding procedures devised.  A workaround was presented, including 
an obligation for forwarders to publish a host policy-record.  The 
Chair commented that "forwarder must publish" + "helo-pass prevents 
rejection" was slightly different than the solution originally 
proposed.  The Chair asked whether that was protocol advice or 
deployment advice.  Alessandro Vesely pointed out that the 
specification is not in accordance with the SMTP specification which 
mentions that one can forward while keeping the Return-path 
unaltered.  John Levine commented that SMTP is designed to deliver 
mail over whichever path is supposed to work and it can be argued 
that SPF is broken by design; SPF takes the practical fact assuming 
that most mail is delivered over a predictable path.  The Chair 
stated that this issue is deployment advice.  Alessandro Vesely did 
not object to the statement.

G. Adoption of draft-kucherawy-spfbis-experiment-03

draft-kucherawy-spfbis-experiment-03 was adopted as a working group 
I-D.  Due to a technical glitch in the datatracker, the filename of 
the draft could not be changed.  The Chair pointed out that there has 
not been any alternative proposal.

Murray Kucherawy gave a presentation of the document describing the 
SPF/Sender-ID experiments.

Slides: http://www.ietf.org/proceedings/83/slides/slides-83-spfbis-0.ppt

He mentioned that there wasn't any specific guidance on how the 
experiments should be concluded.  He tried to follow the steps of an 
interoperability report to produce the document.  The conclusions 
will be based on the collected data.  He will shortly have extensive 
data on published SPF records.

Tony Hansen asked whether the data is enough to produce a 
satisfactory report.  Murray Kucherawy mentioned that as the working 
group does not have specific guidance from the IESG, it only has to 
show that it has done its homework.  The data provided by Hotmail 
will be the missing piece.

The Chairs pointed out that they are in a hurry and they would like 
to get this deliverable winded up so that the working group can work 
on the 4408bis specification.  It would be premature to start work on 
the 4408bis specification if there isn't significant work to draw the 
conclusions as this is a necessary condition to proceed with work on 
the modified specification.

Dave Crocker suggested that the working group focus on the questions 
to answer for the IESG or any reasonable analyst.  Someone suggested 
that the document requires some methodology section.  Doug Otis 
mentioned getting some data about local-part macros.  Hector Santos 
mentioned that more public information data is needed than just ESP 
domains.  The Chair pointed out that these are requests for data sets 
and asked whether the people asking the questions are volunteering to 
collect the data.

Murray Kucherawy commented that it would not be possible to get 
information about local-part from the survey he has done.  He added 
that it was not possible to know how many implementations out there 
check for the RRTYPE.  Doug Otis suggested using postmaster for 
local-part macro tests.  The Chair suggested that if Doug Otis has 
access to a busy mail site and if he can share the data, it would be 
interesting for the working group; if he does not, the request cannot 
be satisfied as the working group does not have access to a data 
source which may provide the information.

The Chair asked whether it is reasonable to expect this work to be 
completed before the next IETF meeting.  He mentioned that given the 
charter, there is no reason the working group cannot be finished with 
its deliverables by the Fall.

H. Any Other Business

The Chair stated that no other business came up and reminded the 
working group to sign the blue sheet.

The meeting was adjourned at 10:46 a.m.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Thu, 26 Apr 2012 14:15:16 -0700

Hello,

I'll consider Version 0.2 of the IETF83 SPFBIS minutes as final as 
there hasn't been any further comments about it.  I'll be submitting 
for the proceedings tomorrow.

Thanks to Douglas Otis for following up on a request made during the 
last meeting ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg01466.html 
).  If anyone would like to send the best arguments for deprecating, 
please post them to this mailing list.  There isn't any rush as the 
working group is currently working on draft-ietf-spfbis-experiment.

Regards,
S. Moonesamy
SPFBIS WG co-chair