Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel
On 11 Jun 2018, at 12:43, Job Snijders wrote: For what it's worth - all my concerns have been addressed. +1 to Job's feeling. I believe the document to be in good shape now and would support a progression through WG LC. except that we already went through WG Last Call. The changes to the document are large, but it is not clear to me that enough people are reading them to warrant another WG Last Call before sending it to the IETF Last Call. I appreciate the effort the authors have put into making this an exemplary specification! +1 again. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel
Dear all, For what it's worth - all my concerns have been addressed. I believe the document to be in good shape now and would support a progression through WG LC. I appreciate the effort the authors have put into making this an exemplary specification! Kind regards, Job On Mon, Jun 11, 2018 at 7:30 PM, Warren Kumari wrote: > Dear WG (and chairs), > > Firstly, thank you to everyone who supported this, those who provided > comments (especially pull requests!) and implementers. > > We have made a number of improvements to the documents based upon your > comments - the diff can be seen here: > https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-kskroll-sentinel-10=draft-ietf-dnsop-kskroll-sentinel-14 > > Possibly more helpful is the GitHub list of Pull Requests: > https://github.com/APNIC-Labs/draft-kskroll-sentinel/pulls?q=is%3Apr+is%3Aclosed > > We've added an implementation section - I know that there were more "client" > side (the Javascript or similar automated tests); I'd been keeping a note > with a list, but seem to have misplaced it. > > BIND and Unbound now support this; AFAIK, Knot supports the older name. > > > I *think* that we've managed to address the comments, but if we happened to > miss yours, please let us know. > > From my read of the WGs views, these, being *labels*, are not *Special Use > Domain Names*, and so don't need to be added to the SUDN registry. > > The authors would like to thank the WG again, and ask that WGLC be resumed. > > W > > > On Tue, Apr 24, 2018 at 9:02 AM Ondřej Surý wrote: >> >> And the MR was peer-review and merged into BIND master branch with intent >> to backport the feature into older release branches. >> >> I don’t think it’s a useful or helpful to change the rules for existing >> adopted work. We need to have a discussion on the mechanisms that would >> allow implementors to know when to start the implementation of existing >> draft. From implementors point, it makes little sense to start implementing >> before the protocol change is almost fully baked (aka WGLC and further), >> because until then the protocol might change considerably. >> >> So, if we require implementation report further down the road, it needs to >> be more clearly defined than people suddenly shouting “this is not ready” >> when WGLC starts. And while the attempt to implement something is certainly >> useful to get valuable feedback, it also imposes some costs (with undefined >> limit) on implementors (especially the open source implementors) and it sort >> of discards the whole “Proposed Standard” -> “Internet Standard” >> classification at global IETF level. >> >> I get that we probably need something more lightweight than “Internet >> Standard” at the WG level, but this needs to be discussed and consensus >> reached. >> >> ISC gave our feedback during the implementation and here are some nits >> from me (re-reading the document again): >> >> ~~~ >> >> Section "2. Protocol Walkthrough Example" will be made into Appendix at >> publication time, so just reminder here that you also need to change the >> references like "(see the logic below)” when you move the section - perhaps >> add direct reference to the other section this refers to? >> >> ~~~ >> >> The table in 3.2 says: >> >> "Key Tag is trusted” and “Key Tag is not trusted” - it seems little bit >> confusing to me; I think that “Key is trusted” and “Key is not trusted”; or >> some change similar to this needs to be made: >> >> “First, the resolver determines if the Key Tag is trusted by comparing >> numerical value of >>to any of the Key Tags of an active root zone KSK which is >>currently trusted…" >> >> in paragraph just before the table you mix “Key Tag” and “keytag” and >> there’s also … >> >> My understanding of the text and the proposed fix: >> >> […] >> >>First, the resolver determines if the numerical value of is >>equal to any of the Key Tags of an active root zone KSK which is >>currently trusted by the local resolver and is stored in its store of >>trusted keys. If a match is found the is trusted. An active >>root zone KSK is one which could currently be used for >>validation (that is, a key that is not in either the AddPend or >>Revoked state as described in [RFC5011]). >> >>Second, the resolver alters the response being sent to the original >>query based on both the left-most label and the presence of a key >>with given Key Tag in the trust anchor store. Two labels and two >>possible states of the generate four possible combinations >>summarized in the table: >> >> Label |is trusted|is not trusted >> -- >> is-ta | return original answer | return SERVFAIL >> not-ta | return SERVFAIL | return original answer >> >> […] >> >> ~~~ >> >>o A query name that is signed with a DNSSEC signature that cannot be >> validated (such as if the
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel
Dear WG (and chairs), Firstly, thank you to everyone who supported this, those who provided comments (especially pull requests!) and implementers. We have made a number of improvements to the documents based upon your comments - the diff can be seen here: https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-kskroll-sentinel-10=draft-ietf-dnsop-kskroll-sentinel-14 Possibly more helpful is the GitHub list of Pull Requests: https://github.com/APNIC-Labs/draft-kskroll-sentinel/pulls?q=is%3Apr+is%3Aclosed We've added an implementation section - I know that there were more "client" side (the Javascript or similar automated tests); I'd been keeping a note with a list, but seem to have misplaced it. BIND and Unbound now support this; AFAIK, Knot supports the older name. I *think* that we've managed to address the comments, but if we happened to miss yours, please let us know. >From my read of the WGs views, these, being *labels*, are not *Special Use Domain Names*, and so don't need to be added to the SUDN registry. The authors would like to thank the WG again, and ask that WGLC be resumed. W On Tue, Apr 24, 2018 at 9:02 AM Ondřej Surý wrote: > And the MR was peer-review and merged into BIND master branch with intent > to backport the feature into older release branches. > > I don’t think it’s a useful or helpful to change the rules for existing > adopted work. We need to have a discussion on the mechanisms that would > allow implementors to know when to start the implementation of existing > draft. From implementors point, it makes little sense to start implementing > before the protocol change is almost fully baked (aka WGLC and further), > because until then the protocol might change considerably. > > So, if we require implementation report further down the road, it needs to > be more clearly defined than people suddenly shouting “this is not ready” > when WGLC starts. And while the attempt to implement something is > certainly useful to get valuable feedback, it also imposes some costs (with > undefined limit) on implementors (especially the open source implementors) > and it sort of discards the whole “Proposed Standard” -> “Internet > Standard” classification at global IETF level. > > I get that we probably need something more lightweight than “Internet > Standard” at the WG level, but this needs to be discussed and consensus > reached. > > ISC gave our feedback during the implementation and here are some nits > from me (re-reading the document again): > > ~~~ > > Section "2. Protocol Walkthrough Example" will be made into Appendix at > publication time, so just reminder here that you also need to change the > references like "(see the logic below)” when you move the section - perhaps > add direct reference to the other section this refers to? > > ~~~ > > The table in 3.2 says: > > "Key Tag is trusted” and “Key Tag is not trusted” - it seems little bit > confusing to me; I think that “Key is trusted” and “Key is not trusted”; or > some change similar to this needs to be made: > > “First, the resolver determines if the Key Tag is trusted by comparing > numerical value of >to any of the Key Tags of an active root zone KSK which is >currently trusted…" > > in paragraph just before the table you mix “Key Tag” and “keytag” and > there’s also … > > My understanding of the text and the proposed fix: > > […] > >First, the resolver determines if the numerical value of is >equal to any of the Key Tags of an active root zone KSK which is >currently trusted by the local resolver and is stored in its store of >trusted keys. If a match is found the is trusted. An active >root zone KSK is one which could currently be used for >validation (that is, a key that is not in either the AddPend or >Revoked state as described in [RFC5011]). > >Second, the resolver alters the response being sent to the original >query based on both the left-most label and the presence of a key >with given Key Tag in the trust anchor store. Two labels and two >possible states of the generate four possible combinations >summarized in the table: > > Label |is trusted|is not trusted > -- > is-ta | return original answer | return SERVFAIL > not-ta | return SERVFAIL | return original answer > > […] > > ~~~ > >o A query name that is signed with a DNSSEC signature that cannot be > validated (such as if the corresponding RRset is not signed with a > valid RRSIG record). > > This is called “Bogus” by RFC 4033 Section 5 -> maybe a reference? > > ~~~ > > In Section: 7. Privacy Considerations > > s/mechansim/mechanism/ > > ~~~ > > That is all folks. > > Cheers, > Ondrej > -- > Ondřej Surý > ond...@isc.org > > > On 7 Apr 2018, at 08:27, Evan Hunt wrote: > > > > On Fri, Apr 06, 2018 at 10:09:50PM -0400, Warren Kumari wrote: > >> I think I heard that ISC
[DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-14.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 WG of the IETF. Title : A Root Key Trust Anchor Sentinel for DNSSEC Authors : Geoff Huston Joao Silva Damas Warren Kumari Filename: draft-ietf-dnsop-kskroll-sentinel-14.txt Pages : 21 Date: 2018-06-11 Abstract: 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 verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies a mechanism that will allow an end user and third parties to determine the trusted key state for the root key of the resolvers that handle that user's DNS queries. Note that this method is only applicable for determining which keys are in the trust store for the root key. [ This document is being collaborated on in Github at: https://github.com/APNIC-Labs/draft-kskroll-sentinel. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests. RFC Editor, please remove text in square brackets before publication. ] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-kskroll-sentinel-14 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-kskroll-sentinel-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-kskroll-sentinel-14 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] Last Call: (DNS Stateful Operations) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'DNS Stateful Operations' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-06-25. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a new DNS OPCODE for DNS Stateful Operations (DSO). DSO messages communicate operations within persistent stateful sessions, using type-length-value (TLV) syntax. Three TLVs are defined that manage session timeouts, termination, and encryption padding, and a framework is defined for extensions to enable new stateful operations. This document updates RFC 1035 by adding a new DNS header opcode and result code which has different message semantics. This document updates RFC 7766 by redefining a session, providing new guidance on connection re-use, and providing a new mechanism for handling session idle timeouts. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ballot/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
