[DNSOP] I-D Action: draft-ietf-dnsop-dnssec-key-timing-04.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : DNSSEC Key Rollover Timing Considerations Authors : Stephen Morris Johan Ihren John Dickinson W. (Matthijs) Mekking Filename: draft-ietf-dnsop-dnssec-key-timing-04.txt Pages : 32 Date: 2014-07-04 Abstract: This document describes the issues surrounding the timing of events in the rolling of a key in a DNSSEC-secured zone. It presents timelines for the key rollover and explicitly identifies the relationships between the various parameters affecting the process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-key-timing-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-key-timing-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: I-D Action: draft-ietf-dnsop-dnssec-key-timing-04.txt
In the words of Stephen Morris DNSOP can now do add another skill to its list: practicing the art of necromancy. This is the return of the DNSSEC Key Timing draft. For those who are new; or don't remember; or choose not to relive those days, a little bit of history: Initially, the document draft-ietf-dnsop-dnssec-key-timing-03 had gone through the working group and was in Working Group Last Call (WGLC). The document stalled for various administrative reasons. Soon after, a companion document titled draft-mekking-dnsop-dnssec-key-timing-bis appeared, and stalled in a similar manner. This version of the document (which will be published as -04) does reflects the original document, but was driven by the consensus of the WG (which was and still is ship it). Hence, this does not include (m)any updates of the draft in draft-mekking-dnsop-dnssec-key-timing-bis. At the end of this email is the list of larger changes that are spelled out in the appendix. I am acting as Document Shepherd for this document, and the feeling is that we feel this document needs 2-3 weeks of editorial review, and then it would head back into WGLC. *What we do need* Since this draft has several equations, there is a need for 2-3 people to strongly review the changes and make sure everything is still correct. Lastly, I want to thank Stephen Morris, Matthijs Mekking, John Dickinson and Johan Ihren for accepting the challenge from the chairs and putting this back on track. I will make sure it makes it out this time. tim === (List of changes from previous version, from the Appendix) o draft-ietf-dnsop-dnssec-key-timing-04 * Renamed to DNSSEC Key Rollover Timing Considerations to emphasise that this draft concerns rollover timings. * Updated 4641bis reference to RFC 6781. * Add introductory paragraph to each rollover description summarising its essential features. * Remove detailed description of double-RRSIG ZSK rollover. It is extremely unlikely to be used in any practical situation. * Double-Signature KSK rollover renamed to Double-KSK to avoid confusion with the ZSK rollover of the same name. * Removed section 2.3 (rollover summary) which just listed the order in which records are published. * Matthijs Mekking added as co-author. * Changed Lzsk and Kzsk definitions: actual lifetime instead of intended lifetime. * Update diagrams and text to better reflect key states and key lifetimes. ---BeginMessage--- A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : DNSSEC Key Rollover Timing Considerations Authors : Stephen Morris Johan Ihren John Dickinson W. (Matthijs) Mekking Filename: draft-ietf-dnsop-dnssec-key-timing-04.txt Pages : 32 Date: 2014-07-04 Abstract: This document describes the issues surrounding the timing of events in the rolling of a key in a DNSSEC-secured zone. It presents timelines for the key rollover and explicitly identifies the relationships between the various parameters affecting the process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-key-timing-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-key-timing-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ---End Message--- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: New Version Notification for draft-mekking-dnsop-kasp-00.txt
Hi wg, I see more and more road maps that include implementing Key and Signing Policies, so Jerry and I thought it would be a good idea to standardize the policy model and the behavior of its elements. Ideally, policies can be used between multiple different software products, and if you do, you expect the same behavior. Here is an initial draft for this, we would appreciate your feedback. Best regards, Matthijs Original Message Subject: New Version Notification for draft-mekking-dnsop-kasp-00.txt Date: Fri, 04 Jul 2014 01:25:01 -0700 From: internet-dra...@ietf.org To: W. (Matthijs) Mekking matth...@nlnetlabs.nl, Jerry Lundstroem jerry.lundst...@iis.se, Jerry Lundstroem jerry.lundst...@iis.se, Matthijs Mekking matth...@nlnetlabs.nl A new version of I-D, draft-mekking-dnsop-kasp-00.txt has been successfully submitted by W. (Matthijs) Mekking and posted to the IETF repository. Name: draft-mekking-dnsop-kasp Revision: 00 Title: DNSSEC Key and Signing Policies Document date: 2014-07-04 Group: Individual Submission Pages: 16 URL: http://www.ietf.org/internet-drafts/draft-mekking-dnsop-kasp-00.txt Status: https://datatracker.ietf.org/doc/draft-mekking-dnsop-kasp/ Htmlized: http://tools.ietf.org/html/draft-mekking-dnsop-kasp-00 Abstract: This document describes how key policies should look like. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-wkumari-dnsop-dist-root-01.txt
Greetings. Warren and I have done a major revision on this draft, narrowing the design goals, and presenting more concrete proposals for how the mechanism would work. We welcome more feedback, and hope to discuss it in the WG in Toronto. --Paul Hoffman Begin forwarded message: From: internet-dra...@ietf.org Subject: I-D Action: draft-wkumari-dnsop-dist-root-01.txt Date: July 3, 2014 at 2:17:46 PM PDT To: i-d-annou...@ietf.org Reply-To: internet-dra...@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Securely Distributing the DNS Root Authors : Warren Kumari Paul Hoffman Filename: draft-wkumari-dnsop-dist-root-01.txt Pages : 9 Date: 2014-07-03 Abstract: This document recommends that recursive DNS resolvers get copies of the root zone, validate it using DNSSEC, populate their caches with the information, and also give negative responses from the validated zone. [[ Note: This document is largely a discussion starting point. ]] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-wkumari-dnsop-dist-root/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-wkumari-dnsop-dist-root-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-wkumari-dnsop-dist-root-01 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] various approaches to dns channel secrecy
i've now seen a number of proposals reaction to the snowden disclosures, seeking channel encryption for dns transactions. i have some thoughts on the matter which are not in response to any specific proposal, but rather, to the problem statement and the context of any solution. first, dns data itself is public -- the data is there for anybody to query for it, if you know what to query for. only the question, questioner, and time can be kept secret. answers are only worth keeping secret because they identify the question, questioner, and time. second, dns transactions are not secret to protocol agents. whether stub resolver, full resolver, forwarder, proxy, or authority server -- the full identity of the question must be knowable to the agent in order to properly process that question. if the agent does logging, then the question, questioner, and time will be stored and potentially shared or analyzed. by implication, then, the remainder of possible problem statement material is hide question from on-wire surveillance, there being no way to hide the questioner or the time. to further narrow this, the prospective on-wire surveillance has to be from third parties who are not also operators of on-path dns protocol agents, because any second party could be using on-wire surveillance as part of their logging solution, and by (2) above there is no way to hide from them. so we're left with hide question from on-wire surveillance by third parties. this is extremely narrow but i can envision activists and dissidents who rightly fear for their safety based on this narrowly defined threat, so i'm ready to agree that there should be some method in DNS of providing this secrecy. and as we know from the history of secrecy, if you only encrypt the things you care about, then they stand out. therefore, secrecy of this kind must become ubiquitous. datagram level channel secrecy (for example, DTLS or IPSEC) offers a solution which matches the existing datagram level UDP transport used primarily by DNS. however, the all-pervasive middleboxes (small plastic CPE devices installed by the hundreds of millions by DSL and Cable and other providers) have been shown to be more powerful than IPv6, DNSSEC, and EDNS -- we could expect them to prevent any new datagram level channel secrecy protocol we might otherwise wish to employ. TCP/53 is less prone to middlebox data inspection, and may seem to be an attractive solution here. i think not for two reasons. first, TCP/53 is often blocked outright, and second, because TCP/53 as defined in RFC 1035 has a connection management scheme that prohibits persistent TCP/53 connections at Internet scale, and we cannot afford the setup/teardown costs of a non-persistent TCP-based channel secrecy protocol for DNS. to those who suggest redefining TCP/53 and upgrading the entire physical plant and all software and operating systems, i challenge you to first show how this is less global effort than other proposals now on the table, and then show how you would handle the long-tail problem, since many agents will never be upgraded, or will only be upgraded on a scale of half-decades. DNS works today because TCP/53 is a fallback for UDP/53. its definition and deployment makes it unsuitable either currently or as-would-be upgraded to become the primary transport. i suggest that any channel secrecy protocol we wish to add to the DNS system must be suitable as the primary transport, to which the existing UDP/53 and TCP/53 protocols are fallbacks. i further suggest that any new transport be operable at internet scale, which demands connection persistence. finally i suggest that this be done using a protocol that the internet's middle boxes (cheap CPE devices who think they know what all valid traffic must look like) will allow to pass without comment. one candidate for this would be RESTful JSON carried over HTTPS. because of its extensive use in e-commerce and web API applications, HTTPS works everywhere. because HTTPS currently depends on X.509 keys, other groups in the IETF world are already working to make HTTPS proof against on-path surveillance. (google for perfect forward secrecy to learn more), and others are working to defend the internet user population against wildcard or targeted SSL certificates issued by governments and other anti-secrecy agents with on-path capabilities. stephane bortzmeyer has already shown us that JSON representation of DNS transactions is possible. i have heard from another protocol engineer who is also working in this area (and who credits bortzmeyer for informing his work). the special advantage of TCP/443 as a primary transport for persistent DNS with channel secrecy is that HTTPS's connection management permits massive scale, as in, a single protocol agent with tens or hundreds of thousands of open connections, even with local and global load balancing and connection pinning. in summary, i agree that we have a narrowly defined problem of on-path surveillance
