[spfbis] IETF83 SPFBIS minutes - Version 0.1

[S Moonesamy <[e-mail]>]

The SPFBIS WG held a meeting at IETF83.  This is Version 0.1 of the 
minutes.  Please email me if there are any changes.

SPF Update Working Group Minutes

Meeting : IETF83, Friday 30 March, 2012
Location: Paris, 09:00 to 11:00
Chairs  : Andrew Sullivan <[e-mail]>
Minutes : John Levine
	     Version 0.1

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 scribe 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, bashed the agenda.

B. RFC 4408 issues

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

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 #18 is about adding a SMTP code.  It is not clear whether it is 
within the charter.

The Chair mentioned that SERVFAIL is not an error in DNS.

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 thyat it should go away but it should be deprecated for 
servers and not for clients.  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 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 to 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 whetehr 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 wasn'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 a previous comment he made 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 #16 is about the PTR mechanism.  There was support on the 
mailing list for adding "SHOULD NOT" text about this.  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

The Chair mentioned that he does not think the 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.

Hector Santos commented that a deployment document may be outside the 
scope of the working group.  Dave Crocker suggested writing the text 
and 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.  They 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 path by 
assuming that all mail is delievred 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 experiment.
http://www.ietf.org/proceedings/83/slides/slides-83-spfbis-0.ppt

He will shortly have extensive data on published SPF 
records.  Several people commented on other material that might be 
reported, e.g., how often to checks succeed or fail, and how well do 
SPF and Sender-ID describe legitimate mail flows.  He will add some 
text.  The Chair noted that people who want this to move ahead need 
to help finish the experiment report.  There was a comment to add 
some methodology.

[This part is not extensive due to an audio cut]

H. Any Other Business

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

Regards,
S. Moonesamy