Olaf Kolkman | 1 Jan 08:35 2005
Picon
Picon

DNSEXT list policy


- List Purpose

  namedroppers <at> ops.ietf.org is the mailing list for the IETF DNSEXT
  working group.  

  See <http://www.ietf.org/html.charters/dnsext-charter.html> for the
  wg charter.  Messages should be on topics appropriate to the dnsext
  wg, which are various discussion of the DNS protocols or
  administrivia of the WG itself.

- Specific items that are not not appropriate for posting

  Calls for papers, announcements of events not directly relevant to
  the DNS protocols, etc. are not appropriate.  

  Discussion of problems with particular implementations,
  announcements of releases, sites' misconfigurations, pleas for help
  with specific implementations, etc.  should be done on mailing lists
  for the particular implementations.

  There is a working group for dns operational practice, DNSOP, whose
  charter can be found at
  <http://www.ietf.org/html.charters/dnsop-charter.html>. Items
  relevant to the DNSOP charter are to be discussed on the DNSOP
  mailinglist.

  Discussion about the quality of implementations is outside the scope
  of this list.

(Continue reading)

Simon Josefsson | 3 Jan 01:57 2005

Re: RFC 2538bis

Dear All:

Since publishing rfc2538bis-00, I have received a number of comments,
mostly from the PKIX and OpenPGP working groups.  The suggestions have
been incorporated, or left as open issues (discussed below).

I have submitted the -01 draft to the IETF.  It can also be found at:

http://josefsson.org/rfc2538bis/draft-josefsson-rfc2538bis.txt

Thanks to rfcdiff, you may review the changes in that document
compared to RFC 2538:

http://josefsson.org/rfc2538bis/draft-josefsson-rfc2538bis-from-rfc2538xml.diff.html

A complete resource with XML, HTML, and TXT versions, and the two
input documents that motivated this work, can be found at:

http://josefsson.org/rfc2538bis/

The major addition in -01 compared to -00 are the new paragraphs in
section 3 that introduce the terms "content-based owner name" and
"purpose-based owner name".  The intention is to motivate the new
owner name guidelines.  As you might recall, for my needs, the RFC
2538 guidelines were not possible to use.  This was the motivation for
2538bis in the first place.

New since -00 is also the purpose-based owner name guideline for
X.509. However, this has been discussed earlier in:

(Continue reading)

wayne | 4 Jan 03:41 2005
Picon

SPF I-D for review: draft-schlitt-spf-classic-00.txt

[ Moderators note: This post needed manual approval.

   Either it was posted by a non-subscribed address, or the posting
   was too large ( > 20000bytes ) for this list.

   With the massive amount of spam, it is easy to miss and therefore
   delete posts that need manual approval.

   Please use your subscribed address to post, or shorten your
   postings by using links instead of attachments. ]

fyi;

There is a new I-D for the SPF email anti-forgery system available for
review.  This draft tries to document the current practices of the
~~1,000,000[1] published SPF records and ~10,000[1] deployed SPF
systems that are checking 20-100million emails per day.

See: http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-00.txt

Discussions about this, and previous, drafts have been taking place on
the spf-discuss <at> v2.listbox.com mailing list.  To subscribe or read
the archives, see http://spf.pobox.com/mailinglist.html

While I have been reading this mailing list for many months and will
note any comments posted here, sending email to the spf-discuss list
or to me personally is probably better than flooding this list.

I realize that the whole subject of SPF (and similar systems) has a
certain amount of controversy to it, but for the purposes of this
(Continue reading)

Stephane Bortzmeyer | 10 Jan 09:19 2005
Picon

Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt

On Mon, Jan 03, 2005 at 08:41:36PM -0600,
 wayne <wayne <at> schlitt.net> wrote 
 a message of 47 lines which said:

> There is a new I-D for the SPF email anti-forgery system available
> for review.
...
> While SPF mostly deals with the [2]821 SMTP level, it also relies
> heavily on DNS to communicate between the domain owner, and the
> email receiver.  This I-D also makes provisions to create a new RR
> that is just a clone of the TXT RR type.  While I did not make it to
> IETF-61, it is my understanding that Stephane Bortzmeyer made a
> presentation on this subject during the DNSEXT session.

There have been apparently no reply. Does it mean that nobody see
solid problems and that there is a silent and rough consensus that
the I-D can move forward :-)

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

william(at)elan.net | 10 Jan 10:02 2005
Picon

Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt


On Mon, 10 Jan 2005, Stephane Bortzmeyer wrote:

> > There is a new I-D for the SPF email anti-forgery system available
> > for review.
> ...
> > While SPF mostly deals with the [2]821 SMTP level, it also relies
> > heavily on DNS to communicate between the domain owner, and the
> > email receiver.  This I-D also makes provisions to create a new RR
> > that is just a clone of the TXT RR type.  While I did not make it to
> > IETF-61, it is my understanding that Stephane Bortzmeyer made a
> > presentation on this subject during the DNSEXT session.
> 
> There have been apparently no reply. Does it mean that nobody see
> solid problems and that there is a silent and rough consensus that
> the I-D can move forward :-)

I do see some problems, but I already raised them at spf-discuss. 
But since you asked about it on namedroppers, I'll focus just list
what I do not like as far as dns is concerned:

1. The draft says that if SPF record is not found for say "sub.example.com", 
that lookup should be made for zonecut record which would probably be
"example.com". This is done as a way to simulate *.example.com and provide
spf record for all subdomains (especially when they exist unlike "*"), but
I think the problem is that these default SPF record are not identified 
any difernent as with "*" and its just normal spf record for that domain 
that is always the default and one can not turn this off. I have proposed 
instead using special prefix - possibly "*spf*" or just "**" so that
such records are clearly identified, this would also allow in the future 
(Continue reading)

Paul Vixie | 10 Jan 18:05 2005

Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt

> 1. The draft says that if SPF record is not found for say
> "sub.example.com", that lookup should be made for zonecut record which
> would probably be "example.com". This is done as a way to simulate
> *.example.com and provide spf record for all subdomains (especially
> when they exist unlike "*"), but I think the problem is that these
> default SPF record are not identified any difernent as with "*" and
> its just normal spf record for that domain that is always the default
> and one can not turn this off. I have proposed instead using special
> prefix - possibly "*spf*" or just "**" so that such records are
> clearly identified, this would also allow in the future to add feature
> to dns server itself that it could substitute default on its own
> instead of forcing client to do 2nd lookup each time.

the SPF steamroller can't slow down or change direction, nope.  or else
we'd be using namehack-based subclassing a la the "mail-from" proposal.

however, some thought should be given to protecting the root servers.
given that a number of ill-considered SPF clientsides already do things
like look at some/all header addresses even if only envelope addresses
are indicated, thus breaking mailing list exploders who leave the headers
as they are and only rewrite the envelope, we know that SPF's clientside
will be broad, unaudited, and powerful.  it may be that given a domain
name of sub.example.com, queries will be made for TXT RRs having names

     sub.example.com
     example.com
     com
     .

which would be bad.  with specific reference to RFC 1535, i'd like this
(Continue reading)

Jaap Akkerhuis | 11 Jan 15:46 2005
Picon

Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt


    with specific reference to RFC 1535, i'd like this
    danger to be called out in the dns-related part of the SPF document, in
    case any clientside implentor ever actually reads the SPF specification.
    perhaps a prohibition of the form "SPF queries must never be made for
    domain names having fewer than two labels".

Although I agree with Paul about the danger (unnecessarily querying
of root and tld domains) he tries to guard against with this language,
this won't help tlds with second level or deeper level structure
such as co.uk or eu.int.

This whole idea of walking up the tree looking for an SPF record
seems to be broken to me.

	jaap

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

Dean Anderson | 11 Jan 16:47 2005

Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt

SPF has been shown not to work, and I've collected about 14 major problems
with it, posted on ietf-mxcomp.  SPF fails to achieve the goals set out,
and makes some problems worse.  The ietf-mxcomp working group (created for
SPF) has shut down.  But some people continue to push SPF ahead anyway.  
I think the reasons are financial. Some have patents and products, and
want an IETF stamp of approval for their marketing literature.

Indeed, I thought you were one of the people who wanted to push it ahead
despite the failures.  Is your post a rhetorical question?

I think the silence (and workgroup dissolution) means that people have
realized that it won't work and that no one has any solutions.

		--Dean

On Mon, 10 Jan 2005, Stephane Bortzmeyer wrote:

> On Mon, Jan 03, 2005 at 08:41:36PM -0600,
>  wayne <wayne <at> schlitt.net> wrote 
>  a message of 47 lines which said:
> 
> > There is a new I-D for the SPF email anti-forgery system available
> > for review.
> ...
> > While SPF mostly deals with the [2]821 SMTP level, it also relies
> > heavily on DNS to communicate between the domain owner, and the
> > email receiver.  This I-D also makes provisions to create a new RR
> > that is just a clone of the TXT RR type.  While I did not make it to
> > IETF-61, it is my understanding that Stephane Bortzmeyer made a
> > presentation on this subject during the DNSEXT session.
(Continue reading)

Stephane Bortzmeyer | 11 Jan 16:52 2005
Picon

Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt

On Tue, Jan 11, 2005 at 10:47:35AM -0500,
 Dean Anderson <dean <at> av8.com> wrote 
 a message of 47 lines which said:

> SPF has been shown not to work,

This is clearly off-topic for this group. As said by the chairs at
IETF 61, "DNS extensions" should focus on DNS issues, like Paul Vixie
did by addressing the new RR type question.

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

Stephane Bortzmeyer | 11 Jan 17:15 2005
Picon

Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt

On Tue, Jan 11, 2005 at 03:46:17PM +0100,
 Jaap Akkerhuis <jaap <at> NLnetLabs.nl> wrote 
 a message of 21 lines which said:

> this won't help tlds with second level or deeper level structure
> such as co.uk or eu.int.

At least, it will mitigate the problem.

> This whole idea of walking up the tree looking for an SPF record
> seems to be broken to me.

The rationale is to handle domains with subdomains (like
www.example.com or sales.example.com) which typically forget to set up
a SPF record for the subdomains. So, the phisher can just say MAIL
FROM:<president <at> www.example.com> and defeat SPF even if example.com is
protected.

Of course, the proper solution is to have SPF records automatically
generated by the same process that creates the zone file with the
proper PTR, the MX records and so on. But some people seems to edit
large zone files by hand (they typically do not know M4 or Perl or
Ruby) and want a mechanism to help them.

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

(Continue reading)


Gmane