Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-dnssec-validator-requirements-01
Hi James, Thanks for the review. Please see inline my responses as well as the changes below: https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/commit/074ff71844b076b6e83ba8e0134a224b5f5617f9 Yours, Daniel On Thu, Nov 24, 2022 at 2:07 AM James Gannon via Datatracker < nore...@ietf.org> wrote: > Reviewer: James Gannon > Review result: On the Right Track > > Reviewer: James Gannon > Review Result: On the right track > > As this is an early review (And also my first ietf review so please feel > free > to offer feedback on its usefulness!) its a mix of general comments and > some > more detailed comments on sections that from a non-DRO operator perspective > dont seem to be overly logical. > >- The recommendations do not come with the same level of requirements > and > some are likely to be required. Other are optional and may be > followed by more advanced DROs. > > Suggestion to tighten up the language in this paragraph, if the authors > wish to > assign priority to the reccomendations then they should do so, however if > it is > up to the implementer to determine the applicability then state so clearly. > That is an interesting comment. In one part SHOULD / MUST are expected to provide some sort of priority. We could eventually as I think you are suggesting have our own way to prioritize the recommendations, but I am not sure we will be able to make it, so I am inclined to prefer staying with the maybe large categories created by SHOULD/MUST and let the operational team to select what is appropriated to them according to their deployments and policies. I propose to add the following sentence: It is up to the DRO to determine their applicability I think this addresses your concern. > - When these devices are re-plugged the initial time is set to January > 1 > 1970. > > As this is not universally true it is not valuable or required context and > should be considered for removal. > I think it describes pretty well what the problem is, so I think it might be preferred to indicate it as an example. I propose the following lines: With Raspberry Pi for example, when these devices are re-plugged their time is res et to some initial values like (January 1, 1970 for example) until they get re syn chronized via NTP. > -Because of this, it is recommended that implementations make the root >zone trust anchor obvious to the operator while still enabling >configuration of general trust points. > > If this is considered a RECCOMENDATION as per the document please use > consistent langugage and categorise it as with the other recs > > Current recommendations for DRO mostly describe how to handle the TA, but do not provide some recommendations regarding which TA should be trusted. I do see a slight difference between recommending how to operate the set of TA and recommending what should be trusted. The recommendation in question is also more addressed to implementers as DRO. As result, I agree that the use of normative language may be considered, but we probably do not want to issue a specific DRO recommendation. I propose to replace s/recommended/RECOMMENDED/. I hope this addresses your concern. -7.1.3. Configuration Generation > >The generation of a configuration file associated to the TA is >expected to be implementation independent. The necessity of tweaking >the data depending of the software implementer or eventually the >software version introduces a vector for configuration errors. > > No action for a DRO is associated with this section. Consider need of > section > or move to a general considerations section? > > Configuration Generation and DNSSEC Resolver Instantiation could be merged but I do think that it increases clarity of the purpose to have different sections. > Overall comment: The document is quite verbose and "wordy" I would suggest > for > a reccomendations document that the content is slimmed down to direct > reccomendations and any required context for implementors, rather than > extensive supporting information and general context > > The document is intended to be read to non DNSSEC experts and we believe the context being provided will be helpful to the target audience especially to help them balance the various trade-off. Overall comment: Considering that there are no actual requirements in the > draft > consider retitling it from -requirements to -reccomendations. > > Correct. There was only one word that has been changed. The name of the file cannot be changed, but I agree it would have been more appropriate. Initially we were targeting some requirements for implementations, and latter changed to recommendations for DRO which was what we are aiming at. > Overall comment: For the document to be valuable its critical that these > reccomendations are actually aligned with the needs and practices of DROs, > has > their input been considered in the drafting of these reccomendations. > > yes. We
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements
On Wed, Nov 23, 2022 at 10:29 AM Vladimír Čunát
wrote:
> OK, thanks. The changes are certainly improvements, in my eyes. Below
> I'll further clarify what I meant.
>
> 4033 indicates it does not make much sense to keep a RRSIG whose validity
> period has expired ( TTL > Validity period).
>
> Yes, I should stress that I do agree with trimming TTL of whole RRset by
> expiration of RRSIG that's used to validate it, and there are good reasons
> for that. I even had implemented that some time ago for Knot Resolver.
>
> As I wrote (perhaps unclearly), I was puzzled mainly by the recommendation
> that followed. I'm failing to really understand what it meant exactly, and
> by what mechanism it's meant to ensure coherence (in some cases?). And
> perhaps, how a validator operator could enforce such conditions without
> forking their validator. The line:
>
> RRsets TTL SHOULD NOT exceed the DS, KSK or ZSK initial TTL value, that
> TTL SHOULD trigger delegation revalidation as described in
> {{!I-D.ietf-dnsop-ns-revalidation}}.
>
>
> So let me know how we came to this lines and I suspect we do share some
similar concerns. A recurrent question and reticence we receive from MNO
and ISPs regarding DNSSEC is that they are really scared about having
the cache with incoherent RRsets in their cache that causes the validation
to fail and in many cases they imagine a mechanism to prevent and address
such incoherent data in the cache.
One of the intentions of this draft is to prevent such mechanisms to be
implemented - mostly as it is likely to generate errors that DNSSEC experts
would not be able to catch or understand - as generated by the home
made solutions. As a result we wanted to minimize the change to
the DNSSEC mechanic and only rely on very simple and standard mechanisms.
4033 provided one way to limit some incoherencies, and we also thought of a
similar mechanism that was like the one described in
I-D.ietf-dnsop-ns-revalidation which as we saw it ensures something like a
mechanism that refreshes the chain of trust.
What we expect is that the validator proposes this option and as such the
DRO selects that option in the validator if present.
>
> I agree we need to ensure good practice with 8624.
> I do agree this might not be very very useful today, but the reason we
> recommended this is also to ease communication between the resolvers and
> authorities. My impression is that it is hard to change the signature
> scheme on the authoritative side as we do not know what resolver will
> support it.
>
> Recommendations for authoritatives are a bit tangential here. I believe
> that RFCs (8624 or others) currently don't give a good idea about
> internet-wide support of resolvers for the algorithms, but you can find
> good measurements if you pay attention around IETF, OARC, etc. Alg. 13 is
> widely used for some time, even on TLDs, but 15 seems unfortunately still
> rather "risky" (or recently was):
> https://www.potaroo.net/ispcol/2021-06/eddi.html
>
>
> sure. So the idea is not to provide some recommendations to the
authoritative part, but what I wanted to stress is that having a
communication between resolvers and authoritative server is beneficial for
a better understanding of the DNS system involving multiple parties. Now,
given that EDNSO has some drawbacks an dthat the current mechanisms is not
deployed. I agree we can remove this recommendation.
>
> The question seems whether we should use such recommendations to improve
> communication between authoritative and resolvers or favor a more
> centralized approach where all software is more sticking to one
> document 8624. That latter approach seems to me to have too long cycles and
> I wished that we could benefit from new crypto ed25519 earlier than when
> all resolvers are updated.
>
> Well yes, I'm in favor of keeping the supported-algorithm set centralized
> internet-wide, instead of trying to start deploying a decentralized
> mechanism.
>
> Validators don't need to talk to *authoritative* servers. I believe it's
> quite common to have more than one layer of resolvers/caches, in which case
> an EDNS0 signal is just a bad mechanism, even if we somehow managed to
> deploy it widely. (which wouldn't be easy, kinda similarly to widely
> deploying EdDSA validation)
>
> I mainly wanted to dissuade from early algorithm deprecation on validator
> side. Validator operators might not understand that instead of validating
> a zone with a (supposedly) weak algorithm, they won't validate it at all.
> So the only improvement is the AD=1 bit which gets stricter by that, but
> most use cases don't even look at that bit and only rely on the protection
> by SERVFAILs.
>
>
> I got your point and agree it might be counter productive to encourage a
mechanism that is not reliable. I propose to remove the text below:
RUNTIME:
* A DRO SHOULD regularly request and monitor the signature scheme supported
by an authoritative server.
* A DRO SHOULD report a
Re: [DNSOP] DNSOP rfc8499bis Interim followup consensus on historical definition of bailiwick
Hi Peter, On 04/11/2022 00:52, Peter Thomassen wrote: On 11/3/22 17:44, Benno Overeinder wrote: Questions: 1b. Does this also mean changing the definition of "out-of-bailiwick" to a more historical definition as well? Or do we still need a term for in-domain name server, sibling domain name server and ... (alternative for out-of-bailiwick)? Is "unrelated name server" a term that can be used? I think "unrelated name server" is easy to misunderstand, as the term is unclear about what kind of relation it refers to. For example, a naive interpretation of an "unrelated" nameserver may be a sibling nameserver that is operated by another (unrelated) DNS provider. I would think that such misunderstandings will be frequent when this term is introduced. Think about various degrees of relationship, the following observation occurred to me. - in-domain nameservers are, in a sense, related to the 0th order (no delegations not shared between zone and NS), - sibling nameservers are related to 1st order (one delegation not shared, namely the one from the parent to the NS zone), - out-of-bailiwick nameservers are related to 2nd or higher order (example.com with ns1.example.net has 2 delegations not shared, namely the net delegation and the example.net delegation). One possible would thus be to establish terminology in terms of n-th order. E.g., sibling NS is a "1st-order foreign delegation NS" or something like that. -- I'm aware this sounds very bumpy, and it's simply what just occurred to me, not at all thought through. I'm also not trying to crash the interim results, just sharing the observation. If not helpful, ignore. :) Thank you for your input and your suggestion to come up with a more specific terminology for the "historical" out-of-bailiwick term. In the definition of in-domain and sibling domain, you suggest using the 0th and 1st order in the definition? And for out-of-bailiwick use a term like "2nd+ order nameservers"? I'd love to hear from other DNSOP participants if there is any support for Peter or any other suggestions for a good, more specific alternative term for out-of-bailiwick? -- Benno ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOP rfc8499bis Interim followup consensus on historical definition of bailiwick
Hi Libor, On 04/11/2022 12:15, libor.peltan wrote: Hi, I'm trying to understand this, but not sure if I do. What I see is: "The definition of bailiwick (in-b, out-of-b) is messed up and any further use of it in normative documents will probably lead to ambiguities. The proposed tactic is to stop using it and define a new term (in-domain) which means the same but it's definition will be precise and relevant in current state of DNS." If my understanding above is matching reality, then (note the implication) I agree with the proposed tactic. Indeed, your understanding is correct that is the intent of the question to the WG. Best, -- Benno Dne 03. 11. 22 v 22:44 Benno Overeinder napsal(a): Dear WG, With the DNSOP rfc8499bis interim in September, we had the action point to send two questions to the DNSOP WG to find consensus on the bailiwick and glue discussion. You can find the interim meeting material here https://datatracker.ietf.org/meeting/interim-2022-dnsop-02/session/dnsop and the recording of session here https://youtu.be/wY7-f40lDgU. We will send two questions to the WG, in two separate emails to keep the discussion separate. This email is the first question to the WG that addresses the definition of bailiwick. Questions: 1. Move Bailiwick to historical. 1a. During the interim, there was a (feeling of) consensus to drop a formal definition of "bailiwick", but keep a historical definition (how it was interpreted by) of "bailiwick". Also do not define and use the term "in-bailiwick". Suggested terms to use are "in-domain name server" and "sibling domain domain server", as defined and used in draft-draft-ietf-dnsop-glue-is-not-optional, section 2.1 and 2.2. [The latest draft of glue-is-not-optional does provide a definition of sibling domain name servers, but it does not really provide one for in-domain name servers. That would be easy to fix.] 1b. Does this also mean changing the definition of "out-of-bailiwick" to a more historical definition as well? Or do we still need a term for in-domain name server, sibling domain name server and ... (alternative for out-of-bailiwick)? Is "unrelated name server" a term that can be used? Thanks, -- Suzanne, Tim and Benno ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-rfc5933-bis-12: (with COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-dnsop-rfc5933-bis-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/ -- COMMENT: -- I support Roman's discuss. I would rather see this document be published by the ISE than go through the IETF stream. My specific concern is than an operator who reads this RFC and doesn't know the context may not be aware that this may be an inappropriate algorithm to use. Even if this is published via the ISE channel then I think that it should be stated very clearly early in the document that the cryptographic properties haven't been independently verified. Regards, Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
