http://permalink.gmane.org/gmane.ietf.dnsext hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.dnsext/22432 <pre>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 reviewe</pre> The IESG 2013-05-17T21:10:48 http://permalink.gmane.org/gmane.ietf.dnsext/22431 <pre>* David Miller: It's also the overall packet length limit, so an entire RRset cannot be larger. _______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </pre> Florian Weimer 2013-05-11T20:36:41 http://permalink.gmane.org/gmane.ietf.dnsext/22430 <pre>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 </pre> Ted Lemon 2013-05-11T15:25:28 http://permalink.gmane.org/gmane.ietf.dnsext/22429 <pre> In message &lt;CAMm+Lwj44HbisG549bXMhGqFG_cZ5wZ42i_+-F7NqM9oH13m+Q&lt; at &gt;mail.gmail.com&gt; , Phillip Hallam-Baker writes: Both SPF queries and SPF records are growing w.r.t. TXT records and queries so the arguement is moot. Mark </pre> Mark Andrews 2013-05-07T23:13:55 http://permalink.gmane.org/gmane.ietf.dnsext/22428 <pre> 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. </pre> Phillip Hallam-Baker 2013-05-07T22:14:46 http://permalink.gmane.org/gmane.ietf.dnsext/22427 <pre> In message &lt;CAL0qLwaiL64XLxyKX2i94NAfAvMOqJwfdL3R9oB01FxJ=VEEsg&lt; at &gt;mail.gmail.com&gt;, "Murray S. Kucherawy" writes: As far as I can see there is nothing in it with respect to failure rates and spf sites using type SPF are approaching 8% which is a significant increase (2x) since the RFC6686 surveys. TXT: 22157 NOERROR, 2777 NXDOMAIN, 645 SERVFAIL, 9289 v=spf1 SPF: 22068 NOERROR, 2774 NXDOMAIN, 737 SERVFAIL, 730 v=spf1 CASE1 CASE2 CASE3 8614txt only 33.7% 92.2% 96.8% 96.6% 95.2% 55spf only 0.2% 0.6% 675 txt + spf 2.6% 7.2% have spf 7.8% 3.2% 3.4% 4.8% Mark </pre> Mark Andrews 2013-05-07T14:44:16 http://permalink.gmane.org/gmane.ietf.dnsext/22426 <pre> 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&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </pre> Murray S. Kucherawy 2013-05-06T14:04:16 http://permalink.gmane.org/gmane.ietf.dnsext/22425 <pre> Probably - but I was following Johns usage. 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... Sounds very much like the folks who hijacked net 1.0.0.0/8 for their wireless/NAT space. (Or pretty much anyone who has "borrowed" IP space because it was too hard to get/justify the space properly.) They have no incentive to change their installed base... except for interoperability problems. /bill _______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </pre> bmanning< at >vacation.karoshi.com 2013-05-06T12:58:23 http://permalink.gmane.org/gmane.ietf.dnsext/22424 <pre> 6686 asked the wrong questions, and then used the data to come to the wrong conclusions. It's totally irrelevant to the question, "How should SPF be done properly going forward?" Doug _______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </pre> Doug Barton 2013-05-06T08:38:05 http://permalink.gmane.org/gmane.ietf.dnsext/22423 <pre> 1) I think you're supporting RFC6686's conclusions there. 2) There was more than just the Alexa survey in RFC6686. -MSK _______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </pre> Murray S. Kucherawy 2013-05-06T08:31:16 http://permalink.gmane.org/gmane.ietf.dnsext/22422 <pre> In message &lt;CAL0qLwa-fWyB2NtVdMu02-iz8ZWnYo3+PJ4qFtxYeWe=KQtiwA&lt; at &gt;mail.gmail.com&gt; , "Murray S. Kucherawy" writes: That list of domains includes personal as well as business correspondence, spam sources, mail from various mailing lists. And RFC6686 is biased as it use the Alexa top X which is known to use more load balancers which are often not RFC 103[45] compliant name servers. They don't do negative answers properly. Fixing one set of nameservers in the Alexa top X can drastically change the numbers as many domains Alexa top X are served by identical sets of name servers. The vast majority of name servers (from sites sending email or not) respond to both TXT and SPF queries. Of those that don't most are broken for both TXT and SPF (and AAAA and NS and SOA). Mark </pre> Mark Andrews 2013-05-06T01:12:36 http://permalink.gmane.org/gmane.ietf.dnsext/22421 <pre> That's a far more constrained sample size than the RFC6686 surveys used, and I have some vague thoughts about likely bias of mail going to isc.org. -MSK _______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </pre> Murray S. Kucherawy 2013-05-06T00:36:13 http://permalink.gmane.org/gmane.ietf.dnsext/22420 <pre> 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 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. 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&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </pre> Murray S. Kucherawy 2013-05-06T00:34:00 http://permalink.gmane.org/gmane.ietf.dnsext/22419 <pre> 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 </pre> Mark Andrews 2013-05-05T11:06:34 http://permalink.gmane.org/gmane.ietf.dnsext/22418 <pre> one vs. many ... and the number of includes in SPF is bounded at the upper limit of...? Not my job to prove your unfounded assertions. 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%. 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. my what a pessemistic/fatalistic attitude you have there. and again with your unsupported assertions. "No effect"??? You've just completely flipped from your original</pre> bmanning< at >vacation.karoshi.com 2013-05-05T08:53:48 http://permalink.gmane.org/gmane.ietf.dnsext/22417 <pre> On May 4, 2013, at 6:22 PM, bmanning&lt; at &gt;vacation.karoshi.com wrote: 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&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </pre> Douglas Otis 2013-05-05T01:30:29 http://permalink.gmane.org/gmane.ietf.dnsext/22416 <pre> 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). care to publish the experiment and its results? I'd like to replicate it. 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. 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. _______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </pre> bmanning< at >vacation.karoshi.com 2013-05-05T01:22:16 http://permalink.gmane.org/gmane.ietf.dnsext/22415 <pre> On May 4, 2013, at 8:16 AM, John R Levine &lt;johnl&lt; at &gt;taugh.com&gt; wrote: Dear John and Bill, I have heard this canard several times as if it offers some level of assurance. How does one know whether SPF sourced any particular DDoS related query? These represent reverse PTR, TXT, A, AAAA record types at any location. It is also wrong to suggest SPF specification represents existing practice. Not all providers implemented SPF macro components. The decision to depreciate SPF (99) RRs happened at roughly the same level of local-part macro expansion use. Use of local-part macros requires other mechanisms to prevent unlimited spoofing when SPF pass becomes independent of the sending client. The impact that such clever mechanisms may have is unknown if they ever become popular. Thank you Bill for clearly expressing this opinion. Regards, Douglas Otis _______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </pre> Douglas Otis 2013-05-05T01:01:02 http://permalink.gmane.org/gmane.ietf.dnsext/22414 <pre> 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. 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_______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </pre> John R Levine 2013-05-04T15:16:38 http://permalink.gmane.org/gmane.ietf.dnsext/22413 <pre> 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? What ever happened to "Be Conservitive in What you Send..." /bill _______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </pre> bmanning< at >vacation.karoshi.com 2013-05-04T13:33:12 http://permalink.gmane.org/gmane.ietf.dnsext/22412 <pre> Well, yes, you're right, the RR's total length is a 16 bit value. I'd be pretty horrified if that were ever an issue for SPF. R's, John _______________________________________________ dnsext mailing list dnsext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dnsext </pre> John Levine 2013-05-04T04:30:00 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.dnsext