The IESG | 17 May 2013 23:10
Picon
Favicon

Protocol Action: 'Signaling Cryptographic Algorithm Understanding in DNSSEC' to Proposed Standard (draft-ietf-dnsext-dnssec-algo-signal-10.txt)

The IESG has approved the following document:
- 'Signaling Cryptographic Algorithm Understanding in DNSSEC'
  (draft-ietf-dnsext-dnssec-algo-signal-10.txt) as Proposed Standard

This document is the product of the DNS Extensions Working Group.

The IESG contact persons are Ted Lemon and Brian Haberman.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-signal/

Technical Summary

  The DNS Security Extensions (DNSSEC) were developed to provide
  origin authentication and integrity protection for DNS data by using
  digital signatures. These digital signatures can be generated using
  different algorithms. This draft sets out to specify a way for
  validating end-system resolvers to signal to a server which digital
  signature and hash algorithms they support. 

Working Group Summary

  The DNSEXT WG members reviewed and commented on previous revisions
  of the  document. All substantive comments were reviewed and the
  document updated accordingly. Most reviewers feel that the proposed
  extensions would be harmless to the protocol and would be useful for
  measuring cryptographic algorithm implementation uptake in
  clients. A minority of the reviewers questioned the need for such
  signalling. No reviewers flagged the existence of the proposed EDNS0
  extension create interoperability or deployment problems.
(Continue reading)

Ted Lemon | 11 May 2013 17:25

Updates to draft-ietf-dnsext-dnssec-algo-signal draft as a result of IESG review

During IESG review some subtle issues were raised with the DNSSEC algorithm signaling draft that resulted
in an RFC editor note being added to the document.   I'm writing this note to apprise the working group of the
changes that were made.   My expectation is that the working group will not see any of these changes as
substantially changing the document in a way that would influence the outcome of the last call, but they
are not merely editorial, so it seemed appropriate to give the working group a shot at them.

The complete editor's note is here: http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-signal/writeup/

The particular change to which I want to draw your attention relate to the question of what it means for a
resolver to be a validating resolver.   The document as submitted by the working group allowed for the
possibility that a validating resolver might not set the DO bit; this then led to an ambiguity in section 5
about the processing of the three new options.

The text as submitted by the working group said that the server doesn't process the options if the DO bit
isn't set.   The question was raised: what if a validating resolver doesn't set the DO bit for a particular
query?   Don't we still care, in principle, what algorithms it supports?

The clarifying change is the change to section 3.1.1: a validating stub resolver is now defined for the
purposes of the document as one that sets the DO bit.   The actual piece of software running on the host may
sometimes set the DO bit and sometimes not, but we only _treat_ it as a validating resolver if it does.

If this sounds like an interesting point to you, please check out the editor's note and see how it affects the
draft.   If we don't hear any substantive objection by midweek, I will release the document for publication
with the editor's note as is.  There are a number of editorial changes in the editor's note as well; the
changes that pertain to this question are specifically those that address 3.1.1 and 3.2.1.

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext
(Continue reading)

Phillip Hallam-Baker | 8 May 2013 00:14
Picon

Re: SPF, a cautionary tale




On Mon, May 6, 2013 at 2:58 PM, <bmanning <at> vacation.karoshi.com> wrote:

> I'm an existence proof that your claim is false.  I've read RFC5507 and I'm
> familiar with its contents.  I've already said that, were we writing this
> anew, I think we'd likely be taking a different path here, one that would
> make the members of dnsext much happier.  But since the former is false,
> and there's a substantial deployed base much of which is unlikely to change
> its behaviour for various reasons, we have to look at this a different way.


        there is this wonderful thing called "O'Dells Law" which, paraphrased
        is:  "The installed based doesn't matter".   However, there is nothing
        preventing the SPF community from using TXT to store thier particularly
        unique stuff.  But there can be zero whining when other folks use TXT for
        their own purposes and confuse the heck out of SPF processors which get
        (for thier purposes) malformed SPF data...


O'Dells Law only applies AFTER you have reached critical mass and growth is automatic.

If you are in a situation where the installed base meets the requirements just fine then the new proposal doesn't matter and will actually shrink over time as a percentage of the installed base as people continue to use the legacy system.

If the numer of domains with feature X is growing at a significantly faster rate than the Internet then it will become ~100% in due course.

If the numer of domains with feature X is growing at a significantly slower rate than the Internet then it will become ~0% in due course.


About one year after an RFC has been published there is sometimes a sudden shock of realization that maybe deployment did matter after all. Catching an existing system is very hard. Apart from POP vs IMAP and WWW vs Gopher, I can't remember any examples offhand.

--
Website: http://hallambaker.com/
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext
Murray S. Kucherawy | 6 May 2013 16:04
Picon

Re: SPF, a cautionary tale

On Mon, May 6, 2013 at 5:58 AM, <bmanning <at> vacation.karoshi.com> wrote:
        there is this wonderful thing called "O'Dells Law" which, paraphrased
        is:  "The installed based doesn't matter".   However, there is nothing
        preventing the SPF community from using TXT to store thier particularly
        unique stuff.  But there can be zero whining when other folks use TXT for
        their own purposes and confuse the heck out of SPF processors which get
        (for thier purposes) malformed SPF data...

Numerous such cases exist (I gave ut.edu as an example) and nobody is doing any of the aforementioned whining.  Establishing a loop across a set of strings looking for the one that starts "v=spf1" is hardly rocket science.  If that's the primary concern, I think we're good to go from here.

-MSK
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext
Murray S. Kucherawy | 6 May 2013 02:34
Picon

Re: SPF, a cautionary tale

On Sun, May 5, 2013 at 1:53 AM, <bmanning <at> vacation.karoshi.com> wrote:
> If you're saying that the author of RFC 6686 is lying about the data he
> presents, including 400,000 domains that publish TXT SPF records and the
> few thousand that publish type 99, I'll pass the message along.

        I'm saying that your claim of millions of messages is flawed.
        No as to the claims for RFC 6686, I'll be happy to take those numbers
        at face value. (but, yeah, pass my concerns along)
        402,000 domains using SPF is barely statistically relevent, considering
        there are over 350 million domains in existance.  just over 1%.

Isn't "domains that appear to be sending mail" a more useful universe from which to sample than "registered domains"?

        apparently no one in the spfbis wg bothered to read http://tools.ietf.org/html/rfc5507
        and there is no time limit to the choice of a good idea v. a bad idea.
        a bad idea can and should be questioned at any time - there is no
        "its too late" arguemnt that should hold, particularly when there is
        roughly 1% penetration of the service against the number of existing domains.

I'm an existence proof that your claim is false.  I've read RFC5507 and I'm familiar with its contents.  I've already said that, were we writing this anew, I think we'd likely be taking a different path here, one that would make the members of dnsext much happier.  But since the former is false, and there's a substantial deployed base much of which is unlikely to change its behaviour for various reasons, we have to look at this a different way.
 

> Despite what the fantasists in dnsext imagine, there is no chance
> whatsoever of getting those hundreds of thousands of existing mail systems
> to change the way they publish and check SPF data, particularly a change
> that has less than no operational benefit.  (Don't argue unless you know
> more people who run large mail systems than I do, and I meet pretty much
> all of them at MAAWG meetings.)  The only recent changes I can think of
> are that Yahoo used to check both TXT and type 99 and now only checks TXT,
> and Micsosoft mail properties including Hotmail gave up on Sender ID and
> just check SPF.

        my what a pessemistic/fatalistic attitude you have there.
        and again with your unsupported assertions.

His pessimism is founded in reality.  I have similar contact with the same people, and I reach the same conclusion.
 
-MSK
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext
Mark Andrews | 5 May 2013 13:06

Re: SPF, a cautionary tale


	I looked a 25579 unique domains that have sent me email
	over the last 20 odd years.

	737 (2.88%) failed to resolve when queried with SPF
	of those 737, 178 subequently succeeded with A TXT query

	853 (spf query) + 102 (txt query) of those return a non
	empty answer section (138 + 4 cnames). 

	As far as I can see  success difference between SPF and TXT
	is at the noise level.

	Mark
--

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka <at> isc.org
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

bmanning | 5 May 2013 10:53

Re: SPF, a cautionary tale

On Sun, May 05, 2013 at 12:51:52AM -0400, John R Levine wrote:
> Re CNAME and SPF looping, whatever you call them, the loop breaking issues 
> are the same.  This really isn't a complicated idea.  SPF is slightly 
> uglier since a single SPF record can have multiple includes, but the 
> solution, a fixed limit on the iterations, is the same.

	one vs. many ...  and the number of includes in SPF is bounded
	at the upper limit of...?

> > Please enumerate "all of the large systems" that use SPF. etc, etc
> 
> Sorry, it's not my job to do your homework.  You can get a pretty good 
> idea of whether a system uses SPF by seeing it if publishes SPF records 
> (the TXT records mail systems actually use, not the type 99 they don't.) 
> I expect you can do that better than I can.  I'll be pretty surprised if 
> you find a large system that doesn't other than Yahoo, who doesn't for 
> internal political reasons, but we know they check SPF since they do 
> queries for the records when you send them mail.

	Not my job to prove your unfounded assertions.

> >	John, your lack of crispness and accuracy suggest that you are 
> >	conflating
> >	any number of concepts.  While the number of messages surrounding 
> >	this
> >	topic is large, I am confident that your estimates are off by several
> >	orders of magnitude.
> 
> If you're saying that the author of RFC 6686 is lying about the data he 
> presents, including 400,000 domains that publish TXT SPF records and the 
> few thousand that publish type 99, I'll pass the message along.

	I'm saying that your claim of millions of messages is flawed.
	No as to the claims for RFC 6686, I'll be happy to take those numbers
	at face value. (but, yeah, pass my concerns along)
	402,000 domains using SPF is barely statistically relevent, considering
	there are over 350 million domains in existance.  just over 1%.

> >   If the SPF WG had actually read the DNS RFCs, they
> >   would have known about the formal advice regarding overloading TXT.
> >   Why did the WG reject this RFC?
> 
> As you would know if you had read the recent traffic in dnsxet and spfbis, 
> or looked at the spfbis charter, the WG is updating RFC 4408 and 
> documenting existing practice.  Nobody claims that it was a swell idea to 
> use unprefixed TXT records a decade ago, but unless you can provide us 
> with a time machine, there's nothing to be done about it now.

	apparently no one in the spfbis wg bothered to read http://tools.ietf.org/html/rfc5507
	and there is no time limit to the choice of a good idea v. a bad idea.
	a bad idea can and should be questioned at any time - there is no
	"its too late" arguemnt that should hold, particularly when there is
	roughly 1% penetration of the service against the number of existing domains.

> Despite what the fantasists in dnsext imagine, there is no chance 
> whatsoever of getting those hundreds of thousands of existing mail systems 
> to change the way they publish and check SPF data, particularly a change 
> that has less than no operational benefit.  (Don't argue unless you know 
> more people who run large mail systems than I do, and I meet pretty much 
> all of them at MAAWG meetings.)  The only recent changes I can think of 
> are that Yahoo used to check both TXT and type 99 and now only checks TXT, 
> and Micsosoft mail properties including Hotmail gave up on Sender ID and 
> just check SPF.

	my what a pessemistic/fatalistic attitude you have there.
	and again with your unsupported assertions.  

> >	To be clear - at this point I'd really like to see you document any
> >	formal study of the impact of SPF on the DNS.  From any credible 
> >	source.
> >	Anything.
> 
> The closest thing to a study is what's described in RFC 6686, and it 
> wasn't looking for effects on the DNS other than to observe in passing the 
> *fact* that in 2012, when it was published, a lot of DNS servers didn't 
> respond to type 99 requests at all (no NODATA, no NXDOMAIN, no nothing), 
> despite that being obviously, painfully wrong.  Again, if you don't 
> believe it, I'll be happy to let the author know you think he's lying.
> 
> Beyond that there is none.  No study, no effect.  Feel free to prove 
> otherwise.

	"No effect"???  You've just completely flipped from your original
	assertion back on May 3rd, "interpreting SPF records requires more 
	DNS queries than any other DNS application I know."  Which is it?

	I don't need to prove your assertions, I want some proof that your 
	assertions about the impact on the DNS are based on actual facts.

/bill
	
> 
> R's,
> John
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Douglas Otis | 5 May 2013 03:30
Picon

Re: SPF, a cautionary tale


On May 4, 2013, at 6:22 PM, bmanning <at> vacation.karoshi.com wrote:

> On Sat, May 04, 2013 at 11:16:38AM -0400, John R Levine wrote:
>>>> ... and interpreting SPF records requires more DNS queries than any 
>>>> other DNS application I know.
>> 
>>> 	So what you are saying is that SPF is a carefully crafted DNS
>>> 	DDoS attack because it was too hard to do the work inside your
>>> 	own protocol?
>> 
>> Yup, just like CNAME.
>> 
> 
> 	excuse me,  how do you reconcile your first statement; "more DNS queries
> 	than -any- other DNS application I know"  with "just like CNAME"
> 
> 	CNAME semantics and behaviour are well known and studied.  You get -ONE-
> 	redirect.   Other DNS tricks have been DNS-abusive and have been abandon
> 	(BITSTRING) or redesigned (KEY/SIG).
> 
>> In the decade that SPF has been around, the putative DDoS has never been 
>> observed in the wild, ever, despite Doug Otis warning us about it every 15 
>> minutes since 4408 was a draft, and a few experiments I did with stunt DNS 
>> servers that returned giant trees of SPF records very slowly.  It turns 
>> out everyone does loop breaking, just like for CNAME.  It's a sloppy 
>> design from a decade ago that succeeded because it made an end run around 
>> the DNS provisioning problems of "better" alternatives.
> 
> 	care to publish the experiment and its results?
> 	I'd like to replicate it.
> 
>>> 	What ever happened to "Be Conservative in What you Send..."
>> 
>> It lost out to Stuff That Actually Exists Works Better than Stuff That 
>> Doesn't.
> 
> 
> 	actually, not so much - there is certainly a whole lot of parasitic 
> 	behaviour in this decades work - there appears to be evidence that 
> 	the SPF RR type exists and works.
> 
>> A decade ago, SPF was far from my favorite authentication design, but now 
>> it exists, it's more widely used than most standards track protocols, and 
>> it would be silly to pretend otherwise.  Hence the spfbis charter to 
>> standardize existing practice.
> 
> 	Now that I have a hard time believing... "more widely used that most
> 	standards track protocols"  is a mightly big brush.  Perhaps you want
> 	to focus on SMTP authentication - then I would have an easier time 
> 	believing you.
> 
>> R's,
>> John

Dear Bill and John,

May I also add, SPF verification of the Mail From parameter provides authorization for Non-Delivery
Notifications.  It does not provide any form of Authentication.

Regards,
Douglas Otis
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

John R Levine | 4 May 2013 17:16

Re: SPF, a cautionary tale

>> ... and interpreting SPF records requires more DNS queries than any 
>> other DNS application I know.

> 	So what you are saying is that SPF is a carefully crafted DNS
> 	DDoS attack because it was too hard to do the work inside your
> 	own protocol?

Yup, just like CNAME.

In the decade that SPF has been around, the putative DDoS has never been 
observed in the wild, ever, despite Doug Otis warning us about it every 15 
minutes since 4408 was a draft, and a few experiments I did with stunt DNS 
servers that returned giant trees of SPF records very slowly.  It turns 
out everyone does loop breaking, just like for CNAME.  It's a sloppy 
design from a decade ago that succeeded because it made an end run around 
the DNS provisioning problems of "better" alternatives.

> 	What ever happened to "Be Conservative in What you Send..."

It lost out to Stuff That Actually Exists Works Better than Stuff That 
Doesn't.

A decade ago, SPF was far from my favorite authentication design, but now 
it exists, it's more widely used than most standards track protocols, and 
it would be silly to pretend otherwise.  Hence the spfbis charter to 
standardize existing practice.

R's,
John
Attachment (smime.p7s): application/pkcs7-signature, 2317 bytes
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext
David Conrad | 3 May 2013 23:01

Re: loads of TXT records for fun and profit

Phil,

On May 3, 2013, at 1:39 PM, Phil Pennock <namedroppers+phil <at> spodhuis.org> wrote:
> That is not my understanding as a reader of RFC4408 and as someone who
> worked with the coder (and documented the results) for the handling of
> TXT records in a widespread MTA to be as flexible as possible and to
> support SPF-style lookups.

Last sentence of RFC 4408, section 3.1.3:

"  SPF or TXT records containing multiple strings are useful in
   constructing records that would exceed the 255-byte maximum length of
   a string within a single TXT or SPF RR record."

Sure sounds to me like 4408 anticipates multiple TXT RRs.

Regards,
-drc

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Douglas Otis | 3 May 2013 21:04
Picon

Effects on DNS can be severe

Dear ietf and dnsext,

I apologies for posting this ahead of the wg last call.

Over many years at attempting to change the course of the SPF process, this effort appears to have been futile.
It seems many even feel the present spfbis document represents current practices.  It does not, from the perspective of macros.
I have written an I-D that I fully expect SPF proponents will denounce and so I have left that wg alone.  

Here is a draft written in hopes of placing these concerns into a broader scope--

Two references in this draft  did not carry over in the same manner as in the tcl script?  
Until remedied, here are the links missing in this i-d:



SPF can pose serious threats, that when confronted, few solutions are available.  I have been able to convince some of the larger providers of this concern, who in returned offered assurances the macro extensions in their SPF libraries are removed and in doing so have not seen any problems.

This is a serious effort at addressing a security concern, please read this draft from that perspective.

Regards,
Douglas Otis

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Gmane