[DNSOP] Secdir early review of draft-ietf-dnsop-domain-verification-techniques-05
Reviewer: Benjamin Kaduk Review result: Has Issues # SecDir review of draft-ietf-dnsop-domain-verification-techniques-05 CC @kaduk Since the changes from the -01 that I previously reviewed are so substantial, this is mostly a de novo review. The main comment on the diff is on the weakening of the guidance to enable DNSSEC validation from MUST to SHOULD, which I assume had ample WG discussion. Perhaps the identified exception cases that keep it from being a MUST could be mentioned in the draft, though? On the whole, though, this is good stuff, and I'll be happy to see it published. The one "discuss" point is mostly about being clear about what the actual requirements are for domain control validation and what we believe we're getting from the random token -- while I believe that our recommendation is secure and the right general recommendation, the PSL example seems to be a case that does securely perform the validation, but without a random token, which is a good opportunity for us to think about the underlying requirements. ## Discuss ### Recommendation for random token In toplevel §5 we say that "an issued random token then needs to exist in at least one of these to demonstrate the User has control over the domain name in-question", but this could stand to be more precise. While I agree that the random token is needed in general, we should be talking about which of unguessable, probabilistically collision-free, unique, bound to a given issuance event, etc. are needed. (We say just (§5.1) "128 bits of entropy", which is plenty to give the first three properties but needs a bit of help (underscore prefix) to get the last, and doesn't say which properties we're relying on that entropy for.) In particular the scheme used by the PSL (§A.1.1.5) does not use a random token but as far as I can tell it is fit for purpose, so I would say that the core underlying requirement is not just "random". I'll include some notes from my analysis below, with suggestion that we both clarify the specifics of the requirement (and why that translates to needing to be random in the general case) and include in §A.1.1.5 some discussion of why this the PSL flow is a secure flow. The PSL's verification scheme (§A.1.1.5) uses a github pull request URL rather than a random token. It seems like this is actually a secure flow, since it does provide a clear binding to intent to perform the requested operation and is collision-free (by use of a central authority). But to assess that, we really need to enumerage the risks that a DCV scheme needs to protect against. This list is going to include at least: - collisions, where an authorizing DNS record intended to authorize use at one service provider also authorizes use at another (this is most prominent when using a TXT record at the name being verified itself but may show up elsewhere)) - forwarding of challenge values from one service provider to another (so that a user authorizes an application other than the one they intend to) - more generally, confusion between the application and user about the scope of what is being authorized (e.g., single domain vs wildcard, among others) - an attacker guessing what the verification token will be and causing the corresponding DNS record to exist through means other than the authorization flow By having github generate the token (a URL) in a way that guarantees uniqueness, we prevent collisions, and the PR content covers what the intended action being confirmed is. It is pretty possible to guess what an upcoming verification token would be, but it seems pretty challenging to get someone to create a DNS record pointing to a URL that talks about something totally different. So while prediction/collision is possible, it seems pretty easy to detect as malicious and avoid using the collided URL. The PR also gets a nice binding of intent, since the literal operation being authorized is right there in the page referenced by the URL; for the scheme we recommend we need to combine both the underscore prefix and the random token to get an indication of intent (as provider plus unique token for specific authorization event), and even then rely on the provider's docs/UI to be clear about what they're doing on their end. But for all I'm lauding the PSL method, it's not suitable for general use since there's not a central authority to assign numbers/URLs, nor is there a generic way to have the token/URL clearly refer to the operation being authorized. And in many cases the parties involved don't want the operation being authorized to be particularly public -- the PSL is a rare case in that the whole point of it is to be public! ## Comments I remain a little nervous about allocating a new BCP number for a topic of fairly narrow scope such as this, but the guidance is good and worth publishing, and I have not better alternative
Re: [DNSOP] Secdir early review of draft-ietf-dnsop-domain-verification-techniques-01
Hi Paul, all, On Thu, Apr 20, 2023 at 11:46:30AM -0400, Paul Wouters wrote: > On Wed, 19 Apr 2023, Benjamin Kaduk via Datatracker wrote: > > [co-author hat on] > [...] > > > ### Continuing Ownership > > > > While I see the example in Appendix A.1.4.1 about Atlassian, when we say in > > the introduction that sometimes the DNS record must be kept in the zone to > > prove continued ownership of the domain, that doesn't exactly seem to hold > > true, or at least only provides a weak indication of continued ownership. I > > think that to really prove continued ownership the challenge would need to > > be > > rotated periodically; just putting one record in once and leaving it there > > mostly only shows that you had control of the domain at the one point in > > time > > it was added and that there isn't anything cleaning up old records. A > > wholesale migration of the domain to a different DNS server would clean up > > old > > records, but staffing changes within a large organization would not. > > That's a great point. We will add those considerations to the document. Thanks! > > ### Underscore for attrleaf > > > > In §3.1 we say "The provider constructs the validation domain name by > > prepending a provider-relevant prefix followed by "-challenge" to the domain > > name being validated (e.g. "_foo-challenge.example.com")." which implicitly > > uses an underscore-prefixed atterleaf name component. Is the underscore > > part > > of the required or recommended behavior? > > We can clarify it. The reason for the underscore is to avoid any > accidental real hostname matching. Eg someone could validly already use > "foo-challenge.example.com" to host a website. As underscores are not > valid hostnames (but are valid DNS names), the underscore prevents such > collissions. Thanks. I probably should have asked my question differently, in that I was pretty sure that the underscore was important, and I just wanted the document to be clear that it was required (or just recommended, if that's the case, but I see no reason to do anything other than required). > > ### Hashing the random token > > > > The recommendations in §3.1 requires computing the SHA-256 digest of the > > Random Token before base64url encoding and use as RDATA, but provides no > > justification for the SHA-256 step that I can see. If the intent is for the > > Random Token to be a non-public identifier for the challeng with only the > > digest value being public, we should say that. Otherwise it's not clear > > what > > we gain over just using base64url(random-data) as the RDATA. > > Good point. Let me get back to my co-authors on that. > > > ### TXT RDATA contents > > > > We say that the RDATA of the recommended TXT resource record construction > > must > > "contain" a certain token construction (rather than "consist of"). Does the > > format/structure of the RDATA also need to be one that unambiguously > > identifies where the token is (or is a raw substring match sufficient)? > > I believe we were trying to avoid issues where DNS presentation format can > have multi-line and spaces in them. Let me also take this back to my > coauthors for some discussion. Thanks for spotting this!. > > > I think we might provide clearer guidance if we laid out the recommended > > comma-separated key-value format first and talked about the token= contents, > > and then only afterward mention that even if other formats are used, the > > RDATA > > MUST contain the token value (and whether it must be identifiable as such > > via > > some metadata). Or we could state up front what properties we want from the > > RDATA before going on to describe how we achieve those properties. But the > > current formulation starts out with a MUST-level requirement without much > > context and then tries to build the context around it, which tends to cause > > confusion in the reader. > > > > Reading again, I think that the core of what is confusing me here is that > > the > > SHOULD-level guidance for using the comma-separated key-value pair format is > > buried as an aside in the mechanism for conveying the instructions for > > removing a resource record. It seems like it's a more generic > > recommendation > > and should be framed as such. > > We will look at clarifying that. Thanks. As was hopefully clear, I read the paragraph several times and had a couple different takes as I kept reading. It seems that probably the key points are: - there
[DNSOP] Secdir early review of draft-ietf-dnsop-domain-verification-techniques-01
Reviewer: Benjamin Kaduk Review result: Has Issues # SecDir review of draft-ietf-dnsop-domain-verification-techniques-01 CC @kaduk ## Discuss ## Comments I'm a little nervous about allocating a new BCP number for a topic of fairly narrow scope such as this, but the guidance is good and worth publishing, and I have not better alternative to offer, so I will stifle any objection I might have raised. On the whole the content is reasonable, but read on for some suggestions on how to tighten things up and some questions about why all the pieces are needed. I also made a PR with some editorial suggestions, https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/pull/51 ### Continuing Ownership While I see the example in Appendix A.1.4.1 about Atlassian, when we say in the introduction that sometimes the DNS record must be kept in the zone to prove continued ownership of the domain, that doesn't exactly seem to hold true, or at least only provides a weak indication of continued ownership. I think that to really prove continued ownership the challenge would need to be rotated periodically; just putting one record in once and leaving it there mostly only shows that you had control of the domain at the one point in time it was added and that there isn't anything cleaning up old records. A wholesale migration of the domain to a different DNS server would clean up old records, but staffing changes within a large organization would not. ### Underscore for attrleaf In §3.1 we say "The provider constructs the validation domain name by prepending a provider-relevant prefix followed by "-challenge" to the domain name being validated (e.g. "_foo-challenge.example.com")." which implicitly uses an underscore-prefixed atterleaf name component. Is the underscore part of the required or recommended behavior? ### Hashing the random token The recommendations in §3.1 requires computing the SHA-256 digest of the Random Token before base64url encoding and use as RDATA, but provides no justification for the SHA-256 step that I can see. If the intent is for the Random Token to be a non-public identifier for the challeng with only the digest value being public, we should say that. Otherwise it's not clear what we gain over just using base64url(random-data) as the RDATA. ### TXT RDATA contents We say that the RDATA of the recommended TXT resource record construction must "contain" a certain token construction (rather than "consist of"). Does the format/structure of the RDATA also need to be one that unambiguously identifies where the token is (or is a raw substring match sufficient)? I think we might provide clearer guidance if we laid out the recommended comma-separated key-value format first and talked about the token= contents, and then only afterward mention that even if other formats are used, the RDATA MUST contain the token value (and whether it must be identifiable as such via some metadata). Or we could state up front what properties we want from the RDATA before going on to describe how we achieve those properties. But the current formulation starts out with a MUST-level requirement without much context and then tries to build the context around it, which tends to cause confusion in the reader. Reading again, I think that the core of what is confusing me here is that the SHOULD-level guidance for using the comma-separated key-value pair format is buried as an aside in the mechanism for conveying the instructions for removing a resource record. It seems like it's a more generic recommendation and should be framed as such. ### Instructions for TXT record removal We say > Providers MUST provide clear instructions on when a verifying record > can be removed. The user SHOULD de-provision the resource record > provisioned for a DNS-based domain verification challenge once the > one-time challenge is complete. These instructions SHOULD be encoded > in the RDATA via comma-separated ASCII key-value pairs [RFC1464] > using the key expiry. If this is done, the token should have a key > token. For example: I think that the "these instructions" refers to the "clear instructions" provided by the provider. But the TXT record is something provisioned by the user, not the provider. If the instructions are to be encoded in the RDATA, does that require that the RDATA contents themselves are provided by the provider to the user? I'd strongly recommend including some more description of the workflow that's envisioned if it includes the provider giving the user the entire RDATA contents to copy/paste in place (and also using those RDATA contents as a separate information channel to the user). Additionally, do we make any requirement/recommendation of the format used for the value corresponding to the "expiry" key? ### CNAME chaining In §3.2 we see the
Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-svcb-https-08: (with DISCUSS and COMMENT)
Hi Ben, Also inline... On Wed, Mar 02, 2022 at 02:42:37PM -0500, Ben Schwartz wrote: > Thanks for the deep review, Ben. I've added your editorial comments to our > issue tracker (https://github.com/MikeBishop/dns-alt-svc/issues/369) and > responded inline where there were questions. > > On Tue, Mar 1, 2022 at 10:18 PM Benjamin Kaduk via Datatracker < > nore...@ietf.org> wrote: > > > -- > > DISCUSS: > > -- > > > ... > > > While there is a caution in §9.5 that: > > > >If this redirection would result in a loss of functionality (e.g. > >important resources that are only available on the "http" origin), > >the operator MUST NOT publish an HTTPS RR. > > > > but in my reading it leaves some important details as only implicit! > > We need to care not only about resources only available on one vs the > > other origin, but also about whether the translation would change the > > semantics of the client's request/response exchange. That is, whether the > > resources accessible by the different schemes are actually analogous > > (which, per the above, is not required by HTTP and is subject to the site > > administrator's control or in some cases other application protocols on > > top of HTTP used by that origin). > > > > Indeed, I expect that in the common case the resources will _not_ be > analogous, because the insecure HTTP endpoint will be blank except for a > redirect to "https". This is it mentions "important resources": a page > that says "Please use https instead" is not "important". Ah, good point. I think I've even seen a few of those myself, but only managed to think of "serve the same content just not over TLS" examples when I was writing this. > This (mostly implicit) requirement is a potential barrier for adoption of > > the HTTPS RRtype, and while the precondition is very often going to be > > satisfied, I wanted to get a sense for whether we should make the > > requirement more explicit, and possibly more prominent in the document > > (e.g., mention it in the Introduction). I don't know what the right > > answer is, but it seems important enough to ensure that the topic receives > > deliberate consideration. > > > > I've posted a PR that slightly expands the description of this feature, > both in §9.5 and in the introduction ( > https://github.com/MikeBishop/dns-alt-svc/pull/366). If you have ideas for > a more visible change, I'd be happy to hear them. I left some comments there, including noting that I put up a candidate "more visible change" at https://github.com/MikeBishop/dns-alt-svc/pull/374 > -- > > COMMENT: > > -- > > > > First off, thanks for this well-written document! It was pretty clear and > > easy to read despite covering some fairly complex logic. > > > > I made a github pull request with some hopefully boring editorial > > suggestions: https://github.com/MikeBishop/dns-alt-svc/pull/365 > > > > I did have a few high-ish-level thoughts that I either wasn't sure where > > to put in the section-by-section comments or wanted to make a bit more > > prominent. > > > > The first is a bit hard for me to describe, but basically, when we > > construct a QNAME for an SVCB or HTTPS query, we include information > > reflecting URI scheme and port, but when we get a TargetName back, that's > > been flattened to a single name, in some sense "using up more" of the DNS > > hostname namespace under the control of the alternative endpoint then in > > the authority's namespace. That is, if I wanted to provide service for > > both "foo" and "bar" schemes on two ports each, in order to serve all > > four combinations for a single service name, I would need to allocate four > > hostnames for alternative endpoints. We do mention this property as it > > relates to URI schemes, in §11.1 where we say that "zone owners SHOULD > > choose alias target names that indicate the scheme in use", but I didn't > > see much discussion of the port-related aspects. I know that the > > ServiceMode response can include a port to use in the parameters, so it's > > not really a concern about losing flexibility of what ports to use. It > > just seems "unbalan
Re: [DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-svcb-https-08: (with COMMENT)
On Mon, Feb 28, 2022 at 05:19:20PM -0500, Ben Schwartz wrote: > > > Does anyone know if there is a way to make something quoted in the > TXT output and code-formatted in the HTML output? Or is that discouraged > to avoid discrepancy between the renderings? The "quoted in TXT and code-formatted in HTML" scenario you describe was the behavior until fairly recently, but it was deliberately changed. I don't have a great hook into the relevant discussions, and though I thought Robert Sparks sent an announcement of the change to ietf@ I failed to find it just now. https://mailarchive.ietf.org/arch/msg/rfc-interest/RcoSXNRLoX3tqCbRxnneJ7EK2pk/ is perhaps a place to get started if you want to read up on the context of that change. -Ben ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] HTTPS upgrades (was Re: Benjamin Kaduk's Discuss on draft-ietf-dnsop-svcb-https-08: (with DISCUSS and COMMENT))
On Wed, Mar 02, 2022 at 02:46:05PM +1100, Martin Thomson wrote: > On Wed, Mar 2, 2022, at 14:18, Benjamin Kaduk via Datatracker wrote: > > This (mostly implicit) requirement is a potential barrier for adoption of > > the HTTPS RRtype, and while the precondition is very often going to be > > satisfied, I wanted to get a sense for whether we should make the > > requirement more explicit, and possibly more prominent in the document > > (e.g., mention it in the Introduction). I don't know what the right > > answer is, but it seems important enough to ensure that the topic receives > > deliberate consideration. > > Your point about highlighting more than loss of functionality is a good one. > The idea that request semantics might be altered by swapping the scheme is > far more relevant. > > That said, I'm comfortable with deploying with the upgrade requirement as > stated. While we did have a number of examples where the assumed > HTTP<->HTTPS equivalence did not hold in the past, the diminishing share of > cleartext HTTP usage is overwhelmingly the vestiges that do not have any > HTTPS service on the same name. > > As noted, those servers with a need to maintain distinct resources that > differ only in scheme simply cannot use the HTTPS RR. That is entirely > appropriate. > For clarity, I'm also comfortable with the upgrade requirement as stated; this discuss was intended to just relate to how and how much we talk about the requirement. -Ben ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-svcb-https-08: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-svcb-https-08: Discuss 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-svcb-https/ -- DISCUSS: -- I'd like to have a (hopefully brief!) discussion about our description of the "strict transport security" functionality the HTTPS RRtype provides, with respect to its accuracty/completeness and how explicit vs implicit we should be about the corresponding divergence from "pure" HTTP behavior. It's pretty clear that at a pure HTTP protocol level (which as far as I can tell is the scope of applicability that we claim) that resources accessed with "http" scheme and resources accessed with "https" scheme have no intrinsic relationship -- §4.2.2 of draft-ietf-httpbis-semantics-19 says: Resources made available via the "https" scheme have no shared identity with the "http" scheme. They are distinct origins with separate namespaces. [...] But the procedures in this document (e.g., §9.5, §9) seem pretty clear that, when an HTTPS record is published, accesses for "http" scheme resources should be converted to "https" scheme accesses, with implication that the client should expect to get the same resource back from the modified query compared to the unmodified "http"-scheme one. While there is a caution in §9.5 that: If this redirection would result in a loss of functionality (e.g. important resources that are only available on the "http" origin), the operator MUST NOT publish an HTTPS RR. but in my reading it leaves some important details as only implicit! We need to care not only about resources only available on one vs the other origin, but also about whether the translation would change the semantics of the client's request/response exchange. That is, whether the resources accessible by the different schemes are actually analogous (which, per the above, is not required by HTTP and is subject to the site administrator's control or in some cases other application protocols on top of HTTP used by that origin). This (mostly implicit) requirement is a potential barrier for adoption of the HTTPS RRtype, and while the precondition is very often going to be satisfied, I wanted to get a sense for whether we should make the requirement more explicit, and possibly more prominent in the document (e.g., mention it in the Introduction). I don't know what the right answer is, but it seems important enough to ensure that the topic receives deliberate consideration. -- COMMENT: -- First off, thanks for this well-written document! It was pretty clear and easy to read despite covering some fairly complex logic. I made a github pull request with some hopefully boring editorial suggestions: https://github.com/MikeBishop/dns-alt-svc/pull/365 I did have a few high-ish-level thoughts that I either wasn't sure where to put in the section-by-section comments or wanted to make a bit more prominent. The first is a bit hard for me to describe, but basically, when we construct a QNAME for an SVCB or HTTPS query, we include information reflecting URI scheme and port, but when we get a TargetName back, that's been flattened to a single name, in some sense "using up more" of the DNS hostname namespace under the control of the alternative endpoint then in the authority's namespace. That is, if I wanted to provide service for both "foo" and "bar" schemes on two ports each, in order to serve all four combinations for a single service name, I would need to allocate four hostnames for alternative endpoints. We do mention this property as it relates to URI schemes, in §11.1 where we say that "zone owners SHOULD choose alias target names that indicate the scheme in use", but I didn't see much discussion of the port-related aspects. I know that the ServiceMode response can include a port to use in the parameters, so it's not really a concern about losing flexibility of what ports to use. It just seems "unbalanced" in some sense that I can't really put my finger on. On the other hand, it's not like hostnames are a particularly limited resource, so I do
Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)
Hi Duane, Sorry for the very delayed response. I will go update my ballot position shortly, but please see https://github.com/jtkristoff/draft-ietf-dnsop-dns-tcp-requirements/pull/11 for some further edits to the text for discuss point (1). On Mon, Nov 08, 2021 at 10:35:21PM +, Wessels, Duane wrote: > Hi Ben, thank you for the detailed review. It has taken me a while to work > through > all of your comments and suggestions, but hopefully this addresses them > sufficiently. > > > > > On Oct 25, 2021, at 3:51 PM, Benjamin Kaduk via Datatracker > > wrote: > > > > > > -- > > DISCUSS: > > -- > > > > (1) This should be pretty easy to resolve, but this text from §4.4 > > does not seem to match up with the referenced document: > > > > The use of TLS places even stronger operational burdens on DNS > > clients and servers. Cryptographic functions for authentication and > > encryption requires additional processing. Unoptimized connection > > setup takes two additional round-trips compared to TCP, but can be > > reduced with TCP Fast Open, TLS session resumption [RFC8446] and TLS > > False Start [RFC7918]. > > > > Two additional round trips was true of TLS 1.2 and prior versions, but > > as of TLS 1.3 the application data from the client can be sent after > > only 1 round trip, accompanying the client Finished (and authentication > > messages, if in use). Given the nature of the rest of the sentence, we > > might want to specifically mention TLS 1.3 as an improvement over TLS > > 1.2, but there are probably a number of ways that we could fix it. Note > > additionally that for TLS 1.3, session resumption is not a reduction in > > the number of round trips unless 0-RTT data is used (but AFAIK there is > > not a published application profile specifying acceptable DNS content > > for TLS 0-RTT data, so use of TLS 0-RTT data for DNS is forbidden), but > > is still an efficiency gain due to the reduced number of cryptographic > > operations (including certificate validation). > > Is this better? > >The use of TLS places even stronger operational burdens on DNS >clients and servers. Cryptographic functions for authentication and >encryption requires additional processing. Unoptimized connection >setup with TLS 1.3 [RFC8446] takes one additional round-trip compared >to TCP. Connection setup times can be reduced with TCP Fast Open, >and TLS False Start [RFC7918]. TLS session resumption does not >reduce round-trip latency becase no application profile for use of >TLS 0-RTT data with DNS has been published at the time of this >writing. However, TLS session resumption can reduce the number of >cryptographic operations. As mentioned above, https://github.com/jtkristoff/draft-ietf-dnsop-dns-tcp-requirements/pull/11 has a few tweaks to this to account for the differences between TLS 1.2 and TLS 1.3, and the skew in feature availability between the TLS versions. (Highlights: RFC 7918 is 1.2-only, and TLS 1.2 session resumption does save a round-trip (the current text implicitly assumes 1.3).) > > > (2) Trivial to address, but the section heading for Appendix A.8 > > references RFC 3326 (The Reason Header Field for the Session Initiation > > Protocol (SIP)), not RFC 3226 (DNSSEC and IPv6 A6 aware server/resolver > > message size requirements) > > Thanks, this has been corrected. > > > > > > > > -- > > COMMENT: > > -- > > > > This document targets BCP status, while proposing an Updates: > > relationship with an Internet Standard and an Informational document. > > As mentioned in > > https://secure-web.cisco.com/16mLP8dG_ibZ9_hePr-XOEAMh0ghoochCF5XPpWWxHVs2rqFvgauZy7CTG1l4e8I_O8UaNtqmDrRRxvsmORmD2R1aCRr-SZvwMWwE5IcT1ky6ggdBCttsM0zPB1RTtvux53rPHrjpxbLUVVLSGGOUyh6nVhhkw1KE2dqgrO18iMEmjsLol05Dkj15p5m2l-O0-ZirQbfx_OkxB8W8tw_WkmVpMMsLm7IQwjG-dVQgbr5pK_hBp8VLx7I4WgryUGMW/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Flast-call%2FoMhqRigr4nbRSMll5NY4zXpZu20%2F > > there is some motivation for having updates to standards-track documents > > occur via other standards-track documents, but given that this document > > is mostly about giving operational guidance for DNS-over-TCP usage, > > there seems to be some argument that BCP is a more appropriate status > > for it. However, I do wonder if there is some existing
Re: [DNSOP] Lars Eggert's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)
Hi Paul, On Thu, Dec 23, 2021 at 06:48:24PM +, Paul Vixie wrote: > > > Benjamin Kaduk wrote on 2021-12-23 10:28: > > Hi Duane, > > > > On Mon, Nov 29, 2021 at 11:53:48PM +, Wessels, Duane wrote: > >> ... > >> > >> Proposed new text: > >> > >> Similarly, DNS server software MAY provide a configurable limit on > >> the total duration of a TCP connection. This can help protect > >> against unfair connection use, slow read attacks, and network evasion > >> attacks. > > not duane, but... > > > Maybe I'm just being dense today, or lost too much state in the intervening > > weeks, but how do these limits protect against network evasion attacks? > > What are "network evasion attacks" in this context, anyway? The draft > > references [phrack] in a different location surrounding use of that term, > > in the context of applications doing TCP stream reassembly from packet > > captures. In that location it seems that the TCP segmentation could cause > > the reassembling application to miss actual DNS protocol messages, but I'm > > not sure how transaction or time limits on a connection would protect > > against a similar loss of processing of DNS protocol messages by the > > reassembling application. > > ...without commenting on the text itself, i'll speak to the question. > when a dns responder tries to accept more simultaneous tcp connections > than it has capacity for, some kind of error will occur. for example in > UNIX the "accept()" system call will fail in user mode, and a TCP RST > will be sent in kernel mode. this is nonconstructive from a systemic > point of view since the client is not being given enough information to > inform its "what now?" decision. > > this condition can be predicted, however, and handled more > constructively. as an example if the dns responder knows that it only > has some number of file descriptors available or that the kernel only > has some number of tcp protocol control blocks available, then it could > treat the last few of these "quota slots" specially. for example, saving > the last slot or the last 5% of slots for error pathways, and answering > SERVFAIL or some other error code rather than attempting any useful work. > > the trouble with state, whether tcp protocol control blocks or any > other, is that it must be finite, and can be attacked. "syn flood" > attacks are an example, because protection against these was possible by > creating more state. DNS RRL is another example of how adding state can > resist attacks. in every case we must be able to imagine the outcome of > an attack on the limited resource, and try to behave constructively. Thanks for this; it helps me recover more of the background and paints a good picture of why these limits are useful. I'm still unclear on the connection to "network evasion attacks" specifically, though -- which limited resource are such attacks targeting? Maybe Duane can help with that. -Ben ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Lars Eggert's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)
Hi Duane, On Mon, Nov 29, 2021 at 11:53:48PM +, Wessels, Duane wrote: > > > > On Oct 26, 2021, at 4:35 AM, Lars Eggert via Datatracker > > wrote: [...] > > Section 4.2. , paragraph 3, comment: > >> DNS server software MAY provide a configurable limit on the number of > >> transactions per TCP connection. > > > > What does that limit protect against? > > proposed new text: > >DNS server software MAY provide a configurable limit on the number of >transactions per TCP connection. This can help protect against >unfair connection use (e.g., not releasing connection slots to other >clients) and network evasion attacks. > > > > > > Section 4.2. , paragraph 2, comment: > >> Similarly, DNS server software MAY provide a configurable limit on > >> the total duration of a TCP connection. > > > > What does that limit protect against? > > Proposed new text: > >Similarly, DNS server software MAY provide a configurable limit on >the total duration of a TCP connection. This can help protect >against unfair connection use, slow read attacks, and network evasion >attacks. Maybe I'm just being dense today, or lost too much state in the intervening weeks, but how do these limits protect against network evasion attacks? What are "network evasion attacks" in this context, anyway? The draft references [phrack] in a different location surrounding use of that term, in the context of applications doing TCP stream reassembly from packet captures. In that location it seems that the TCP segmentation could cause the reassembling application to miss actual DNS protocol messages, but I'm not sure how transaction or time limits on a connection would protect against a similar loss of processing of DNS protocol messages by the reassembling application. Thanks, Ben ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Erik Kline's Yes on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)
On Tue, Oct 26, 2021 at 01:09:00PM -0700, Erik Kline via Datatracker wrote: > Erik Kline has entered the following ballot position for > draft-ietf-dnsop-dns-tcp-requirements-13: Yes > > 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/blog/handling-iesg-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-dns-tcp-requirements/ > > > > -- > COMMENT: > -- > > [abstract vs. S1/S3, question] > > * The abstract says: > >"...strongly >encourages the operational practice of permitting DNS messages to be >carried over TCP" > > while section 1 says: > >"...all DNS resolvers and recursive >servers MUST support and service both TCP and UDP queries" > > and section 3 also some MUST text. > > Should the abstract be updated to say MUST rather than just > "strongly encourages", or is there a subtly in here I'm missing? "require" might be better than "MUST", on the principle that if a given requirement is stated in more than one place, there is risk of inadvertent skew between what is actually stated; such skew can cause interoperability failure or security vulnerabilities if different implementations use the differing behaviors. -Ben > [S4.1, comment] > > * "Resolvers and other DNS clients should be aware that some servers >might not be reachable over TCP. For this reason, clients MAY want >to track and limit the number of TCP connections and connection >attempts to a single server." > > I think the same comment could be made about paths to a server from > a given network, e.g., in the case of one network filtering TCP/53 for > some reason. > > I'm not sure how to best reword this to add a per-network notion to > TCP connection success tracking, but I did want to note that a mobile > client's measure of TCP connection success to a single server might > vary from network to network. (for your consideration) > > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-dns-tcp-requirements-13: Discuss 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/blog/handling-iesg-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-dns-tcp-requirements/ -- DISCUSS: -- (1) This should be pretty easy to resolve, but this text from §4.4 does not seem to match up with the referenced document: The use of TLS places even stronger operational burdens on DNS clients and servers. Cryptographic functions for authentication and encryption requires additional processing. Unoptimized connection setup takes two additional round-trips compared to TCP, but can be reduced with TCP Fast Open, TLS session resumption [RFC8446] and TLS False Start [RFC7918]. Two additional round trips was true of TLS 1.2 and prior versions, but as of TLS 1.3 the application data from the client can be sent after only 1 round trip, accompanying the client Finished (and authentication messages, if in use). Given the nature of the rest of the sentence, we might want to specifically mention TLS 1.3 as an improvement over TLS 1.2, but there are probably a number of ways that we could fix it. Note additionally that for TLS 1.3, session resumption is not a reduction in the number of round trips unless 0-RTT data is used (but AFAIK there is not a published application profile specifying acceptable DNS content for TLS 0-RTT data, so use of TLS 0-RTT data for DNS is forbidden), but is still an efficiency gain due to the reduced number of cryptographic operations (including certificate validation). (2) Trivial to address, but the section heading for Appendix A.8 references RFC 3326 (The Reason Header Field for the Session Initiation Protocol (SIP)), not RFC 3226 (DNSSEC and IPv6 A6 aware server/resolver message size requirements) -- COMMENT: -- This document targets BCP status, while proposing an Updates: relationship with an Internet Standard and an Informational document. As mentioned in https://mailarchive.ietf.org/arch/msg/last-call/oMhqRigr4nbRSMll5NY4zXpZu20/ there is some motivation for having updates to standards-track documents occur via other standards-track documents, but given that this document is mostly about giving operational guidance for DNS-over-TCP usage, there seems to be some argument that BCP is a more appropriate status for it. However, I do wonder if there is some existing BCP that this document would become part of, or if it would need to be given a new BCP number. It's not entirely clear how much scope there is for future additions that would become part of that same BCP, and whether a BCP number is truly needed in that scenario. It would be good to hear others' thoughts on this topic, especially in the form of references to previous WG discussion. I made a pull request on github with some editorial suggestions, most of which by volume are classifying the "Standards Track" documents in Appendix A properly as Internet Standard or Proposed Standard (there don't seen to be any lingering Draft Standards in the list): https://github.com/jtkristoff/draft-ietf-dnsop-dns-tcp-requirements/pull/10 Section 2.4 headers. Unfortunately, it is quite common for both ICMPv6 and IPv6 extension headers to be blocked by middleboxes. According to [HUSTON] some 35% of IPv6-capable recursive resolvers were unable to receive a fragmented IPv6 packet. [...] I looked through [HUSTON] and wasn't able to find this "35%" figure. There is a remark that "37% of endpoints used IPv6-capable DNS resolvers that were incapable of receiving a fragmented IPv6 response", but that seems to be a somewhat different statement in addition to a somewhat different percentage value. In particular, the sampling domain for the [HUSTON] statement as written appears to be "all endpoints", but the statement in this draft uses the sampling domain of "IPv6-capable recursive resolvers". However, the corresponding calculation in [HUSTON] looks to be using "IPv6-capable resolvers" as the sampling domain, just as this document states, which suggests that the error in phrasing is in [HUSTON] and not in this document. Section 3 As the directorate review noted, it's a little surprising to see the OLD/NEW formulation for one of the updates to §6.1.3.2 of RF
[DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-dnssec-iana-cons-04: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for
draft-ietf-dnsop-dnssec-iana-cons-04: 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/blog/handling-iesg-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-dnssec-iana-cons/
--
COMMENT:
--
Thanks to Dan Harkins for the secdir review, and the authors for the
corresponding updates.
Section 1
DNSSEC is primarily described in [RFC4033], [RFC4034], and [RFC4035].
DNSSEC commonly uses two resource records beyond those defined in RFC
4034: DS [RFC3658] (which was obsoleted by RFC 4034) and NSEC3
[RFC5155].
I'm a bit confused at how DS is "beyond those defined in RFC 4034" when
RFC 4034 includes discussion of DS, the record format, etc.
Section 4
In the "Domain Name System Security (DNSSEC) NextSECure3 (NSEC3)
Parameters" registry, the registration procedure for "DNSSEC NSEC3
Flags", "DNSSEC NSEC3 Hash Algorithms", and "DNSSEC NSEC3PARAM Flags"
are changed from "Standards Action" to "RFC Required".
I note (this is a "comment", after all, right?) that the "flags"
registries have only 7 values available. It is not entirely clear to me
that the IESG would be justified in using an RFC 5742 conflict-review
response to try to block any frivolous registration attempts made in
non-IETF-stream RFCs, but maybe we are willing to place confidence in
the other streams' managers behaving responsibly and otherwise accept
this risk.
NITS
Section 2 only talks about "DS or NSEC3 hash algorithms" but the actual
registry actions also cover the NSEC3{,PARAMS} flags registries.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Benjamin Kaduk's Yes on draft-ietf-dnsop-rfc7816bis-10: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-rfc7816bis-10: Yes 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/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7816bis/ -- COMMENT: -- The discussion about how many labels to add at each step is rather spread out amongst Sections 2, 2.3, and 3, and my preference would be to have a single more-clear specification of behavior for the Proposed Standard level of publication (but this is just a non-blocking comment and I recognize that addressing it would require somewhat invasive changes to the text). Looking over the diff from RFC 7816, I see that the discussion of empty non-terminals has been removed. Is that because the prevalence of servers that fail to handle them properly in the wild has dropped to an insignificant level? (If so, hooray!) If not, why was the text removed? We also removed the discussion of "some broken name servers [that] do not react properly to QTYPE-NS requests", which is mostly understandable since we no longer recommend that NS is used as the QTYPE for masking minimized requests. I don't know if it's worth retaining this warning in some form as it might apply to legacy implementations that retain the RFC 7816 behavior. Thanks to Donald Eastlake for the secdir review. I echo the intdir reviewer's question about where "strict mode" of QNAME minimization is defined. I also see the genart reviewer's question about whether the number of labels per iteration can remain large after the division, and I think that the maximum allowed length of a domain name helps some here, but would appreciate if someone more familiar with the actual limits ran the numbers and opined that the resulting number of labels is capped at some reasonable bound. Abstract If the note about the WG and git source is expected to be removed before publication as an RFC, it seems prudent to note that somewhere (whether in the visible prose or as a comment in the XML). Section 2.1 The QTYPE to use while minimising queries can be any possible data type (as defined in [RFC6895] Section 3.1) for which the authority always lies below the zone cut (i.e. not DS, NSEC, NSEC3, OPT, TSIG, TKEY, ANY, MAILA, MAILB, AXFR, and IXFR), as long as there is no relation between the incoming QTYPE and the selection of the QTYPE to use while minimising. [...] At risk of being overly pedantic, the procedure will still get you the right answer even if there is a relation between the incoming and selected QTYPE, so the "can be ... as long as" isn't quite correct. We insist on the lack of relationship because that gives better privacy properties, not because it is required for correct behavior, as I understand it. Section 3 (3) If CHILD is the same as QNAME, or if CHILD is one label shorter than QNAME and the original QTYPE can only be at the parent side (like QTYPE=DS), resolve the original query as normal starting from ANCESTOR's name servers. Start over from step 0 if new names need to be resolved as result of this answer, for example when the answer contains a CNAME or DNAME record. We might want to reference RFC 6672 for DNAME (since we use it later in step 6 as well). Section 6 the amount of data sent also, in part, addresses the case of a wire sniffer as well as the case of privacy invasion by the servers. Who are "the servers"? Section 7.1 It seems rather unconventional to make a normative reference to the document being obsoleted (RFC 7816). It seems like that document would be more appropriately classified as an informative reference. Section 7.2 Deferring to RFC 8499 for terminology definitions may well merit classifying it as a normative reference. NITS Thanks for putting the git repo link in the Abstract. Since I only have a proposed wording for one of these I didn't go through the effort of phrasing it in the form of a patch, but it's nice to have the option available. Section 3 (4) Otherwise, add the next relevant label or labels from QNAME to the start of CHILD. The number of labels to add is discussed in Section 2.3. It might be worth being a little more explicit that this is updating the current value of CHILD, as opposed to producing a new temporary value consisting of (next relevant label or labels)+CHILD. (E.g., "Update the value of CHILD to consist of [...]".) Sec
Re: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-iana-class-type-yang-03: (with COMMENT)
Hi Lada, On Fri, Jun 04, 2021 at 10:46:09AM +0200, Ladislav Lhotka wrote: > Hi Benjamin, > > thanks for the review, please see below. > > Benjamin Kaduk via Datatracker writes: > > ... > > > -- > > COMMENT: > > -- > > > > Like Roman, I applaud the use of XSLT to avoid specifying redundant > > information > > and allow for reasonably automated updates. Some other comments below. > > > > Section 3 > > > >The IANA document "Domain Name System (DNS) Parameters" > >[IANA-DNS-PARAMETERS] contains altogether thirteen registries. The > > > > I suggest "at the time of this writing" just in case we add or remove > > some registries. > > OK, added. > > > > > Section 4 > > > >Upon publication of this document, the initial revision of the "iana- > >dns-class-rr-type" YANG module SHALL be created by applying the XSLT > >stylesheet from Appendix A to the XML version of > >[IANA-DNS-PARAMETERS]. > > > > This is just a random observation from a bystander, but my understanding > > is that IANA is gradually moving registries to a database backend, so > > that the XML version may in some sense not be the "most authoritative" > > version (or the "preferred form for modification" to use the open-source > > software jargon). The XML format mand XSLT are both quite well-defined, > > and the database backend might not be, though, so it's not clear that > > moving to a procedure to generate YANG directly from the database would > > be an advantage over taking a detour via XML. > > That's why this document only deals with the initial revision of the module. > Whilst it is perfectly possible that IANA will use the stylesheet for > subsequent revisions, it is officially out of scope for this document. > > > > >"status": Include only if a class or type registration has been > > deprecated or obsoleted. In both cases, use the value "obsolete" > > as the argument of the "status" statement. > > > > I don't see any logic in the XSLT that looks for "deprecated", just > > "OBSOLETE". (This may be fine, given that there's not currently > > anything listed as deprecated in the live registry...) > > Right, the XSLT stylesheet is expected to work on those two registries in > their current state. The registry XML is loose in some respects and it is not > clear (to me at least) how a deprecated entry will exactly look like. It > would be certainly better to indicate the status e.g. with an XML attribute. > Searching for magic words like "OBSOLETE" in the entry text is brittle, but > it's currently the only way. Understood about the current way being brittle but nothing better being available (yet). My comment here was intended more along the lines of an apparent inconsistency between the text and the code -- the text says that we will set "status obsolete" if the registration is deprecated, but the XSLT doesn't do that. IMO it would be better to either drop the text about deprecated or add code to look for it (but this is just a non-blocking comment so my opinion doesn't count for too much). > > > > Section 5 > > > > The XSLT is only run over trusted input, so it is safe to ignore the > > risk of any issues due to improper escaping or input validation. > > Whether or not we need to note this property in the RFC is not entirely > > clear, though. > > I assume that the resulting YANG module will also be validated, e.g. with > pyang, so any unintentional translation errors should be discovered. I guess that gets a bit into Francesca's point about how involved the DEs or other parties will be when (new) output is generated. I don't think we need to say more in this subthread, though. > > > > Appendix A > > > >This appendix contains an XSLT 1.0 stylesheet [W3C.REC-xslt-19991116] > >that is intended to be used for generating the initial revision of > >the "iana-dns-class-rr-type" YANG module. This is achieved by > > > > Is this only going to be used for the initial revision, or for updates > > as well? > > As I wrote, the official target is only the initial revision. > > > > > > > > > This seems unused (and instead we have a lot of literals). > > Correct, I first used this variable but then r
[DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-iana-class-type-yang-03: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-iana-class-type-yang-03: 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/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-iana-class-type-yang/ -- COMMENT: -- Like Roman, I applaud the use of XSLT to avoid specifying redundant information and allow for reasonably automated updates. Some other comments below. Section 3 The IANA document "Domain Name System (DNS) Parameters" [IANA-DNS-PARAMETERS] contains altogether thirteen registries. The I suggest "at the time of this writing" just in case we add or remove some registries. Section 4 Upon publication of this document, the initial revision of the "iana- dns-class-rr-type" YANG module SHALL be created by applying the XSLT stylesheet from Appendix A to the XML version of [IANA-DNS-PARAMETERS]. This is just a random observation from a bystander, but my understanding is that IANA is gradually moving registries to a database backend, so that the XML version may in some sense not be the "most authoritative" version (or the "preferred form for modification" to use the open-source software jargon). The XML format mand XSLT are both quite well-defined, and the database backend might not be, though, so it's not clear that moving to a procedure to generate YANG directly from the database would be an advantage over taking a detour via XML. "status": Include only if a class or type registration has been deprecated or obsoleted. In both cases, use the value "obsolete" as the argument of the "status" statement. I don't see any logic in the XSLT that looks for "deprecated", just "OBSOLETE". (This may be fine, given that there's not currently anything listed as deprecated in the live registry...) Section 5 The XSLT is only run over trusted input, so it is safe to ignore the risk of any issues due to improper escaping or input validation. Whether or not we need to note this property in the RFC is not entirely clear, though. Appendix A This appendix contains an XSLT 1.0 stylesheet [W3C.REC-xslt-19991116] that is intended to be used for generating the initial revision of the "iana-dns-class-rr-type" YANG module. This is achieved by Is this only going to be used for the initial revision, or for updates as well? This seems unused (and instead we have a lot of literals). contact "Internet Assigned Numbers Authority The leading spaces seem a little out of place in the rendered output, to me. description "This YANG module translates IANA registries 'DNS CLASSes' and 'Resource Record (RR) TYPEs' to YANG derived types. [...] This initial version of this YANG module was generated from the corresponding IANA registries using a XSLT stylesheet Though I guess this part might not work well for a non-initial revision. "IANA 'Domain Name System (DNS) Parameters' registry https://www.iana.org/assignments/dns-parameters";; I may be missing something, but why two children of the ? Hardcoding the names "dns-parameters-2" and "dns-parameters-4" is in the class of things that (if I understand correctly) IANA is not always keen on people doing. In this case it's probably not a big issue, since the output of the transformation will be looked at by a human before it's published, and we can modify the template if needed, but I do wonder if any identifier more closely aligned to the registry's role is available. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-nsec-ttl-04: (with COMMENT)
Thanks, Job -- that looks better than anything I would have come up with! -Ben On Wed, May 19, 2021 at 01:10:27PM +0200, Job Snijders wrote: > On Wed, May 19, 2021 at 12:28:16PM +0200, Peter van Dijk wrote: > > > Section 3.1, etc. > > > > > > | The TTL of the NSEC RR that is returned MUST be the lesser of the > > > | MINIMUM field of the SOA record and the TTL of the SOA itself. > > > | This matches the definition of the TTL for negative responses in > > > | [RFC2308]. A signer MAY cause the TTL of the NSEC RR to have a > > > | deviating value after the SOA record has been updated, to allow > > > | for an incremental update of the NSEC chain. > > > > > > I don't think I understand what a "deviating value" would be (and in > > > which direction it would deviate). > > > > This sentence was added because some implementations may need time to > > rework the whole NSEC/NSEC3 chain after a TTL change. The deviation > > would be 'part of the chain still has the old, wrong, value - for a > > while'. I'll ponder better words - suggestions are very welcome, of > > course. > > Perhaps: > > Because some signers incrementally update the NSEC chain, a transient > inconsistency between the observed and expected TTL MAY exist. > > Kind regards, > > Job ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-nsec-ttl-04: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-nsec-ttl-04: 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/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-ttl/ -- COMMENT: -- I put a (small) handful of editorial suggestions up at https://github.com/PowerDNS/draft-dnsop-nsec-ttl/pull/11 . Section 3.1, etc. | The TTL of the NSEC RR that is returned MUST be the lesser of the | MINIMUM field of the SOA record and the TTL of the SOA itself. | This matches the definition of the TTL for negative responses in | [RFC2308]. A signer MAY cause the TTL of the NSEC RR to have a | deviating value after the SOA record has been updated, to allow | for an incremental update of the NSEC chain. I don't think I understand what a "deviating value" would be (and in which direction it would deviate). Section 3.4 | A resolver that supports aggressive use of NSEC and NSEC3 MAY | limit the TTL of NSEC and NSEC3 records to the lesser of the | SOA.MINIMUM field and the TTL of the SOA in a response, if | present. It MAY also use a previously cached SOA for a zone to | find these values. The original 8198 has "SHOULD reduce", but now we only have "MAY limit". Why should the requirements level be weaker for the new, more-correct, guidance? Section 4 If signers & DNS servers for a zone cannot immediately be updated to conform to this document, zone operators are encouraged to consider setting their SOA record TTL and the SOA MINIMUM field to the same value. That way, the TTL used for aggressive NSEC and NSEC3 use matches the SOA TTL for negative responses. Are there any negative consequences of such a move that would need to be weighed against the stated benefits? Section 8 Why is RFC 8174 only an informative reference? Shouldn't it be given the same treatment as RFC 2119? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Benjamin Kaduk's Yes on draft-ietf-dnsop-server-cookies-05: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-server-cookies-05: Yes 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/ -- COMMENT: -- Thank you very much for the updates in the -06; they are just what I was hoping for! I will note a couple nit-level editorial suggestions, though I am sure the RFC Editor would find them as well. Section 4 nit: s/Because DNS servers need to calculate/Because DNS servers need to recalculate it/ Section 8.2 nit: s/Portion of the structure/A portion of the structure/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-server-cookies-04: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-server-cookies-04: Discuss 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/ -- DISCUSS: -- The following points notwithstanding, I'm excited to see this mechanism get specified and am looking forward to balloting Yes once my concerns are resolved. Thank you for writing this document (and implementing it, etc.)! There seems to be an internal inconsistency in the normative guidance for how long a given cookie value should be accepted. Section 4.3 says that "[t]he DNS Server SHOULD allow Cookies within 1 hour period in the past and 5 minutes into the future to allow operation of low volume clients and some limited time skew between the DNS servers in the anycast set" (before going on to recommend that the server generates a new cookie if it receives one from the client that is more than half an hour old). In contrast, Section 5 says "[t]he operator SHOULD wait at least longer than the period clients are allowed to use the same Server Cookie, which SHOULD be half an hour, see Section 4.3". If I'm reading correctly the "1 hour" in Section 4.3 is supposed to line up with the "half an hour" in Section 5, but does not. Also, as was mentioned in the secdir review thread, I think we should clearly state what properties we require of a MAC in order to be a useful server cookie (including why the chosen inputs are the right thing to MAC!) That is, what message is being authenticated, and why is that a useful message to authenticate? I will also take this opportunity to consult the CFRG on the suitability of SipHash-2-4 for its stated purpose, though I do not feel a strong need to delay IESG approval of this document until a positive answer is received. -- COMMENT: -- Abstract This seems quite long for an Abstract! I suspect that everything after the first paragraph could be consolidated into a single second paragraph, if desired. Section 1 attackers. This document specifies a means of producing interoperable strong cookies so that an anycast server set including diverse implementations can be easily configured to interoperate with standard clients. While the need for a precise and interoperable specification is clear in this case of diverse implementations backing a single anycast service, isn't there also some benefit in having a well-studied algorithm even for use within a single implementation or non-anycast service? Section 3 While I recognize that (UDP) DNS packets do feel some need to economize on space, I also feel that we should consider what role the client cookie is playing as a nonce and how much randomness is needed in order for it to succeed in that role. In particular, in some sense it is *not* being used as a cryptographic nonce, but rather an ephemeral opaque identifier for a given client+IP address, that should be unguessable. Specifically, the client cookie can be used for more than one cryptographic operation, as it is re-used when the server generates a new "fresh" cookie. So I would suggest rewording to not call this a 'nonce'. That notwithstanding, my generic advice for random nonces is to use at least 128 bits if you want to not think about it much (https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.html apparently suggests 256-bit, though that's just a link I happened to see recently on some other list), and I feel that there is a need to include reasoning to justify the choice of any smaller nonce in terms of what properties the nonce needs to provide and how they are achieved within the target security margin. In this case (IIUC) we are a bit constrained by the size of the client cookie being a protocol constant, but we can still provide some analysis of what properties we are able to provide within that constraint. One way to track Client IP addresses, is to register the Client IP address alongside the Server Cookie when it receives the Server Cookie. In subsequent queries to the Server with that Server Cookie, nit/editorial: given the previous mention of "tracking" as being a bad thing done by external observers, the transition to this topic is a bit rough. I'd consider something like "
Re: [DNSOP] [secdir] Secdir last call review of draft-ietf-dnsop-server-cookies-04
Hi Ondřej, Thanks for this detailed writeup; it really helps bring clarity to the current situation. In light of the follow-ups from others, it seems that there are actually two distinct but somewhat entangled issues: (1) whether SipHash is a strong cryptographic hash function that delivers its stated properties. (2) whether the stated properties of SipHash are appropriate for the scenario we are using it for in this document. I had initially assumed that Stephen's review was asking about (2), but for the most part we tend to ask CFRG about things like (1). So, while I agree that it's valuable to get input from the CFRG on (1) and am willing to start the conversation there if needed, I would also like to get Stephen's (or anyone else's really) input about question (2). I suspect that we are okay in that regard, not least because of the other similar usage that you describe, but request that the analysis of what properties we need from a hash function for this use case (and that SipHash meets them) be included in a future version of the draft. Thanks again, Ben On Fri, Dec 04, 2020 at 10:14:29PM +0100, Ondřej Surý wrote: > Hi Benjamin, > > I did not used appeal to authority as an argument, but I’ve just provided > examples that SipHash has been implemented in the similar scenarios and there > hasn’t been reported issue with the choice for years now. > > Using fast PRF (pseudorandom function) for the DNS Cookies is a good choice > because it matches the required properties - it needs to be fast and secure > in a sense that attacker can’t compute neither the key nor the output of the > function. DNS Cookies are not MACs. > > Sorry for the misnomer of the brute force - what I meant was a protection > against a replay attack. I’m just currently very tired with day to day job. > > Please note that DNS Cookies doesn’t protect the actual DNS message payload, > it merely provide means to establish trust between the client and the server > as to distinguish between a legitimate and spoofed traffic, so different > policies can be used - Response Rate Limiting (RRL) could be turned off for > DNS messages with cookies or when under attack it could require fallback to > TCP for DNS queries without the DNS Cookie. The DNS cookies doesn’t protect > the actual content in any way, neither it does protect the communication from > the on path adversary. > > In that regard, the client cookie is just nonce (and it’s just convenient to > use same algorithm to generate it, but it could be output from CSPRNG as > well) and the server cookie is a cryptographic primitive that uses the client > nonce, key and timestamp to construct the server cookie. Such server cookie > is used by the DNS client to authenticate to the server (it’s shared secret, > but it requires no per-client state on the server). Just to repeat, the > actual payload (DNS message) is not protected by the DNS cookie. > > If the DNS server could keep a state for every DNS client, a CS random number > would be as good as the output of the SipHash. > > I might not be a cryptographer as my daily job, but I am reasonably confident > that SipHash has matching properties, it hasn’t been broken as of today. Also > all DNS vendors have agreed to make this choice and the RFC here is merely a > way how to ensure interoperability between various implementations. > > (Typing this on phone, so excuse any irregularities in the text.) > Ondrej > -- > Ondřej Surý — ISC (He/Him) > > > On 4. 12. 2020, at 21:37, Benjamin Kaduk wrote: > > > > Hi Ondřej, > > > > Just because someone else does something, even a "big name", doesn't > > necessarily make it a good idea for us to also do it. > > We should be able to justify our algorithm choices on cryptographic > > principles, not just appeal to authority. > > > > In a similar vein, you said something about the 32-bit timestamp being wide > > enough to prevent brute-force attacks. Could you say a bit more about what > > attacks those are that are being prevented? I'm not really seeing how the > > width of the timestamp comes into play for that concern, just from a quick > > skim of the document. (Timestamps tend to not provide much protection > > against brute force by themselves, since time is relatively guessable, > > especially to seconds precision.) > > > > Thanks, > > > > Ben > > > >> On Wed, Dec 02, 2020 at 11:18:29PM +0100, Ondřej Surý wrote: > >> SYN cookies in both Linux and FreeBSD uses siphash. > >> > >> * FreeBSD: https://svnweb.freebsd.org/base?view=revision&revision=253210 > >> (since 2013) > >> * Linux: > >> ht
Re: [DNSOP] [secdir] Secdir last call review of draft-ietf-dnsop-server-cookies-04
Hi Ondřej, Just because someone else does something, even a "big name", doesn't necessarily make it a good idea for us to also do it. We should be able to justify our algorithm choices on cryptographic principles, not just appeal to authority. In a similar vein, you said something about the 32-bit timestamp being wide enough to prevent brute-force attacks. Could you say a bit more about what attacks those are that are being prevented? I'm not really seeing how the width of the timestamp comes into play for that concern, just from a quick skim of the document. (Timestamps tend to not provide much protection against brute force by themselves, since time is relatively guessable, especially to seconds precision.) Thanks, Ben On Wed, Dec 02, 2020 at 11:18:29PM +0100, Ondřej Surý wrote: > SYN cookies in both Linux and FreeBSD uses siphash. > > * FreeBSD: https://svnweb.freebsd.org/base?view=revision&revision=253210 > (since 2013) > * Linux: > https://github.com/torvalds/linux/commit/fe62d05b295bde037fa324767674540907c89362#diff-14feef60c3dbcf67539f089de04546c907233cbae09e1b2dd2c2bc6d6eae4416 > (since 2017) > > I believe that the SYN cookies have exactly the same properties as DNS > cookies. > > Ondrej > -- > Ondřej Surý (He/Him) > ond...@isc.org > > > On 2. 12. 2020, at 22:15, Eric Rescorla wrote: > > > > Well hash tables are an application with somewhat different security > > properties than MACs, so I don't think this is dispositive. > > > > ___ > secdir mailing list > sec...@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Benjamin Kaduk's Yes on draft-ietf-dnsop-dns-zone-digest-13: (with COMMENT)
Hi Duane, Thanks -- this all sounds good (and it sounds like Rob is okay with the new thought for text about reporting, as well). Thanks again! -Ben On Mon, Oct 12, 2020 at 03:54:02PM +, Wessels, Duane wrote: > > > > On Oct 11, 2020, at 9:03 PM, Benjamin Kaduk via Datatracker > > wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-dnsop-dns-zone-digest-13: Yes > > > > > > -- > > COMMENT: > > -- > > > > Thanks for addressing my discuss (and comment!) points. There are still > > a few more threads to tidy up, but I'm happy with the direction we're > > going. > > > > Section 1 > > > > We (implicitly) mention "integrity" here as provided in the absence of > > DNSSEC, but later in Section 1.1 we say that integrity can only be assured > > when the zone is signed. I leave it to Roman to say when his discuss is > > resolved, but it seems likely that we should be consistent about which way > > we go with it. > > Looks like I missed that spot in when addressing Roman's point. Now changed > to this: > >It allows a receiver of the >zone to verify the zone's integrity and authenticity when used in >combination with DNSSEC. > > > > > Section 1.1 > > > > It's perhaps unusual to follow "the motivation for this protocol" with "a > > secondary motivation"; instead writing "the primary motivation" would reduce > > the surprise at seeing a secondary motivation added later. > > Agreed. This has been changed. > > > > > > Section 2.2.2 > > > > This change seems to be a regression? The value 1 in question is the > > scheme value, not a Hash Algorithm value. (I would make this a > > Discuss point but I am sure we will get it resolved quickly.) > > Oops, I changed that in the wrong place. Now it says "with Scheme value 1" > there > and "with Hash Algorithm value 1" in the next section. > > > > > > Section 3 > > > > (nit) Right now the literal reading of "identical" is that the ZONEMD and > > the signature and the denial-of-existence records are identical, which > > is of course nonsensical. Perhaps adding "to the ones produced by this > > procedure" or similar would reduce the stress for people who habitually > > make sentence diagrams. > > Changed to this: > >Implementations that deviate from the >described algorithm are advised to ensure that it produces ZONEMD >RRs, signatures, and dential-of-existence records that are identical >to the ones generated by this procedure. > > > > > Section 4 > > > > I can't tell if there's a duplicate line in the XML source or not, here > > (as an editing leftover), but that's my guess as to what happened. In > > particular, I'm not sure how one would query for a DS RR *in the anchor*. > > If I'm reading the previous thread correctly we were only proposing to talk > > about querying for (and validating) DS RRs in the parent zone, not the > > anchor (whatever that means). > > Yes indeed there was a line duplicated during editing. Now: > >This is done by examining locally >configured trust anchors, and, if necessary, querying for (and >validating) DS RRs in the parent zone. > > > > > Who is going to come to a conclusion on the "[ Maybe remove all the "SHOULD > > report" above and just say this:]"? (I'd be fine with it, for what little > > it's worth, but I don't think my opinion is anywhere close to the most > > relevant one.) > > Both you and Rob asked about this -- the possibility of overly verbose > reporting. > I'd like to hear Rob's opinion. > > DW > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)
On Fri, Oct 09, 2020 at 06:36:28PM +, Wessels, Duane wrote: > > > > On Oct 8, 2020, at 4:18 AM, Robert Wilton via Datatracker > > wrote: [...] > >2. The ZONEMD Resource Record > > > > It is > > RECOMMENDED that a zone include only one ZONEMD RR, unless the zone > > publisher is in the process of transitioning to a new Scheme or Hash > > Algorithm. > > > > I'm not quite sure how well this fits with sections 2.2.3 restriction that > > SHA384 MUST be implemented, and SHA512 SHOULD be implemented. As a > > recipient > > of the zone info I understand that I would need to implement both, but as a > > sender am I allowed to only send SHA512, or both, or must I always send > > SHA384? > > As sender (publisher) you are allowed to publish whatever you want. > > The purpose of the recommendation above is to hopefully avoid the situation > where multiple records are published (with both types) on an ongoing basis. > That is something we observe with DS records quite often. For example, > 750 TLDs today publish both SHA1 and SHA256 digest types as DS records in > the root zone. This new paragraph has been added to the security > considerations: > > 6.2. Use of Multiple ZONEMD Hash Algorithms > >When a zone publishes multiple ZONEMD RRs, the overall security is >only as good as the weakest hash algorithm in use. For this reason, >Section 2 recommends only publishing multiple ZONEMD RRs when >transitioning to a new scheme or hash algorithm. Once the transition >is complete, the old scheme or hash algorithm should be removed from >the ZONEMD RRSet. While I'm happy to see this statement made, I do want to note that the actual properties here have some complex interplay, and "only as good as the weakest hash algorithm in use" may only be strictly true in certain scennarios. (So, in the general case, it is a true statement, but there may be certain cases in which it does not hold.) In particular, since DNSSEC signs the whole RRset, it does not seem like it is possible (without some other attack) to modify things so that the ZONEMD with a different hash algorithm is not visible while retaining the RRSIG. And if you have a signed zone with a weak hash for ZONEMD, producing a different zone that collides the ZONEMD will probably not retain all the RRSIGS on the other records (though could plausibly retain most of them). So, it's complicated, but I'm not sure that we really need to get into the specifics in this document. Personally, I'm fine keeping this text as-is, but I did want to note the subtlety involved. -Ben ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)
On Sat, Oct 10, 2020 at 11:34:11AM -0400, John Levine wrote: > In article <20201010032517.gm89...@kduck.mit.edu> you write: > >There's two general classes of attack to consider: when an external > >attacker takes an existing ZONEMD and tries to modify the associated zone, > >or when the zone provider is the malicious entity that wants to provide > >different content to different people but give them the same digest value ... > > I think there's a third threat, a transcription error due to > transmission error or other kinds of bitrot. I send zone files between > my DNS servers over ssh, so the chances of an external attack are low, > but particularly as zone files continue to grow, the protection of the > TCP checksum is less effective. On my rather small DNS setup I have a > 71MB zone and I don't think that's unusual. In many, probably most, > cases a bit flip or two would produce DNS data that is still valid but > wrong, e.g., change the address in or the characters in a name > anywhere. At risk of being overly glib, "Murphy is often a very effective attacker". That is, the analysis for this decomposes into a subset of the first case I listed. -Ben > That's why there are situations where a zone digest can be useful > even without a DNSSEC validation chain. > > R's, > John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Benjamin Kaduk's Yes on draft-ietf-dnsop-dns-zone-digest-13: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-dns-zone-digest-13: Yes 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/ -- COMMENT: -- Thanks for addressing my discuss (and comment!) points. There are still a few more threads to tidy up, but I'm happy with the direction we're going. Section 1 We (implicitly) mention "integrity" here as provided in the absence of DNSSEC, but later in Section 1.1 we say that integrity can only be assured when the zone is signed. I leave it to Roman to say when his discuss is resolved, but it seems likely that we should be consistent about which way we go with it. Section 1.1 It's perhaps unusual to follow "the motivation for this protocol" with "a secondary motivation"; instead writing "the primary motivation" would reduce the surprise at seeing a secondary motivation added later. Section 2.2.2 This change seems to be a regression? The value 1 in question is the scheme value, not a Hash Algorithm value. (I would make this a Discuss point but I am sure we will get it resolved quickly.) Section 3 (nit) Right now the literal reading of "identical" is that the ZONEMD and the signature and the denial-of-existence records are identical, which is of course nonsensical. Perhaps adding "to the ones produced by this procedure" or similar would reduce the stress for people who habitually make sentence diagrams. Section 4 I can't tell if there's a duplicate line in the XML source or not, here (as an editing leftover), but that's my guess as to what happened. In particular, I'm not sure how one would query for a DS RR *in the anchor*. If I'm reading the previous thread correctly we were only proposing to talk about querying for (and validating) DS RRs in the parent zone, not the anchor (whatever that means). Who is going to come to a conclusion on the "[ Maybe remove all the "SHOULD report" above and just say this:]"? (I'd be fine with it, for what little it's worth, but I don't think my opinion is anywhere close to the most relevant one.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)
Hi Rob, One can do a bit of semi-generic analysis here to help motivate 12 bytes as being a tolerable choice (one could make some argument for 32 being the right length to actually use, but the protocol-mandated floor does not necessarilly need to be the "full protection" value as there can be trade-offs in play. There's two general classes of attack to consider: when an external attacker takes an existing ZONEMD and tries to modify the associated zone, or when the zone provider is the malicious entity that wants to provide different content to different people but give them the same digest value so that the cursory examination indicates the two different zones are identical. (The second one is going to be fairly contrived most of the time, and may not be in the practical threat model for most people.) In the former case the cryptographic property in play is second-preimage resistance which, in the absence of a quantum computer, scales as the bitlength of the output, so 12 bytes of digest means that for a good hash function the attacker has to put in a work factor of roughly 2**96, which is a substantial burden. The cryptographic property in play for the second case is regular collision resistance, which scales as the square root of the preimage problem due to the birthday paradox. A work factor of 2**48 is feasible but nontrivial, so 12 bytes poses some burden for both classes of attack and a substantial burden for the riskier attack. To me, that seems like a reasonable tradeoff for the bare minimum allowed by the protocol, though of course opinions can differ. -Ben On Fri, Oct 09, 2020 at 11:10:14PM -0400, Donald Eastlake wrote: > Hi Rob, > > I'm not aware of any precise analysis supporting the 12 byte minimum > size but I believe it is reasonable and in line with the lower end of > the range of hash sizes typically standardized by the IETF these days. > > Thanks, > Donald > === > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e...@gmail.com > > On Fri, Oct 9, 2020 at 5:23 AM Rob Wilton (rwilton) wrote: > > > > Hi Donald, > > > > > -Original Message- > > > From: Donald Eastlake > > > Sent: 09 October 2020 00:47 > > > To: Rob Wilton (rwilton) > > > Cc: The IESG ; draft-ietf-dnsop-dns-zone-dig...@ietf.org; > > > Tim Wicinski ; ; > > > dnsop-cha...@ietf.org > > > Subject: Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns- > > > zone-digest-12: (with COMMENT) > > > > > > On Thu, Oct 8, 2020 at 7:18 AM Robert Wilton via Datatracker > > > wrote: > > > > Robert Wilton has entered the following ballot position for > > > > draft-ietf-dnsop-dns-zone-digest-12: No Objection > > > > > > > > ... > > > > > > > > -- > > > > COMMENT: > > > > -- > > > > > > > > ... > > > > > > > > 2.2.4. The Digest Field > > > > > > > >The Digest field MUST NOT be shorter than 12 octets. Digests for > > > the > > > >SHA384 and SHA512 hash algorithms specified herein are never > > > >truncated. Digests for future hash algorithms MAY be truncated, > > > but > > > >MUST NOT be truncated to a length that results in less than 96- > > > bits > > > >(12 octets) of equivalent strength. > > > > > > > > When I read this, I wonder why the limit of 12 bytes was chosen. > > > Possibly a > > > > sentence that justifies why this value was chosen might be useful, > > > noting that > > > > the two suggested algorithms have significantly longer digests. > > > > > > To me, the purpose of the limit is to establish a minimum strength > > > against brute force attacks. Of course, the hash algorithm also has to > > > be strong but the length of the Digest field puts a sharp limit on the > > > strength of a ZONEMD. > > [RW] > > > > I absolutely agree on specifying a minimum value. My question is how was > > the minimum length of "12 bytes" chosen? Is there some analysis performed > > that indicates that this is the right minimal value, or is this just a "12 > > bytes sounds like enough"? > > > > Regards, > > Rob > > > > > > > > > > Note that for the same reason there is a similar provision from 2006 > > > in RFC 4635, Section 3.1, point 4, which sets a minimum size of 10 > > > bytes for the hashes that appear in TSIG RRs. > > > > > > Thanks, > > > Donald > > > === > > > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > > 2386 Panoramic Circle, Apopka, FL 32703 USA > > > d3e...@gmail.com > > > > > > > ... > > > > > > > > Regards, > > > > Rob > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-zone-digest-12: (with DISCUSS and COMMENT)
Hi Duane, On Wed, Oct 07, 2020 at 07:59:54PM +, Wessels, Duane wrote: > Hi Benjamin, thanks for the extensive review and comments. Responses are > inline. As you've noted some of this overlaps with Roman's comments as > well. > > > > On Oct 6, 2020, at 10:41 AM, Benjamin Kaduk via Datatracker > > wrote: > > > > -- > > DISCUSS: > > -- > > > > Inclusion of an "implementation requirement" column in the IANA > > registries implies a need for a defined procedure to make changes to > > existing registrations. With only a "specification required" procedure, > > it seems there would need to be a "change controller" column as well. > > Furthermore, is it expected that anyone with any specification could > > set, e.g., an implementation requirement of "MUST"? It seems like this > > attribute might be better left for the RFCs defining the protocol, to be > > modified by an updating RFC... > > To be honest, I feel like the "implementation requirement" column is a > bit of a can-of-worms. I have a hard time finding other IANA registries > that use it. Would it be better to omit this from the registry? In my opinion, yes! There's a pretty strong argument that changing implementation requirements is placing requirements on implementations with a similar level of authority to actual protocol changes, and thus that just having the implementation requirements in an RFC that gets updated as needed makes more sense. See, e.g., RFC 8247 (which obsoletes 4307) > If not, would it be sufficient to say something like "all specifications > requesting an allocation must have the implementation requirement set to > MAY unless being published on the standards track"? > > > > > > > If we are to retain the Implementation Status appendix in the final RFC, > > the boilerplate will need some changes, and I think those changes should > > get review prior to AUTH48. For example, "at the time of posting of > > this Internet-Draft" will make no sense in an RFC, and the relationship > > to RFC 7942 is not quite as clear given that we diverge from its > > recommendations. "[A]ssist the IETF in its decision process" does not > > seem to apply after the IETF has made its decision, though the > > disclaimer about endorsement seems highly important to retain. > > > Is this okay? > > RFC Editor: Please retain this section upon publication. > > This section records the status of known implementations of the > protocol defined by this specification, and is inspired by the We probably do want to keep something about "time of publication" (just not talk about Internet-Drafts). > concepts described in RFC7942. > > Please note that the listing of any individual implementation here > does not imply endorsement by the IETF. Furthermore, no effort has > been spent to verify the information presented here that was supplied > by IETF contributors. This is not intended as, and must not be > construed to be, a catalog of available implementations or their > features. Readers are advised to note that other implementations may > exist. But it seems otherwise unobjectionable to me. (Hopefully we can get some voices from the WG to chime in as well.) There is perhaps some question about whether it should get another IETF LC, but Barry and probably the rest of the IESG should be part of that conversation. > > > > > This seems to be related to Roman's Discuss point, but the document > > seems to be inconsistent as to the primary purpose of the mechanism -- > > Section 1.1 says that it is to verify "authenticity" of a stand-alone > > zone, whereas the Introduction implies that "integrity" is primary (with > > authenticity as an add-on "when used in combination with DNSSEC), and > > the Abstract refers to "accuracy and completeness". In particular, it > > is easy to read references to "integrity" (and, indeed, the Abstract > > itself) as referring to something akin to a transport checksum instead > > of a cryptographic message integrity code. I think the document needs > > to be much more clear, and consistent, about what properties it aims to > > provide. (I do not believe that the "authenticity" property can be > > provided without DNSSEC, and Roman covers the cryptographic integrity > > case in his ballot position.) > > Thanks for pointing this out. Here's some diff showi
[DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-zone-digest-12: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-dns-zone-digest-12: Discuss 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/ -- DISCUSS: -- Inclusion of an "implementation requirement" column in the IANA registries implies a need for a defined procedure to make changes to existing registrations. With only a "specification required" procedure, it seems there would need to be a "change controller" column as well. Furthermore, is it expected that anyone with any specification could set, e.g., an implementation requirement of "MUST"? It seems like this attribute might be better left for the RFCs defining the protocol, to be modified by an updating RFC... If we are to retain the Implementation Status appendix in the final RFC, the boilerplate will need some changes, and I think those changes should get review prior to AUTH48. For example, "at the time of posting of this Internet-Draft" will make no sense in an RFC, and the relationship to RFC 7942 is not quite as clear given that we diverge from its recommendations. "[A]ssist the IETF in its decision process" does not seem to apply after the IETF has made its decision, though the disclaimer about endorsement seems highly important to retain. This seems to be related to Roman's Discuss point, but the document seems to be inconsistent as to the primary purpose of the mechanism -- Section 1.1 says that it is to verify "authenticity" of a stand-alone zone, whereas the Introduction implies that "integrity" is primary (with authenticity as an add-on "when used in combination with DNSSEC), and the Abstract refers to "accuracy and completeness". In particular, it is easy to read references to "integrity" (and, indeed, the Abstract itself) as referring to something akin to a transport checksum instead of a cryptographic message integrity code. I think the document needs to be much more clear, and consistent, about what properties it aims to provide. (I do not believe that the "authenticity" property can be provided without DNSSEC, and Roman covers the cryptographic integrity case in his ballot position.) -- COMMENT: -- Section 1.2 The Transport Layer Security protocol suite also provides channel security. One can easily imagine the distribution of zones over HTTPS-enabled web servers, as well as DNS-over-HTTPS [RFC8484], and perhaps even a future version of DNS-over-TLS ([RFC7858]). I'm not sure I understand why a "future version" of DoT is needed -- while 7858 disclaims applicability outside of stub-to-recursive, is it know whether/what protocol changes would be needed, if any, to effectuate zone transfer? Section 1.2 been modified. Such modification could be the result of an accidental corruption of the file, or perhaps an incompletely saved file [disk-full-failure]. For these reasons, it is preferable to secure the data itself. "secure" is kind-of a catchall word; it would be better to use a more precise term if possible, perhaps "protect the integrity of". DNSSEC. Furthermore, zones that employ NSEC3 with opt-out are susceptible to the removal or addition of names between the signed nodes. Whereas DNSSEC is primarily protects consumers of DNS (nit) an RFC 5155 reference might be helpful here. Section 1.4.2 While I'm sure this is all true, I do wonder if there are any references available that go into more detail about the various possible setups and the problems that can arise with them. Section 1.4.3 RPZ is an individual draft that expired in 2018. Is the reference likely to have archival value? Secion 1.4.4 ICANN operates the Centralized Zone Data Service [CZDS], which is a repository of top-level domain zone files. Users that have been granted access are then able to download zone data. Adding a zone digest to these would provide CZDS users with assurances that the data has not been modified between origination and retrieval. ZONEMD could be added to CZDS zone data independently of the zone served by production name servers. I'm not entirely sure that I understand the relationship between the last two sentences.
[DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-extended-error-15: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-extended-error-15: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/ -- COMMENT: -- Thank you for addressing my Discuss point! It's probably worth a second look at the IANA considerations (see below), and I do have a few other comments. Section 1 Were you going to say something about EDE allowing stubs to stop after SERVFAIL-due-to-DNSSEC-bogus instead of continuing on to a non-validating resolver? Section 2 (I note that BCP 18 likes a language indicator, and "intended for human consumption" relies on humans to be language detectors, which is not always reliable.) Section 3 the truncation bit when dropping EDE options. Because long EXTRA- TEXT fields may trigger truncation, which is undesirable given the supplemental nature of EDE. Implementers and operators creating EDE options SHOULD avoid lengthy EXTRA-TEXT contents. I think this was intended to be one sentence, not two? Section 5.2 Are these two snippets consistent with each other? o 0 - 49151: First come, first served. o 49152 - 65280: Private use. [...] INFO-CODE: 25-65535 Purpose: Unasigned Reference: Section 5.2 Section 6 unauthenticated information. As such, EDE content should be treated only as diagnostic information and MUST NOT alter DNS protocol processing. Until all DNS answers are authenticated via DNSSEC or This looks an awful lot like the text Eric Orth didn't like when proposed in the secdir review thread. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-extended-error-14: (with DISCUSS and COMMENT)
On Thu, Apr 23, 2020 at 02:14:26PM -0400, Warren Kumari wrote: > On Thu, Apr 23, 2020 at 5:04 AM Vittorio Bertola > wrote: > > > > > > > > > Il 22/04/2020 19:15 Benjamin Kaduk via Datatracker ha > > > scritto: > > > > > > -- > > > DISCUSS: > > > -- > > > > > > Sections 4.16 and 4.17 have some discussion that suggests that the > > > respective extended errors apply only to the current "local hop" of a DNS > > > query, and thus should not be propagated by a resolver/forwarder as part > > > of > > > a response. If so, this would be at odds with the discussion in Section 3 > > > that leaves such bhavior as merely "implementation dependent" (giving some > > > MAY-level options). I'm not sure what the intent is, here, so let's talk > > > about whether there's anything that should change. > > > > Indeed, thinking at the possible use case for those error codes, it would > > make sense for the forwarder to forward them to the final user. Perhaps we > > can fix the language to make this clear? E.g., instead or "the server being > > directly talked to", "the server actually resolving the queries" or > > something like that? > > Hah! Wes and I spent some time yesterday trying to figure out how best > to answer this, and ended up with two ideas: > 1: just remove the "being directly talked to": > "The server is unable to respond to the request because the domain is > blacklisted due to an internal security policy imposed by the operator > of the server being directly talked to." -> "The server is unable to > respond to the request because the domain isblacklisted due to an > internal security policy imposed by the operator of the server" > or 2: some very convoluted text... > > In my view your proposed text is simple, clear, and addresses the issue... I think it would address my concern as well ... plus all that other stuff :) -Ben ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-extended-error-14: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-extended-error-14: Discuss 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/ -- DISCUSS: -- Sections 4.16 and 4.17 have some discussion that suggests that the respective extended errors apply only to the current "local hop" of a DNS query, and thus should not be propagated by a resolver/forwarder as part of a response. If so, this would be at odds with the discussion in Section 3 that leaves such bhavior as merely "implementation dependent" (giving some MAY-level options). I'm not sure what the intent is, here, so let's talk about whether there's anything that should change. -- COMMENT: -- Section 4.16 The server is unable to respond to the request because the domain is blacklisted due to an internal security policy imposed by the operator of the server being directly talked to. This wording implies that code 15 MUST NOT be copied by a resolver/forwarder, which is somewhat at odds with Section 3. Section 4.17 The server is unable to respond to the request because the domain is blacklisted by a security policy imposed upon the server being talked to by an external requirement. Note that how the imposed policy is [ditto] COMMENT The RFC Editor is going to have to look closely at a lot of commas, but I'll try to not dwell too much on them here. I will note that "i.e." and "e.g." are to be offset from other text both before and after, whether by comma, parenthesis, dash, or other punctuation. Section 1 A good example of issues that would benefit by additional error information are errors caused by DNSSEC validation issues. When a stub resolver queries a name which is DNSSEC bogus (using a I know that "DNSSEC bogus" is a term of art, but not everyone will. Would a reference to RFC 8499 somewhere in here be worthwhile? option is to ask the next configured DNS resolver. The result of trying the next resolver is one of two outcomes: either the next resolver also validates, and a SERVFAIL is returned again or the next resolver is not a validating resolver, and the user is returned a potentially harmful result. With an Extended DNS Error (EDE) option nit: some puncuation before "or the next resolver is also", please. Some combinations of extended error codes and RCODEs may seem nonsensical (such as resolver-specific extended error codes in responses from authoritative servers), so systems interpreting the extended error codes MUST NOT assume that a combination will make sense. [...] It's not really clear what actionable guidance there is in "MUST NOT assume that [...] will make sense". Section 1.1 Please use the current BCP 14 boilerplate from RFC 8174. Section 2 message. The INFO-CODE serves as an index into the "Extended DNS Errors" registry Section 5.1. nit: maybe "registry defined in"? o EXTRA-TEXT, a variable length, UTF-8 encoded, text field that may hold additional textual information. Note: EXTRA-TEXT may be zero octets in length, indicating there is no EXTRA-TEXT included. Care should be taken not to leak private information that an observer would not otherwise have access to, such as account numbers. What's the internationalization plan for EXTRA-TEXT? (See BCP 18.) (Also, I'm apparently not imaginative enough to come up with a case where an account number would be in an error message, so I am glad that you thought of it and included it!) Section 3 supplemental nature of EDE. Implementers and operators creating EDE options SHOULD avoid setting unnecessarily long EXTRA-TEXT contents to avoid truncation. nit(?): "SHOULD avoid setting unnecessarily long" is not clearly actionable; perhaps "should be mindful of such potential consequences of long EXTRA-TEXT contents when generating EDE information" is better? When a resolver or forwarder receives an EDE option, whether or not (and how) to pass along EDE information on to their original client is implementation dependent. Implementations MAY choose to not forward information, or they MAY choose to create a new E
Re: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-multi-provider-dnssec-04: (with COMMENT)
Hi Shumon, On Thu, Apr 09, 2020 at 11:44:30AM -0400, Shumon Huque wrote: > On Thu, Apr 9, 2020 at 1:09 AM Benjamin Kaduk via Datatracker < > nore...@ietf.org> wrote: > > > > > Thanks for this document; it's pretty clear and it's good to have these > > procedures written down in a well-thought-out manner. > > > > Thank you for your review Ben. > > Section 3 > > > >o It may also be the case that a resolver is unable to provide an > > authenticated response because it gave up after a certain number > > of retries or a certain amount of delay. Or that downstream > > clients of the resolver that originated the query timed out > > waiting for a response. > > > > nit: sentence fragment. > > > > Ok, will fix. > > > > > > Section 5 > > > >Since authenticated denial responses are self-contained, NSEC and > >NSEC3 can be used by different providers to serve the same zone. > >Doing so however defeats the protection against zone enumeration > >provided by NSEC3. A better configuration involves multiple > > > > It might be worth a few more words about why this defeats the protection > > against zone enumeration. > > > > Sure (the short summary is that the adversary can just trivially enumerate > the zone by querying the provider that employs NSEC). Will add some text. Oh! I was misreading this sentence -- I thought that the loss of protection was due to mixing NSEC and NSEC3 and some sort of cross-protocol interaction, but of course this is just the inherent property of any use of NSEC. So maybe s/Doing so/Any use of NSEC/? > Section 6.1, 6.2 > > > > Should we say anything about when it's safe for a new ZSK to be used to > > sign responses? > > > > I think we were largely leaving these timing details to other documents > like RFC 6781, which we assume readers will be familiar with. > > But since we describe pre-publish ZSK rollovers in some detail, we can > probably say something. Per 6781, you need to wait (1) propagation delay > of the ZSK update to all authoritative servers, plus (2) the TTL of the > DNSKEY > RRset. The only aspect that _may_ need to be highlighted, is that for multi > provider, propagation delay now includes the time to propagate to authority > servers of _all_ the providers (which now necessarily includes the > associated > ZSK import operations). > > Section 8 > > > > nit: s/CDNS/CDS/ > > > > Yup, thanks for catching that. There's actually an additional typo there. > So, we need to > replace "CDNS/DNSKEY" with "CDS/CDNSKEY". > > Also, this section feels a bit sparse compared to 6.1 and 6.2. > > > > Okay, let me ponder what might be useful to elaborate on here .. > > Section 9 > > > >In model 2, once initially bootstrapped with each others zone signing > >keys via these API mechanisms, providers could, if desired, > >periodically query each others DNSKEY RRsets and automatically import > >or withdraw ZSKs in the keyset as key rollover events happen. > > > > What kind of authentication would be needed for this > > provider-to-provider API access? > > > > Post bootstrapping (i.e. after the providers were already deployed in a > multi-signer configuration), I don't think there any new authentication > mechanisms needed, since the DNSKEY RRset is already signed and > can be verified by anyone to confirm updated ZSK elements. So, they > could securely discover this using the DNS protocol (rather than vendor > proprietary APIs). > > Section 10 > > > > Shouldn't we have references for DoT and DoH? > > > > Hmm, okay. This was almost a parenthetical comment about a possible > future state of the DNS ecosystem, so it didn't immediately occur to me > add references. But sure, we can add them. > > Section 12 > > > > I think both import and export need to be strongly authenticated, though > > the DNSSEC itself can provide for authentication of export in most > > (all?) cases. If (e.g.) the zone owner fetches bad data and then > > strongly authenticates to shove that bad data into the other services, > > you still end up with bad data in use. > > > > > (Also, integrity protection, though I expect this is implicit.) > > Yes, DNSSEC could be used in many cases, post bootstrapping. But I > expect the zone owner will be using provider API for both export and > import. These are almost always REST/HTTPS so they are strongly > authenticated, and yes integrity protected (and confident
[DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-multi-provider-dnssec-04: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-multi-provider-dnssec-04: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-multi-provider-dnssec/ -- COMMENT: -- Thanks for this document; it's pretty clear and it's good to have these procedures written down in a well-thought-out manner. Section 3 o It may also be the case that a resolver is unable to provide an authenticated response because it gave up after a certain number of retries or a certain amount of delay. Or that downstream clients of the resolver that originated the query timed out waiting for a response. nit: sentence fragment. Section 5 Since authenticated denial responses are self-contained, NSEC and NSEC3 can be used by different providers to serve the same zone. Doing so however defeats the protection against zone enumeration provided by NSEC3. A better configuration involves multiple It might be worth a few more words about why this defeats the protection against zone enumeration. Section 6.1, 6.2 Should we say anything about when it's safe for a new ZSK to be used to sign responses? Section 8 nit: s/CDNS/CDS/ Also, this section feels a bit sparse compared to 6.1 and 6.2. Section 9 In model 2, once initially bootstrapped with each others zone signing keys via these API mechanisms, providers could, if desired, periodically query each others DNSKEY RRsets and automatically import or withdraw ZSKs in the keyset as key rollover events happen. What kind of authentication would be needed for this provider-to-provider API access? Section 10 Shouldn't we have references for DoT and DoH? Section 12 I think both import and export need to be strongly authenticated, though the DNSSEC itself can provide for authentication of export in most (all?) cases. If (e.g.) the zone owner fetches bad data and then strongly authenticates to shove that bad data into the other services, you still end up with bad data in use. (Also, integrity protection, though I expect this is implicit.) This is the sort of operation that I'd want to have multi-factor authentication for, too. Section 14.1 RFCs 2136, 5731 don't currently seem to be cited in a manner that requires a normative reference. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-no-response-issue-19: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-no-response-issue-19: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/ -- COMMENT: -- Someone (maybe the RFC Editor) will end up tweaking a lot of commas. I didn't try to list them all. I didn't see a response to the secdir reviewer's question (though I'm also not sure that there's an easy answer to it). Section 1 The existence of servers which fail to respond to queries results in developers being hesitant to deploy new standards. Such servers need nit: it feels a little like a juxtaposition to have "developers" that "deploy" new standards (vs. "developers that implement" or "operators that deploy"). indication that the server is under attack. Parent zone operators are advised to regularly check that the delegating NS records are consistent with those of the delegated zone and to correct them when they are not [RFC1034]. Doing this regularly should reduce the instances of broken delegations. I can't tell if this 1034 reference is for the recommendation to regularly check or the definition of "consistent" or something else; if the recommendation is new, then would BCP 14 keywords be appropriate? Section 2 o The AD flag bit in a response cannot be trusted to mean anything as some servers incorrectly copy the flag bit from the request to the response [RFC1035], [RFC4035]. Would it be worth a 6840 ref here as well (to catch setting AD in a request, even though that's not exactly what's being mentioned)? Section 3.1.2 (Do we want to remind the reader on the NOERROR vs. NXDOMAIN rules? "No" is probably acceptable. I see we do so later, in Section 7, so even a forward reference might suffice.) Where's the first reference/mention of Meta-RRs? I see RFC 2929 (obsoleted, transitively, by 6895) that we cite for the "range reserved for private use" but not for terminology. Even RFC 8499 (which we don't cite) only has "meta-RR" in a parenthetical in the description of OPT. Section 3.1.5 micro-nit: I guess firewalls don't exactly count as "nameservers", which seems to be the claimed scope for this document. Section 3.2.1 This section threw me a bit, at first, as the 3.1.x had led me to expect "nameservers should behave in this way", but this section is "here is how to tell if a nameserver is misbehaving". That's not necessarily a problem, just a ... comment :) Section 3.2.6 Some nameservers fail to copy the DO bit to the response despite clearly supporting DNSSEC by returning an RRSIG records to EDNS queries with DO=1. I'm not sure if we also want an explicit "nameservers should copy to the DO bit to the response when they support DNSSEC". Section 3.2.7 [similarly an affirmative statement of what nameservers should do might be appropriate here.] Section 4 Firewalls and load balancers can affect the externally visible behaviour of a nameserver. Tests for conformance should to be done from outside of any firewall so that the system is tested as a whole. (These are conformance tests run by the nameserver's own operator, or externally-driven tests, too?) However, there may be times when a nameserver mishandles messages with a particular flag, EDNS option, EDNS version field, opcode, type or class field or combination thereof to the point where the integrity of the nameserver is compromised. Firewalls should offer the ability to selectively reject messages using an appropriately constructed response based on all these fields while awaiting a fix from the nameserver vendor. I would suggest reiterating that this is "with a response" vs. "drop the packet silently". Section 5 Ideally, Operators should run these tests against a packet scrubbing service to ensure that these tests are not seen as attack vectors. It feels like maybe the most we can say here is "not seen as attack vectors during normal operation". We can't exclude the possibility that some actor decides to generate a flood of messages that happens to match the test behavior (whether by accident or design), which seems fairly likely to lead to blocking of the test-behavior traffic as collateral damage.
[DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-rfc2845bis-07: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-rfc2845bis-07: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc2845bis/ -- COMMENT: -- Thanks for putting together this update; it's good to see the security issue getting closed off in the udpated spec, and progression to full Internet Standard! I do have several substantive comments (as well as some minor/nit-level ones), many of which are listed here at the top but a few of which are interspersed in the per-section comments. I considered making this a Discuss point, but it should be pretty uncontroversial and I trust that the right thing will happen even if I don't: there's a couple lingering remnants of SHA-1 being the preferred algorithm that need to be cleaned up, in Sections 5.2.2.1 and 10 (further detailed in the per-section comments). I also initially had made the following point a Discuss-level point, but decided to not do so since I don't remember any BCP-level guidance relating to cross-protocol attacks. Nevertheless, I strongly encourage the authors to consider that cryptographic best practice is to use any given key with exactly one cryptographic algorithm. The record format listed in Section 4.2 has the key name and algorithm as separately conveyed, which would allow for a given key to be used with all implemented algorithms. We should include some discussion that it's best to only use a single algorithm with any given key. We also have a 16-bit wide field for "Fudge", which (since it counts seconds) corresponds to a maximum window of something like +/- 18 hours; it's hard to believe that we really want to give people the rope to allow for that much time skew. (Yes, I understand that implementations will set something sane in practice but that doesn't necessarily mean that the protocol still has to allow it.) Our authoritative list of algorithm names (Table 1) is rather divorced from the references to be consulted for the individual hash algorithms to be used with the HMAC procedure. The ones used here are sufficiently well-known that I'm not terribly concerned about it, though. Abstract The title says "DNS" but maybe the body of the abstract should as well? Section 1.1 Some of this language feels like it might not age terribly well, e.g., "this can provide" or "[t]here was a need". addresses that need. The proposal is unsuitable for general server to server authentication for servers which speak with many other servers, since key management would become unwieldy with the number of shared keys going up quadratically. But it is suitable for many resolvers on hosts that only talk to a few recursive servers. Should zone transfers be mentioned here as well? Section 1.2 I don't understand the motivation for changing terminology from MACs to "signatures"; they're still MACs even though they're transaction-based. MAC of the query as part of the calculation. Where a response comprises multiple packets, the calculation of the MAC associated with the second and subsequent packets includes in its inputs the MAC for the preceding packet. In this way it is possible to detect any interruption in the packet sequence. I suggest mentioning the lack of mechanism to detect truncation of the packet sequence. Section 4.2 NAME The name of the key used, in domain name syntax. The name should reflect the names of the hosts and uniquely identify the key among a set of keys these two hosts may share at any given time. For example, if hosts A.site.example and B.example.net share a key, possibilities for the key name include .A.site.example, .B.example.net, and .A.site.example.B.example.net. It should be possible for more than one key to be in simultaneous use among a set of interacting hosts. I'd suggest adding a note along the lines of "This allows for periodic key rotation per best operational practices, as well as algorithm agility as indicated by [BCP201]." The name may be used as a local index to the key involved and it is recommended that it be globally unique. Where a key is (nit?): this feels more like a "but" than an "and", to me. * MAC Size - an unsigned 16-bit integer giving the length
[DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-7706bis-10: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-7706bis-10: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-7706bis/ -- COMMENT: -- Abstract Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server; those resolvers may have difficulty getting responses from the root servers, such as during a network attack. Some DNS recursive resolver operators want to prevent snooping by third parties of requests sent to DNS root servers. Such resolvers can greatly decrease the round-trip time and Can I suggest to s/Such resolvers/In both cases, resolvers/? Section 1 The primary goals of this design are to provide more reliable answers for queries to the root zone during network attacks, and to prevent queries and responses from being visible on the network. This design will probably have little effect on getting faster responses to stub resolver for good queries on TLDs, because the TTL for most TLDs is usually long-lived (on the order of a day or two) and is thus usually already in the cache of the recursive resolver; the same is true for the TTL for negative answers from the root servers. (Although the primary goal of the design is for serving the root zone, the method can be used for any zone.) Are there any considerations of note when using this method for a zone other than the root zone? Section 1.1 (I expect the RFC Editor will change things to use a consistent construction for the last five paragraphs, regarding "this document " vs. just "".) Section 2 only respond to queries from the same host. One way to assure not responding to queries from other hosts is to run an authoritative server for the root that responds only on one of the loopback addresses (that is, an address in the range 127/8 for IPv4 or ::1 nit(?): in principle there's nothing to stop such a service from responding on more than one loopback address ... not that I can think of a reason why one would want to. Section 3 There is a risk that a system using a local authoritative server for the root zone cannot refresh the contents of the root zone before the expire time in the SOA. A system using a local authoritative server for the root zone MUST NOT serve stale data for the root zone. To mitigate the risk that stale data is served, the local root server MUST immediately switch to using non-local root servers. Immediately ... upon what condition? Section 4 We should probably discuss the consequences for when the SHOULD NOT is ignored and the glue records in the root zone are changed. As stated in Section 1, this design explicitly allows the local copy of the root zone information to be available only from resolvers on that host. This has the security property of limiting damage to nit: "allows [...] to be available only from" or "requires [...] to be available only from"? (Or "only allows [...] to be available from", of course.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)
On Thu, Dec 05, 2019 at 02:59:16PM -0500, Dave Lawrence wrote: > Thank you very much for your review, Ben. > > Benjamin Kaduk via Datatracker writes: > >For a comprehensive treatment of DNS terms, please see [RFC8499]. > > > > (side note: I myself would not use the word "comprehensive" when it > > explicitly says that "some DNS-related terms are interpreted quite > > differently by different DNS experts", but I understand why it is used > > here.) > > Would "For a glossary of ..." work better? Slightly simpler text then too. Indeed it would! And now I feel better about making you read a "side note" that I didn't expect to change anything... > >There are a number of reasons why an authoritative server may become > >unreachable, including Denial of Service (DoS) attacks, network > >issues, and so on. If a recursive server is unable to contact the > >authoritative servers for a query but still has relevant data that > > > > side note: the way this is worded might make a reader wonder if the > > recursive is expected to attempt to contact all known authoritatives > > before declaring failure. > > It's slightly complicated but I'd say "expected to" is yes in the > general sense of it but the devil is in the details. Most > implementations basically do try all authorities of the set their > working with, but also have safeguards for getting bogged down, like > what is later described as the query resolution timer. This keeps > them from being tarpitted on an NS RRset that provides many > authorities that all have some sort of aberrant behavior, whether that > be unreachability or super slow TCP or whatever. This isn't just > theoretical either, but observed in the wild. > > Based on that I'd be reluctant to add either "all" into there, or to > fully describe the situation. Understood, and that's why it was a "side note" :) (I was mostly not sure about the scope of "the set they're working with", not that that matters.) > >Several recursive resolver operators, including Akamai, currently use > >stale data for answers in some way. A number of recursive resolver > > > > I did not follow the discussions that led to this wording, but one of my > > colleagues at Akamai suggested that "currently fall back to stale data > > for answers under some circumstances" might be a nicer wording, though I > > note that Adam has already proposed some text here as well, which is > > probably fine. > > Per Adam's review I'd already stricken the mention of Akamai's > operations here. In the earliest versions of the draft it kind of fit > in more naturally as being one member of a set of other explicitly > named providers, but the latter were implementations rather than > specific operations and subsequent edits separated them out. > Ultimately the call-out to a specific operator (and in particular, the > one I worked for at the time) was more meaningful background when > the draft was first introduced than is necessary to have in there now. > > > I recommend using "[this document]" in the section references, since a > > reader reading the updated content in the context of RFC 1035 might look > > there instead of here. > > Yes, I had also updated this per Adam's review to have the RFC Editor > adjust accordingly. > > > side note: I'm slightly surprised that the semantics of the absence of > > Recusion Desired are not more tightly nailed down, but neither is it the > > role of this document to specify them. > > We're barely scratching the surface about what might surprise you that > isn't more tightly nailed down in the DNS. Did I ever tell you about > that time in DoH where we argued for metaphorical days over what TC > really means? I'll have to ask you about that in Vancouver. (Over beer.) > >When no authorities are able to be reached during a resolution > >attempt, the resolver should attempt to refresh the delegation and > >restart the iterative lookup process with the remaining time on the > >query resolution timer. This resumption should be done only once > >during one resolution effort. > > > > Is the "during one" more like a global cap or more like "during a > > given"? > > I confess I don't quite understand the distinction you're drawing, so > perhaps a concrete example helps. The idea to be communicated is that > if you're trying to resolve foo.example.com but your current NS RRSET > for example.com are
[DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-serve-stale-09: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/ -- COMMENT: -- Thanks for this document; it's some good comprehensive discussion of the issues related to this topic and will improve the stability of the internet. I have several minor coments and a few side notes that are expected to lead to at most my own elucidiation (but no textual changes). Section 2 For a comprehensive treatment of DNS terms, please see [RFC8499]. (side note: I myself would not use the word "comprehensive" when it explicitly says that "some DNS-related terms are interpreted quite differently by different DNS experts", but I understand why it is used here.) Section 3 There are a number of reasons why an authoritative server may become unreachable, including Denial of Service (DoS) attacks, network issues, and so on. If a recursive server is unable to contact the authoritative servers for a query but still has relevant data that side note: the way this is worded might make a reader wonder if the recursive is expected to attempt to contact all known authoritatives before declaring failure. Several recursive resolver operators, including Akamai, currently use stale data for answers in some way. A number of recursive resolver I did not follow the discussions that led to this wording, but one of my colleagues at Akamai suggested that "currently fall back to stale data for answers under some circumstances" might be a nicer wording, though I note that Adam has already proposed some text here as well, which is probably fine. Section 4 The definition of TTL in [RFC1035] Sections 3.2.1 and 4.1.3 is amended to read: TTL a 32-bit unsigned integer number of seconds that specifies the duration that the resource record MAY be cached before the source of the information MUST again be consulted. Zero values are interpreted to mean that the RR can only be used for the transaction in progress, and should not be cached. Values SHOULD be capped on the orders of days to weeks, with a recommended cap of 604,800 seconds (seven days). If the data is unable to be authoritatively refreshed when the TTL expires, the record MAY be used as though it is unexpired. See the Section 5 and Section 6 sections for details. I recommend using "[this document]" in the section references, since a reader reading the updated content in the context of RFC 1035 might look there instead of here. Section 5 The resolver then checks its cache for any unexpired records that satisfy the request and returns them if available. If it finds no relevant unexpired data and the Recursion Desired flag is not set in the request, it should immediately return the response without consulting the cache for expired records. Typically this response would be a referral to authoritative nameservers covering the zone, but the specifics are implementation-dependent. side note: I'm slightly surprised that the semantics of the absence of Recusion Desired are not more tightly nailed down, but neither is it the role of this document to specify them. When no authorities are able to be reached during a resolution attempt, the resolver should attempt to refresh the delegation and restart the iterative lookup process with the remaining time on the query resolution timer. This resumption should be done only once during one resolution effort. Is the "during one" more like a global cap or more like "during a given"? Section 6 The client response timer is another variable which deserves consideration. If this value is too short, there exists the risk that stale answers may be used even when the authoritative server is actually reachable but slow; this may result in sub-optimal answers being returned. Conversely, waiting too long will negatively impact user experience. Not just sub-optimal but potentially even wrong or actively harmful answers, no? The balance for the failure recheck timer is responsiveness in detecting the renewed availability of authorities versus the extra resource use for resolution. If this variable is set too large, stale answers may continue to be returned even after the authoritative server is reachable;
Re: [DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)
On Tue, Dec 03, 2019 at 03:50:43PM -0800, Roman Danyliw via Datatracker wrote: > > -- > COMMENT: > -- > > * I agree with Mirja, Section 8 is more informative than what is alluded to > the > paragraph starting with “Several recursive resolvers …” in Section 3, and IMO > is worth keeping. I struck me as odd to call out the operation practice of a > particular vendor (Akamai). We might want to check if this reference is ok – > Ben? To some extent the operational practices of operators equate to implementation status, for those that develop/run their own implementations. So I wasn't particularly struck by the text in Section 8 -- I was more struck by the text in Section 3 that left the "some way" rather vague, and had opened an internal discussion about it (as-yet unresolved). But Adam's proposal to drop the vendor name entirely is likely to be satisfactory. -Ben ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-09.txt
Hi Brian, I agree that this updated text provides more clarity about why the change is being made, but I am not sure that it fully addresses all of the concerns you raised, and would appreciate your thoughts. Specifically, you had raised the possibility of existing, fielded, implementations that would behave poorly when presented with input that has the sign bit set. The DNS-OARC data that indicates such packets have not been seen in the wild serves only to amplify this uncertainty, since we have no reason to believe that such a codepath would have been triggered already and diagnosed. Isn't there still some latent risk of such fielded implementations that would be incompatible with this change if it ever did show up on the wire? Thanks, Ben On Fri, Oct 25, 2019 at 11:23:42AM +1300, Brian E Carpenter wrote: > Hi Dave, > > Thanks. I think that covers it. I still suspect that the original reason > was concern about int versus uint confusion, but the new text is fine. > > Regards >Brian Carpenter > > On 25-Oct-19 08:35, Dave Lawrence wrote: > > internet-dra...@ietf.org writes: > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-serve-stale-09 > > > > This revision addressed the one remaining outstanding issue that Brian > > Carpenter raised in the Gen-ART Last Call Review. The following text > > was added to explain why a TTL with the high-order bit set is now > > handles as a large positive number (then capped down) rather than a > > negative number (and treated as zero). > > > > As for the change to treat a TTL with the high-order bit set as > > positive and then clamping it, as opposed to [RFC2181] treating it as > > zero, the rationale here is basically one of engineering simplicity > > versus an inconsequential operational history. Negative TTLs had no > > rational intentional meaning that wouldn't have been satisfied by just > > sending 0 instead, and similarly there was realistically no practical > > purpose for sending TTLs of 2^25 seconds (1 year) or more. There's > > also no record of TTLs in the wild having the most significant bit set > > in DNS-OARC's "Day in the Life" samples. With no apparent reason for > > operators to use them intentionally, that leaves either errors or > > non-standard experiments as explanations as to why such TTLs might be > > encountered, with neither providing an obviously compelling reason as > > to why having the leading bit set should be treated differently from > > having any of the next eleven bits set and then capped per Section 4. > > > > I also removed the phrasing about 2181's handling of this issue as a > > "curious suggestion". I recognize it could have an unintended > > negative connotation against the original authors, though when I wrote > > the sentence originally I meant it only with its neutral denotation. > > It was curious to me only because no rationale was provided as to why > > that particular choice had been made, despite the current assertion > > that it was obvious as to why. > > > > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-algorithm-update-07: (with COMMENT)
On Thu, Apr 11, 2019 at 12:20:21PM -0400, Warren Kumari wrote: > [ - IESG (for clutter), Bob & Tim (through DNSOP / Chairs respectively) ] > > > On Tue, Apr 9, 2019 at 7:55 AM Paul Wouters wrote: > > > On Fri, 5 Apr 2019, Bob Harold wrote: > > > > [ SNIP ] > > > > > In a similar vein, if we stay at PS, a lot of the references seem > > like > > > they would need to move from Informative to Normative, since to > > > implement the various MUST-level algorithms you have to follow > > those > > > references. > > > > I would not say those references are normative in that sense. You don't > > HAVE to read how GOST is specified to not implement it. > > > > > Perhaps, but there are still lots of Informative references which > implementers would need to read. For example: > > RFC5702, RFC6605: > 8 RSA/SHA-256 RSASHA256 Y * [RFC5702] > 10 RSA/SHA-512 RSASHA512 Y * [RFC5702] > 13 ECDSA Curve P-256 with SHA-256 ECDSAP256SHA256 Y * [RFC6605] > > RFC4509: > 2 SHA-256 MANDATORY [RFC4509] > > It is a simple matter to make these Normative I'll also note (sic) that note 1 at https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/ says: Even references that are relevant only for optional features must be classified as normative if they meet the above conditions for normative references. -Ben ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-algorithm-update-07: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-algorithm-update-07: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/ -- COMMENT: -- I'm a little surprised that this is going for PS rather than BCP, which seems like it would reflect the recognized need for recurring updates to the guidance given. In a similar vein, if we stay at PS, a lot of the references seem like they would need to move from Informative to Normative, since to implement the various MUST-level algorithms you have to follow those references. Section 1.1 The field of cryptography evolves continuously. New stronger algorithms appear and existing algorithms are found to be less secure then originally thought. [...] I'd suggest also noting that attacks previously thought to be computationally infeasible become more accessible as the available computational resources increase. Section 1.2 For clarification and consistency, an algorithm will be specified as MAY in this document only when it has been downgraded. Does "downgraded" mean that it was formerly mandatory but has been rotated out of the mandatory role? Perhaps explicitly saying "downgraded from " would aid clarity. Section 3.3 SHA-384 shares the same properties as SHA-256, but offers a modest security advantage over SHA-384 (384-bits of strength versus nit: SHA-384 has an advantage over ... SHA-384? recommended for DS and CDS records. While it is unlikely for a DNSSEC use case requiring 384-bit security strength to arise, SHA-384 is provided for such applications and it MAY be used for generating DS and CDS records in these cases. My understanding is that generally we refer to SHA-384 as providing 192-bit security, though of course that's a vague/generic statement and more specific ones are possible. Section 8 We wish to thank Michael Sinatra, Roland van Rijswijk-Deij, Olafur Gudmundsson, Paul Hoffman and Evan Hunt for their imminent feedback. IIRC a directorate reviewer noted that "imminent" means "expected to arrive in the near future but not yet present"; such text does not seem appropriate for final publication since review after that point would not be helpful. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Favor: Weigh in on draft-ietf-ipsecme-split-dns?
On Sat, Dec 01, 2018 at 10:49:42AM -0500, Paul Wouters wrote: > On Sat, 1 Dec 2018, Scott Morizot wrote: > > > I guess I'll speak up as someone who has been managing the DNS/DNSSEC > > design and implementation of a large > > organization with a complex set of DNS requirements > > Thanks for the write up! It is always good to hear actual enterprise > deployments. I will second this "thank you" -- it was very helpful to me, since this is not an area that I am normally exposed to in my day-to-day work. -Benjamin ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-dns-capture-format-09: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-dns-capture-format-09: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/ -- COMMENT: -- Thank you for addressing (or being in the process of addressing) my Discuss points! Adding IANA registries for the bitmaps will address that concern, so I am proactively clearing my position on the basis that those registry creations are in the works. [Original COMMENT section preserved below] Section 2 Please consider using the RFC 8174 version of the BCP 14 boilerplate. Section 3 Because of these considerations, a major factor in the design of the format is minimal storage size of the capture files. maybe "storage and transmission"? Section 6 In Figure 2, the Query name is marked as "(q)" (only present if there is a query), but the running text in Section 4 (bullet 1) says that the Question section from the response can be used as an identifying QNAME if there is a response with no corresponding query. Am I misexpanding QNAME here, or is there a disagreement between these two parts of the text? In particular, I do not see a part of Figure 2 that would correspond to a Question section in the response, given the various "(q)"/"(r)" markings. Section 6.2.2 Messages with OPCODES known to the recording application but not listed in the Storage Parameters are discarded (regardless of whether they are malformed or not). (Do we need to say anything that the "discarded" is only w.r.t. the capture process, and not meant to imply that DNS queries would not get a normal response?) Section 6.2.4 Please consider using IPv6 examples, per https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ . Section 7.2 o The column T gives the CBOR data type of the item. * U - Unsigned integer * I - Signed integer This is venturing a bit far from my normal area of expertise, but my understanding is that CBOR native major types are only provided for unsigned integer and negative integer, with "signed integer" being an abstraction at a slightly higher layer that needs to be managed in the application. Do we need to add any clarifying text here or will the meaning be clear to the reader? Section 7.4 Should probably forward-reference section 8 for the format version numbers' semantics. Section 7.4.1.1 We should we reference the IANA registries by name for any of these fields (e.g., opcodes, rr-types, etc.). (Also in Section 7.5.3.1, etc.) Are the storage flags going to be allocated in sequence by updating standards-track documents, or some other mechanism? (Is a registry necessary?) For the various address prefix fields, do we need to specify that the full addresses are stored when the corresponding prefix field is absent? Section 7.4.1.1.1 Am I parsing the "query-response-hints" text correctly to say that a bit is set in the bitmap if the corresponding field is recorded (if present) by the collecting implementation? The causality of "if the field is omitted the bit is unset" goes in a direction that is not what I expected. (Similarly for the other fields in this table.) Section 7.4.2 Do we need a reference for "promiscuous mode"? Just to check: in "server-addresses", I just infer the IP version from the length of the byte string? Do we need to say more about where the vlan-ids identifiers are taken from? Is the "generator-id" string intended to only be human readable? Only within a specific (administrative) context? Section 7.5.1 Does "earliest-time" include leap seconds? Section 7.5.3 The "ip-address" description seems to imply that very short ipv6 prefix lengths could cause confusion as to the address type being indicated (e.g., setting to 32 when no ipv4 prefix length is set, or setting to the same value as the ipv4 prefix length). Do we need to restrict the ipv6 prefix lengths to being 33 or larger? Are the "name-rdata" contents in wire format or presentation format? Section 7.5.3.2 What's the allocation policy/procedure for the remaining qr-transport-flags transport values? For additional bits in any/all of the flags fields listed here? Something of a side note, what's the mnemonic for the "sig" in "qr-sig-flags"? That is, what is it a signature of or over (it does
Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)
On Thu, Nov 29, 2018 at 03:43:20PM +, Sara Dickinson wrote: > > > On 24 Nov 2018, at 03:58, Benjamin Kaduk > <mailto:ka...@mit.edu>> wrote: > > > > On Thu, Nov 22, 2018 at 12:01:00PM +, Sara Dickinson wrote: > >>> > >>> Section 7.4.1.1.1 > >>> > >>> Am I parsing the "query-response-hints" text correctly to say that a bit > >>> is > >>> set in the bitmap if the corresponding field is recorded (if present) by > >>> the collecting implementation? The causality of "if the field is omitted > >>> the bit is unset" goes in a direction that is not what I expected. > >>> (Similarly for the other fields in this table.) > >> > >> ekr picked up on the same point - as responded to him: > >> > >> "The issue is that if the bit is set the field might still be missing > >> because although the configuration was set to collect it the data wasn’t > >> available to the encoder from some other reason. However when the bit is > >> not set it means that the data will definitely not be present because the > >> collector is configured not to collect it. > >> > >> We do discuss this problem in section 6.2.1 - perhaps a reference in the > >> table back to that discussion is what is needed?” > >> > >> Looking again I think a slight update to the text in 6.2.1 might help too: > >> > >> OLD: > >> “The Storage Parameters therefore also contains a Storage Hints item > >> which specifies which items the encoder of the file omits from the > >> stored data." > >> > >> NEW: “The Storage Parameters therefore also contains a Storage Hints item > >> which specifies which items the encoder of the file omits from the > >> stored data and will therefore never be present. (This approach is taken > >> because a flag that indicated which items were included for collection > >> would > >> not guarantee that the item was present, only that it might be.) " > > > > This text helps, but I think it is not quite what I was going after -- that > > is, when I think of a "hint" that feels like something active and that > > would be indicated by setting a bit to one. In this design, the hints > > about what are *omitted* are the bits that are *zero*, which is > > counter-intuitive, at least to me. So maybe we could say (in 7.4.1.1.1, in > > addition to your suggested change in 6.2.1): > > > > Hints indicating which "QueryResponse" fields are candidates for capture or > > omitted, see section 7.6. If a bit is unset, that field is omitted from > > the capture. > > Ah, ok I see the confusion now and yes - this text improves the draft - thank > you! > > > > >> > >>> > >>> Section 7.4.2 > >>> > >>> Do we need a reference for "promiscuous mode”? > >> > >> Promiscuous mode is discussed on the main PCAP manpage…. Hopefully a way > >> will be found to address the question of a suitable reference format for > >> PCAP material. > >> > >>> > >>> Just to check: in "server-addresses", I just infer the IP version from the > >>> length of the byte string? > >> > >> As mentioned in the DISCUSS response, we probably need to make the > >> transport flags mandatory. > >> > >>> > >>> Do we need to say more about where the vlan-ids identifiers are taken > >>> from? > >> > >> Suggest: > >> > >> OLD: “ | vlan-ids | O | A | Array of identifiers (of type unsigned > >> | > >> | | | | integer) of VLANs selected for | > >> | | | | collection. “ > >> > >> NEW: “ | vlan-ids | O | A | User specified array of identifiers > >> (of type unsigned | > >> | | | | integer) of VLANs [IEEE 802.1Q] selected > >> for | > >> | | | | collection. " > > > > It seems likely to me that we want to say that the actual VLAN ID values > > are only unique within an administrative domain. > > OK - yes, makes sense. > > > > >>> > >>> Is the "generator-id" string intended to only be human readable? Only > >>> within a specific (administrative) context? > >> > >> The generator ID is intended only t
Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)
On Thu, Nov 22, 2018 at 12:01:00PM +, Sara Dickinson wrote: > > > Begin forwarded message: > > > > From: Benjamin Kaduk mailto:ka...@mit.edu>> > > Subject: Benjamin Kaduk's Discuss on > > draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT) > > Date: 19 November 2018 at 00:28:19 GMT > > To: "The IESG" mailto:i...@ietf.org>> > > Cc: draft-ietf-dnsop-dns-capture-for...@ietf.org > > <mailto:draft-ietf-dnsop-dns-capture-for...@ietf.org>, Tim Wicinski > > mailto:tjw.i...@gmail.com>>, dnsop-cha...@ietf.org > > <mailto:dnsop-cha...@ietf.org>, tjw.i...@gmail.com > > <mailto:tjw.i...@gmail.com>, dnsop@ietf.org <mailto:dnsop@ietf.org> > > Resent-From: mailto:alias-boun...@ietf.org>> > > Resent-To: j...@sinodun.com <mailto:j...@sinodun.com>, j...@sinodun.com > > <mailto:j...@sinodun.com>, s...@sinodun.com <mailto:s...@sinodun.com>, > > terry.mander...@icann.org <mailto:terry.mander...@icann.org>, > > john.b...@icann.org <mailto:john.b...@icann.org> > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-dnsop-dns-capture-format-08: Discuss > > To follow up on items not addressed in our previous email. > > > -- > > DISCUSS: > > -- > > > > There are also a couple of fields whose semantics don't seem to be > > sufficiently well specified for a proposed-standard document, such as > > vlan-ids, generator-id, name-rdata, and ae-code. (I understand that some > > of them are probably only going to have locally relevant semantics, but we > > should be explicit about when that's the case.) > > We have addressed the specific fields mentioned here in the comments below > related to each of them. > > > > > > > -- > > COMMENT: > > -- > > > > Section 2 > > > > Please consider using the RFC 8174 version of the BCP 14 boilerplate. > > Yes - will replace. > > > > > Section 3 > > > > Because of these considerations, a major factor in the design of the > > format is minimal storage size of the capture files. > > > > maybe "storage and transmission”? > > Sure. > > > > > Section 6 > > > > In Figure 2, the Query name is marked as "(q)" (only present if there is a > > query), but the running text in Section 4 (bullet 1) says that the Question > > section from the response can be used as an identifying QNAME if there is a > > response with no corresponding query. Am I misexpanding QNAME here, or is > > there a disagreement between these two parts of the text? In particular, I > > do not see a part of Figure 2 that would correspond to a Question section > > in the response, given the various "(q)"/"(r)" markings. > > Good spot - you are correct this is an error in the diagram and it should > read 'Query name' with no qualifier. Oh good, I was worried that I was just confusing myself, so that's reassuring to know. > > > > Section 6.2.2 > > > > Messages with OPCODES known to the recording application but not > > listed in the Storage Parameters are discarded (regardless of whether > > they are malformed or not). > > > > (Do we need to say anything that the "discarded" is only w.r.t. the capture > > process, and not meant to imply that DNS queries would not get a normal > > response?) > > Suggest: “Messages with OPCODES known to the recording application but not > listed in the Storage Parameters are discarded by the recording application > during C-DNS capture (regardless of whether they are malformed or not)." That sounds good (and to be clear, when I asked the question I wasn't sure if the answer would just be "no"). > > > > Section 6.2.4 > > > > Please consider using IPv6 examples, per > > https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ > > <https://www.iab.org/2016/11/07/iab-statement-on-ipv6/> . > > Yes - will add an IPv6 example. > > > > > Section 7.2 > > > > o The column T gives the CBOR data type of the item. > > > > * U - Unsigned integer > > > > * I - Signed integer > > > > This is ventu
Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)
On Wed, Nov 21, 2018 at 01:53:09PM +, Sara Dickinson wrote: > > > > Begin forwarded message: > > > > From: Benjamin Kaduk mailto:ka...@mit.edu>> > > Subject: Benjamin Kaduk's Discuss on > > draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT) > > Date: 19 November 2018 at 00:28:19 GMT > > To: "The IESG" mailto:i...@ietf.org>> > > Cc: draft-ietf-dnsop-dns-capture-for...@ietf.org > > <mailto:draft-ietf-dnsop-dns-capture-for...@ietf.org>, Tim Wicinski > > mailto:tjw.i...@gmail.com>>, dnsop-cha...@ietf.org > > <mailto:dnsop-cha...@ietf.org>, tjw.i...@gmail.com > > <mailto:tjw.i...@gmail.com>, dnsop@ietf.org <mailto:dnsop@ietf.org> > > Resent-From: mailto:alias-boun...@ietf.org>> > > Resent-To: j...@sinodun.com <mailto:j...@sinodun.com>, j...@sinodun.com > > <mailto:j...@sinodun.com>, s...@sinodun.com <mailto:s...@sinodun.com>, > > terry.mander...@icann.org <mailto:terry.mander...@icann.org>, > > john.b...@icann.org <mailto:john.b...@icann.org> > > Many thanks for the detailed review. > > > > > -- > > DISCUSS: > > -- > > > > It is pretty shocking to not see any discussion of the privacy > > considerations of storing data including client addresses (and ports) > > alongside DNS transactions, given how central DNS resolution is to user > > behavior on the web. (Note that there are mentions of potentially > > anonymized data in Sections 6.2 and 6.2.3 which would presumably > > forward-reference the privacy considerations.) Data normalization would > > probably also be mentioned in this section, since (e.g.) the case used for > > a query/response could be used in fingerprinting an implementation. > > There have been extensive discussion of data storage risks and practices in > two DPRIVE documents so I’d suggest the following changes in the first > instance to address this: This is exactly the sort of thing I was hoping to see, thank you! I have just a couple tweaks to suggest, inline. > New Privacy Considerations section: > “ Storage of DNS traffic by operators in PCAP and other formats is a long > standing and widespread practice. Section 2.5 of > draft-bortzmeyer-dprive-rfc7626-bis is an analysis of the risks to Internet > users of the storage of DNS traffic data in servers (recursive resolvers, > authoritative and rogue server). > > Section 5.2 of draft-dickinson-dprive-bcp-op describes mitigations for those > risks for data stored on recursive resolvers (but which could by extension > apply to authoritative servers). These include data handling practices and > methods for data minimisation, IP address pseudonymization and anonymization. > Appendix B of that document presents an analysis of 7 published anonymization > processes. In addition RSSAC have recently published RSSAC04: " > Recommendations on Anonymization Processes for Source IP Addresses Submitted > for Future Analysis”[1]. > > The above analyses consider full data capture (e.g using PCAP) as a > baseline for privacy considerations and therefore this format > specification introduces no new user privacy issues beyond those of full > data capture. It does provides mechanisms to selectively record only I would say "beyond those of full data capture (which are quite severe)". That is, while the current state of affairs is a valid baseline for comparison, that does not absolve us of responsibility for analyzing the current state of affairs. (To be clear, draft-bortzmeyer-dprive-rfc7626-bis is a fine place for the bulk of that anlaysis to live, but in this document we should not pretend that the current state of affairs is a good situation to be in.) > certain fields at the time of data capture to improve user privacy and to > explicitly indicate that data is sampled and or anonymised. It also > provide flags to indicate if data normalisation has been performed; data > normalisation increases user privacy by reducing the potential for > fingerprinting individuals however a trade-off is potentially reducing I think "however" would be offset by commas on both sides. > the capacity to identify attack traffic via query name signatures. > Operators should carefully consider their operational requirements and > privacy policies and SHOULD capture at source the minimum user data > required to meet their needs“ > > [1] https://www.icann.org/en/system/files/files/rssac-040-07aug18-en.pdf > <https://www.icann.org/en/system/files/files/rssac-040-07
[DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-dns-capture-format-08: Discuss 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/ -- DISCUSS: -- It is pretty shocking to not see any discussion of the privacy considerations of storing data including client addresses (and ports) alongside DNS transactions, given how central DNS resolution is to user behavior on the web. (Note that there are mentions of potentially anonymized data in Sections 6.2 and 6.2.3 which would presumably forward-reference the privacy considerations.) Data normalization would probably also be mentioned in this section, since (e.g.) the case used for a query/response could be used in fingerprinting an implementation. I'm also concerned about the policy/procedure for allocating/extending the various bitfields and similar potential extension points in the data structures. Section 8 covers the major/minor versioning semantics with respect to new map keys and new maps, but not addition of new bits within existing (uint) bitmaps. Given the usage of the CDDL .bits constraint, it's not really clear that an IANA registry is the right tool to use, but I think some indication of the expected way to allocate new bits is in order, whether it's "a future standards-track document that updates this document" or otherwise. (I've noted many, but not all, instances of such bitmaps in my COMMENT section.) There are also a couple of fields whose semantics don't seem to be sufficiently well specified for a proposed-standard document, such as vlan-ids, generator-id, name-rdata, and ae-code. (I understand that some of them are probably only going to have locally relevant semantics, but we should be explicit about when that's the case.) If I'm reading things correctly that the IP address type is inferred from the bytestring length, then I think we need to enforce a restriction on the address prefix length(s) to allow for that inference to be unambiguous (noting that we only have the *byte* length of the address fields at our disposal for disabmgituation, and not the more precise bit-length). -- COMMENT: -- Section 2 Please consider using the RFC 8174 version of the BCP 14 boilerplate. Section 3 Because of these considerations, a major factor in the design of the format is minimal storage size of the capture files. maybe "storage and transmission"? Section 6 In Figure 2, the Query name is marked as "(q)" (only present if there is a query), but the running text in Section 4 (bullet 1) says that the Question section from the response can be used as an identifying QNAME if there is a response with no corresponding query. Am I misexpanding QNAME here, or is there a disagreement between these two parts of the text? In particular, I do not see a part of Figure 2 that would correspond to a Question section in the response, given the various "(q)"/"(r)" markings. Section 6.2.2 Messages with OPCODES known to the recording application but not listed in the Storage Parameters are discarded (regardless of whether they are malformed or not). (Do we need to say anything that the "discarded" is only w.r.t. the capture process, and not meant to imply that DNS queries would not get a normal response?) Section 6.2.4 Please consider using IPv6 examples, per https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ . Section 7.2 o The column T gives the CBOR data type of the item. * U - Unsigned integer * I - Signed integer This is venturing a bit far from my normal area of expertise, but my understanding is that CBOR native major types are only provided for unsigned integer and negative integer, with "signed integer" being an abstraction at a slightly higher layer that needs to be managed in the application. Do we need to add any clarifying text here or will the meaning be clear to the reader? Section 7.4 Should probably forward-reference section 8 for the format version numbers' semantics. Section 7.4.1.1 We should we reference the IANA registries by name for any of these fields (e.g., opcodes, rr-types, etc.). (Also in Section 7.5.3.1, etc.) Are the storage flags going to be allocated in sequence by upd
[DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-kskroll-sentinel-15: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-kskroll-sentinel-15: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/ -- COMMENT: -- Thanks for addressing my Discuss points -- the text in the github version of this document helps a lot, and I'm happy with the direction we're going in for the more general case. [original ballot comments preserved below] Other than my Discuss points, I just have a number of essentially editorial nits. Abstract 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. [...] This wording feels confusing to me; I think what it's trying to say is "the root key(s) that are in use by the resolver" but am having a hard time grouping these words to achieve that meaning. (Is "trust" really necessary to mention, here?) Section 1 RRSIG RRs contain a Key Tag field whose value is equal to the Key Tag of the DNSKEY RR that was used to generate the corresponding signature. nit: Is the RR used to generate the signature, or just the key? o Users may wish to ascertain whether their DNS resolution environment resolvers is ready for an upcoming root KSK rollover. nit: I think there's a singular/plural mismatch or similar here, maybe "environment's resolver"? o Researchers want to perform Internet-wide studies about the proportion of users who will be negatively impacted an upcoming root KSK rollover. nit: "by an upcoming" If a browser or operating system is configured with multiple resolvers, and those resolvers have different properties (for example, one performs DNSSEC validation and one does not), the sentinel test described in this document can still be used, but it nit: this usage of "but" feels a bit misplaced to me, as the thing being warned about is more that the test may produce indeterminate or inconsistent results. Or perhaps that the assumptions it makes may not necessarily hold in the specific environments being described (i.e., "these environments"). makes a number of assumptions about DNS resolution behaviour that may not necessarily hold in all environments. If these assumptions do not hold (such as, for example, requiring the stub resolver to query the next recursive resolver in the locally configured set upon receipt of a SERVFAIL response code) then this test may produce indeterminate or inconsistent results. In some cases where these assumptions do not hold, repeating the same test query set may generate different results. Section 1.1 Please use the RFC 8174 boilerplate. Section 3 I'll note without further comment that we had a long thread on ietf@ relevant to the term "slave resolver". Section 3.1 If the resolver is non-validating, and it has a single forwarder, then the resolver will presumably mirror the capabilities of the forwarder target resolver. Perhaps this is just me misreading the previous paragraph's introduction to what is clearly a more widely known term of art, but in "has a single forwarder" is the thing of which there is only one the "one or more other resolvers" that the "forwarder" is relaying queries to? It's just weird for the word "forwarder" mean a different protocol participant when used as a noun vs. adjective. Or perhaps this is meant to be possessive; the "forwarder's target resolver"? As noted in the directorate review, "use the CD bit" needs disambiguation. Section 4 nit: missing trailing 'r' in the section title Section 4.3 Maybe call out that these are the same general categories of query as in Section 3 but the key tag used is different for some queries? It's also a bit weird to use new notation for this section as opposed to consistent notation between the different types of test. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Mirja Kühlewind's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)
On Mon, Oct 15, 2018 at 04:56:18PM +0200, Mirja Kuehlewind (IETF) wrote: > Sorry, one more comment on section 11.1: > "DSO permits zero round-trip operation using TCP Fast Open [RFC7413] > with TLS 1.3 [RFC8446] 0-RTT to reduce or eliminate round trips in > session establishment.“ > > This sounds like TCP Fast Open and TLS 0-RTT can only be used together. > However these are to different mechanism with different properties/problems > and I don’t think they should be mixed up. If I remember correctly, it was intended in the rev to only use TFP together with TLS 1.3 0-RTT and disallow using just one, though I forget exactly how this came out of the discussion from my Discuss point about specifying the TLS 1.3 0-RTT application profile. -Benjamin > Data that is send with with TLS 0-RTT must be idempotent as for this data an > reply attack is possible which is not the case for the rest of the TLS data. > However with TCP without TLS (but maybe TFO) reply attacks are always > possible, so that’s not an additional problem if TFO. > > With TFO however, a server could start processing without having a return > routability proof, however, such a problem can also be addressed on the > server-side by simply not stat processing large request before the TCP > connection is fully established and that is actually safer than leaving the > decisions to the client. > > Please clarify that TLS 0-RTT can be used without TFO (or TFO can be used > without TLS) and I would also recommend to discuss the respective issue > separately. > > Mirja > > > > > > Am 15.10.2018 um 16:02 schrieb Mirja Kuehlewind (IETF) > > : > > > > Hi Ted, > > > > sorry for the delay, however, as you performed a couple of changes it took > > me a while to re-review. I believe I’m unfortunately not fully ready to > > release my discuss at this point, but close.. > > > > Regarding my first discuss point (delayed ACKs aso.) I think the text > > improved and I would like to seem my minor wording question (comment 2) > > below addressed before I finally release the discuss here. However, I still > > think the extensive discussion as provided in section 9.5 now, does not > > necessarily belong in this document. Therefore I would rather would have > > preferred to move this text in a real appendix, or removed it completely > > and maybe document in an own informational RFC (in tcpm). > > > > Regarding my second discuss point (keep-alives), the text seems still not > > quite right yet, or I’m really confused. Please also see also further below > > (comment 3). > > > > Anyway here are my comments on the edited/new text in the order they appear > > in the draft: > > > > 1) I think the following text in section 3 is not fully correct: > > > > "Fast Open message: A TCP SYN packet that begins a DSO connection and > > contains early data ([RFC8446] section 2.3). Fast Open is only > > permitted when using TLS encapsulation: a TCP SYN message that does > > not use TLS encapsulation but contains early data is not permitted.“ > > If TLS 0-RTT is used this data will not be carried in the TCP SYN, it will > > „just“ be send at the same time as the TLS handshake is performed (but > > after the TCP handshake). Only if TCP Fast Open (TFO) (see RFC7413) is > > used, data can also be sent in the TCP SYN. I guess you mainly need to fix > > the reference here, or maybe name both mechanisms separately. > > > > > > 2) In section 5.5.1: > > "With a DSO request message, the TCP implementation waits for the > > application-layer client software to generate the corresponding DSO > > response message, which enables the TCP implementation to send a > > single combined IP packet containing the TCP acknowledgement, the TCP > > window update, and the application-generated DSO response message. > > This is more efficient than sending three separate IP packets.“ > > > > The phrasing here is a bit confusing, to me at least. It sounds a bit like > > there is a special TCP for DSO… maybe the following is a bit better: > > "With a DSO request message, TCP delayed acknowledge timer will usually > > make the implementation wait for the > > application-layer client software to generate the corresponding DSO > > response message before it sends out an TCP acknowledgment > > This will generate a > > single combined IP packet containing the TCP acknowledgement, the TCP > > window update, and the application-generated DSO response message and > > is more efficient than sending three separate IP packets.“ > > > > (Note that the deplayed ack timer can be configured to a very small value > > as well, and as such it depends on the processing time and the value of the > > timer if a TCP implementation will wait or not.) > > > > 3) Section 6.5.2 > > "For example, a (hypothetical and unrealistic) > > keepalive interval value of 100 ms would result in a continuous > > stream of ten messages per second or more, in b
[DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-attrleaf-fix-04: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-attrleaf-fix-04: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf-fix/ -- COMMENT: -- I support Alissa's Discuss points (and in particular would think that this document would be fine as Proposed Standard). One other comment, in Section 3.1: Why is the new text only placing a "SHOULD be registered" requirement, as opposed to MUST? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-attrleaf-13: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for
draft-ietf-dnsop-attrleaf-13: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/
--
COMMENT:
--
I'm happy to see this registry created and populated; I would be balloting
YES except that I do not think I have time to follow all the references
for the initial registry contents.
That said, I do share Adam's concern about IANA being more reliable than
authors of future enum-services documents at remembering to (check whether
to) update a second table, but the subsequent discussion about not all
enum-services necessarily being used in URI records seems to support the
current scheme.
I also have some section-by-section comments.
Abstract
Formally, any DNS resource record may occur under any domain name.
However some services have defined an operational convention, which
applies to DNS leaf nodes that are under a DNS branch having one or
more reserved node names, each beginning with an _underscore. [...]
nit: just "underscore" or "_", I think -- "_underscore" is not a well
recognized character.
Section 1.4
Conversely, a wildcard such as *.example.com can match any name
including an underscored name. So, a wildcard might match an
underscored name, returning a record that is the type controlled by
the underscored name but is not intended to be used in the
underscored context and does not conform to its rules.
This could perhaps benefit from greater clarity on which entity's
perspective the "not intended" applies to. I assume the entity making the
wild query does not intend to interpret the response in an underscore
context, but the language is a bit hard to follow.
Section 3
This section provides a basic template that can be used to register
new entries in the IANA DNS Underscore Global Scoped Entry Registry,
if the global underscored name above the RRTYPE is not already
registered. [...]
I'm not sure how to parse "name above the RRTYPE", since (1) the RRTYPE
record can have the owner name that is the global underscored name, and (2)
the RRTYPE is, well, a record type and not a name.
Section 4.1
I would consider adding another 8126 citation for "Expert Review"
procedures.
Section 4.3
There are some URI usages with node names _kerberos, _kpasswd, and
_kerberos-adm listed in draft-ietf-kitten-krb-service-discovery (and
implemented, per
http://web.mit.edu/kerberos/krb5-latest/doc/admin/realm_config.html#kdc-discovery).
It's unclear whether they meet the WG's criteria for inclusion in the
initial registry contents, especially at such a late stage of the document's
lifecycle.
Section 5
For the purposes of this Expert Review, other matters of the
specification's technical quality, adequacy or the like are outside
of scope.
I have mixed feelings about wanting to keep registration open to avoid
squatting, but also about wanting to allow the experts to reject requests
that do not provide a clear and interoperable description of what the
RRTYPE+name is used for. I do think that the first bullet point
("sufficeintly clear, precise and complete") allows the experts some leeway
in this regard, but when limited by this statement I'm not sure it provides
the experts enough leeway.
Section 6
One could perhaps argue that by creating a global registry this document
reduces the likelihood of inadvertent collision, and that such collision
could have security consequences. But it would be a bit of a stretch.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-session-signal-15: (with DISCUSS and COMMENT)
Hi Ted, On Thu, Sep 27, 2018 at 01:03:21AM -0400, Ted Lemon wrote: > On Sep 27, 2018, at 12:55 AM, Ted Lemon wrote: > > Yup. Sorry about that. I just submitted a new version that I hope > > addresses this request. > > There's a mistake in the update—while I was working on the new text, I added > a caveat about implicit sessions, but didn't notice that that had weakened > the requirements on the client. I've addressed this with the following > change, but will wait on your and Mirja's responses before resubmitting: > > - If a server receives a Fast Open message containing a DSO message > - whose primary TLV is not permitted to appear in a Fast Open message, > - the server MUST forcible abort the connection. If a client receives > - a Fast Open message containing any DSO message, and there is no > - implicit DSO session, the client MUST forcibly abort the connection. > - If a server or client receives a Fast Open message that is not a TLS > - 1.3 message, it MUST forcibly abort the connection. > + If a client or server receives a Fast Open message containing a DSO > + message whose primary TLV is not permitted to appear in a Fast Open > + message, the server MUST forcible abort the connection. If a client > + receives a Fast Open message containing any DSO message, and there is > + no implicit DSO session, the client MUST forcibly abort the > + connection. If a server or client receives a Fast Open message that > + is not a TLS 1.3 message, it MUST forcibly abort the connection. The -16 (plus this) look great; exactly what I was looking for. I'll go clear my Discuss in the datatracker. But just to double-check my understanding: the idea is that the TCP Fast Open payloads will only be used when TLS 1.3 is in use, and some be something like (client's first handshake flight + early data) and (server's first handshake flight + 0.5-RTT data), with the DSO operations being in the early data and 0.5-RTT data records' payloads? Also, I don't remember if IANA likes to keep columns like our "Fast Open" one blank for unassigned/reserved ranges. But presumably they will tell you :) Thanks again, Benjamin ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-isp-ip6rdns-07: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-isp-ip6rdns-07: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-isp-ip6rdns/ -- COMMENT: -- Thanks for the well-written document! I wrote down some thoughts I had while reading, but they should be treated as very weak suggestions and no pressure to apply them is implied. Section 2.1 DNS administrators should consider the uses for reverse DNS records and the number of services affecting the number of users when evaluating this option. nit: maybe this could be qualified as "number of services relying on PTR records", as otherwise it can be read as a bit of a non sequitur. Section 2.3 Administrators may want to consider user creativity if they provide host names, as described in Section 5.4 "User Creativity." Perhaps "the risks of user creativity"? Section 2.3.1 This option may be scalable, although registration following an outage may cause significant load, and hosts using privacy extensions [RFC4941] may update records daily. [...] I think I've heard of deployments that update more often than daily, though it's unclear that there's a need for this document to mention such possibilities. Section 4 There are six common uses for PTR lookups: I'm a little uncomfortable asserting this as a complete and exhaustive listing in an Informational document, but I also can't dispute its veracity. I'll trust that the authors and WG have done sufficient research and not request any change here. For residential users, if these four use cases are important to the ISP, the administrator will then need to consider how to provide PTR records. but I do have to wonder which four of the six the ISPs are supposed to be considering. A valid negative response (such as NXDOMAIN) is a valid response, if the four cases above are not essential; delegation where no name server exists should be avoided. and similarly here. Section 5.1 Providing location information in PTR records is useful for troubleshooting, law enforcement, and geolocation services, but for the same reasons can be considered sensitive information. It may be worth clarifying that the sensitive nature is an argument for not publishing, since there aren't really well-established schemes for filtering access to the relevant DNS records. Section 5.3 Maybe say something about "for use in other protocols" if we're not trying to limit to DNSKEY and friends? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-kskroll-sentinel-15: (with DISCUSS and COMMENT)
On Wed, Sep 26, 2018 at 10:12:08AM -0700, Warren Kumari wrote: > On Wed, Sep 26, 2018 at 8:16 AM Benjamin Kaduk wrote: > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-dnsop-kskroll-sentinel-15: Discuss > > > > 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/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/ > > > > > > > > -- > > DISCUSS: > > -- > > > > Thanks for preparing this document and mechanism; it is good to have more > > data about the expected impact of the root KSK roll. That said, I have two > > Discuss-worthy points, albeit both fairly minor. > > > > The first one may just be something that I missed, but does this document > > actually say anywhere that there needs to be a real zone with real > > configured A and/or records for the query names used for these tests? > > The Appendix sort-of-mentions it, but I feel like there needs to be a > > mention in the main body text. > > > > > No hats (OMG, everyone will see I'm going bald...) > > Ok, fair. This was actually a source of confusion when we first started > discussing the document -- we explained it on-list / at mics / in person, > but it became so well understood that we didn't notice that it is not > actually specified in the document. I'll try figure out text. Thanks. It eventually became pretty clear to me from things like "return the A or response unchanged" that there was supposed to be a valid response provisioned so that it could be returned, but I don't want to rely on all readers making the same inference. > > > The other point basically is a procedural one, in that we are in effect > > claiming a couple of leaf name prefixes in all domains to exhibit "weird > > and surprising behavior" (that is, for parties unaware of this > > specification). We generally try to avoid this sort of namespace > > squatting, preferring (e.g.) /.well-known for HTTP requests, various > > underscore-prefixed tricks for the DNS, etc. I see in the changelog that > > initial attempts did use an underscore prefix but ran into implementation > > difficulty, and acknowledge that using a "magic" name is much easier to get > > deployed than (e.g.) a new RR type. But I do not want the IESG to > > implicitly approve a namespace claim like this; it's better to be explicit > > about it if this is the best way to go. > > > > > Ok, I see your point. We've actually done something similar in RFC8145 > where we "reserved" (caused funny behavior) for _ta-.example.com, but > this is subtly different. There was some discussion on this and the fact > that could cause "unexpected" behavior. Unfortunately underscore labels > really don't work for us -- for example, Android (and some unix machines) > will not follow / fetch a link of the form http://_foo.example.com. The > labels that we are chose (after a huge amount of discussion) are > "root-key-sentinel-is-ta-" > and "root-key-sentinel-not-ta-". These labels seem sufficiently long > and obtuse that we don't expect them to be used for anything else (e.g: > risk of people happening to choose to name a machine > root-key-sentinel-is-ta-1234.example.com and then being surprised) is > vanishingly small. I agree that it's vanishingly small, and the "magic" behavior is just to return a SERVFAIL, something that in theory could happen at arbitrary times anyway, so the practical effect is not something I'm especially concerned about. (Hey, I did say it was a procedural point!) > But, yes, this does let let the camel's nose into the tent - we are > co-opting some names. > > Do you have any suggested text that you could provide to help us explain > this? I didn't have anything in particular in mind when I balloted, no (and in fact I wasn't entirely sure that any new text would be needed, depending on how we felt about it). But you're probably right that we should describe that this is exceptional behavior of a spec, why the impact is minimal, a
[DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-kskroll-sentinel-15: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-kskroll-sentinel-15: Discuss 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/ -- DISCUSS: -- Thanks for preparing this document and mechanism; it is good to have more data about the expected impact of the root KSK roll. That said, I have two Discuss-worthy points, albeit both fairly minor. The first one may just be something that I missed, but does this document actually say anywhere that there needs to be a real zone with real configured A and/or records for the query names used for these tests? The Appendix sort-of-mentions it, but I feel like there needs to be a mention in the main body text. The other point basically is a procedural one, in that we are in effect claiming a couple of leaf name prefixes in all domains to exhibit "weird and surprising behavior" (that is, for parties unaware of this specification). We generally try to avoid this sort of namespace squatting, preferring (e.g.) /.well-known for HTTP requests, various underscore-prefixed tricks for the DNS, etc. I see in the changelog that initial attempts did use an underscore prefix but ran into implementation difficulty, and acknowledge that using a "magic" name is much easier to get deployed than (e.g.) a new RR type. But I do not want the IESG to implicitly approve a namespace claim like this; it's better to be explicit about it if this is the best way to go. -- COMMENT: -- Other than my Discuss points, I just have a number of essentially editorial nits. Abstract 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. [...] This wording feels confusing to me; I think what it's trying to say is "the root key(s) that are in use by the resolver" but am having a hard time grouping these words to achieve that meaning. (Is "trust" really necessary to mention, here?) Section 1 RRSIG RRs contain a Key Tag field whose value is equal to the Key Tag of the DNSKEY RR that was used to generate the corresponding signature. nit: Is the RR used to generate the signature, or just the key? o Users may wish to ascertain whether their DNS resolution environment resolvers is ready for an upcoming root KSK rollover. nit: I think there's a singular/plural mismatch or similar here, maybe "environment's resolver"? o Researchers want to perform Internet-wide studies about the proportion of users who will be negatively impacted an upcoming root KSK rollover. nit: "by an upcoming" If a browser or operating system is configured with multiple resolvers, and those resolvers have different properties (for example, one performs DNSSEC validation and one does not), the sentinel test described in this document can still be used, but it nit: this usage of "but" feels a bit misplaced to me, as the thing being warned about is more that the test may produce indeterminate or inconsistent results. Or perhaps that the assumptions it makes may not necessarily hold in the specific environments being described (i.e., "these environments"). makes a number of assumptions about DNS resolution behaviour that may not necessarily hold in all environments. If these assumptions do not hold (such as, for example, requiring the stub resolver to query the next recursive resolver in the locally configured set upon receipt of a SERVFAIL response code) then this test may produce indeterminate or inconsistent results. In some cases where these assumptions do not hold, repeating the same test query set may generate different results. Section 1.1 Please use the RFC 8174 boilerplate. Section 3 I'll note without further comment that we had a long thread on ietf@ relevant to the term "slave resolver". Section 3.1 If the resolver is non-validating, and it has a single forwarder, then the resolver will presumably mirror the capabilities of the forwarder target resolver. Perhaps this is just me misreading the previous paragraph's introdu
[DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-session-signal-15: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-session-signal-15: Discuss 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ -- DISCUSS: -- Thank you for resolving most of my DISCUSS points (the additional clarification about when the one-hour retry does (not) apply in particular is helpful even if not strictly needed). However, it seems that my point about an "application protocol profile" for TLS 1.3 0-RTT was deferred until the resolution of a different thread covering 0-RTT, but that we never picked it back up. I think this document's profile needs to provide greater clarity about what specific messages are (or are not) allowed in 0-RTT data, i.e., listing permitted TLVs and having a column in the registry for whether a TLV is 0-RTT-safe. For example, Retry Delay simply cannot appear in a DSO message that is eligible for 0-RTT, so it accordingly cannot appear in a 0-RTT message, while EncryptionPadding should be safe to appear [as an additional TLV], provided there is a suitable primary TLV to attach it to. On first look [after long absence], the keepalive TLV should be safe to use as a 0-RTT primary TLV, since it elicits a response and only affects the current connection. Anyway, my main point here is that we need to place the burden of analysis on a TLV's safety on the authors of the spec introducing that TLV, and not on implementors or users of the protocol. -- COMMENT: -- [COMMENT section unchanged from original ballot; contents may no longer apply] Six authors exceeds five, so "there is likely to be discussion" about this being too large a number of authors. What is the justification for the author count? Do we need to specify some GREASE (per draft-ietf-tls-grease) for new TLV types in order to ensure the proper handling of unknown types? Section-by-section comments follow. Section 1 A DoH reference seems timely/apt. (But maybe then it is only "Some such transports" that can offer persistent sessions.) Maybe give some examples of advantages of server-initiated messages? Are we talking about letting the server push records with larger TTLs or notifying when the response to a query is changing, or just more mundane keepalive-type things? Section 3 The terms "initiator" and "responder" correspond respectively to the initial sender and subsequent receiver of a DSO request message or unacknowledged message, regardless of which was the "client" and "server" in the usual DNS sense. We just defined "client" and "server" explictly (without reference to the "usual DNS sense"), so probably it's best to have this definition refer to the previous client/server definitions or clarify that the above definitions match the "usual DNS sense". When an anycast service is configured on a particular IP address and port, it must be the case that although there is more than one physical server responding on that IP address, each such server can be treated as equivalent. If a change in network topology causes packets in a particular TCP connection to be sent to an anycast server instance that does not know about the connection, the normal keepalive and TCP connection timeout process will allow for recovery. If after the connection is re-established, [...] Perhaps clarifying that "recovery" means "detecting the broken session and starting a new one" would be useful? (I guess Spencer's DISCUSS takes this a different direction.) DSO unacknowledged messages are unidirectional messages and do not generate any response. "Do not generate any response" at the DNS layer; any reason to mention that TCP will still ACK the bytes (or rather, that the "reliable" part of the data stream will need to do so)? Section 5.1 DSO messages MUST be carried in only protocols and in environments where a session may be established according to the definition given above in the Terminology section (Section 3). nit: is this "in only" or "only in" If the RCODE is set to any value other than NOERROR (0) or DSOTYPENI ([TBA2] tentatively 11), then the client MUST assume that the ser
Re: [DNSOP] Benjamin Kaduk's Yes on draft-ietf-dnsop-refuse-any-07: (with COMMENT)
On Thu, Sep 13, 2018 at 09:38:54AM +1100, Ólafur Guðmundsson wrote: > On Thu, Sep 13, 2018 at 9:13 AM, Benjamin Kaduk wrote: > > > Hi Ólafur, > > > > Before I get into the inline comments, I should note something that I only > > noticed after I posted my ballot position: although everyone I know always > > refers to this query as "ANY", that's the command-line interface in dig(1), > > etc., it seems that the specified string to refer to this query is > > officially "*". That's what 1035 uses and that's what's in the IANA > > registry; RFC 6895 has a clarification in a parenthetical "* (ALL/ANY)", > > but I didn't see much precedent for only using "ANY" in an RFC to refer to > > this query. To be clear, I don't object to using that as the primary term > > -- it is, after all, the common usage! But perhaps it's worth a short > > mention at the start that we use "ANY" to refer to QTYPE 255, registered as > > "*". The reader can perhaps infer this fact from the IANA considerations > > that update that entry in the registry to also refer to this document, but > > it would be nice for the relationship to be more explicit. > > > That is a great point something like: > RFC1035 defined "*" as type 255 but DNS applications have used the "ANY" > word to refer to that type code" That works to get the point across, sure. Thanks, Benjamin ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Benjamin Kaduk's Yes on draft-ietf-dnsop-refuse-any-07: (with COMMENT)
Hi Ólafur, Before I get into the inline comments, I should note something that I only noticed after I posted my ballot position: although everyone I know always refers to this query as "ANY", that's the command-line interface in dig(1), etc., it seems that the specified string to refer to this query is officially "*". That's what 1035 uses and that's what's in the IANA registry; RFC 6895 has a clarification in a parenthetical "* (ALL/ANY)", but I didn't see much precedent for only using "ANY" in an RFC to refer to this query. To be clear, I don't object to using that as the primary term -- it is, after all, the common usage! But perhaps it's worth a short mention at the start that we use "ANY" to refer to QTYPE 255, registered as "*". The reader can perhaps infer this fact from the IANA considerations that update that entry in the registry to also refer to this document, but it would be nice for the relationship to be more explicit. On Thu, Sep 13, 2018 at 08:51:45AM +1100, Ólafur Guðmundsson wrote: > On Tue, Sep 11, 2018 at 1:48 AM, Benjamin Kaduk wrote: > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-dnsop-refuse-any-07: Yes > > > > 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/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ > > > > > > > > -- > > COMMENT: > > -- > > > > I am balloting YES, because it is good to have these techniques available, > > but > > I also have some comments that I would like to see addressed or rebutted. > > > > The Shepherd writeup does not say why 1034/1035 are not mentioned in the > > Abstract. Also, the phrase "updates [103x] by" does not appear in the > > Introduction, leaving just section 7 to describe the changes. > > > > ---> > Section 1 has following text > > The DNS specification [RFC1034] [RFC1035] does not include specific >guidance for the behaviour of DNS servers or clients in this >situation. This document aims to provide such guidance. > > > Is that sufficient for readers ? I was coming at this from the perspective of the proposed IESG statement on the use of the "Updates" (see thread at https://www.ietf.org/mail-archive/web/ietf/current/msg109106.html), the wording or which would imply that a stronger statement is appropriate in this document. But the linked proposal is not yet in effect, and as such is non-binding. > > > The document doesn't really make it clear whether the "[t]he operator [] > > might choose not to respond to such queries" is restating an existing > > specification from some other document or making a new statement. > > > It is stating an operating practice Is this behavior permitted by the existing RFCs, or a grey area, or in contravention to the spec? > Section 1.1 > > > > As Mirja notes, draft-ietf-dnsop-terminology-bis is likely to replace 7719 > > by the time this document's publication process finishes. > > > > If that is published I hope RFC editor Auth48 phase will catch it > > > > Section 2 > > > > It seems like the intended takeaway here is that there's a balance or > > tradeoff to had between the "good" uses (efficiency of getting all desired > > data at once) and "bad" ones (amplification), with mining for zone data > > being a "dual-use technology". The text doesn't really help the reader > > reach that conclusion, though -- a few extra words at the start of each > > paragraph might help, like the "legitmiately used" in the very first one, > > or "On the other hand, ANY queries are frequently abused to [...]" might > > help set the intended tone. > > > > > IMHO there is no "good" use of ANY in the world but by the operator of the > server, > all other uses are based on misunderstanding or abuse, > others disagree. > Since this document was started the abuse of ANY has decreased against the > operators that have adopted the techniques in the document > but at the same time mo
[DNSOP] Benjamin Kaduk's Yes on draft-ietf-dnsop-refuse-any-07: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-refuse-any-07: Yes 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ -- COMMENT: -- I am balloting YES, because it is good to have these techniques available, but I also have some comments that I would like to see addressed or rebutted. The Shepherd writeup does not say why 1034/1035 are not mentioned in the Abstract. Also, the phrase "updates [103x] by" does not appear in the Introduction, leaving just section 7 to describe the changes. The document doesn't really make it clear whether the "[t]he operator [...] might choose not to respond to such queries" is restating an existing specification from some other document or making a new statement. Section 1.1 As Mirja notes, draft-ietf-dnsop-terminology-bis is likely to replace 7719 by the time this document's publication process finishes. Section 2 It seems like the intended takeaway here is that there's a balance or tradeoff to had between the "good" uses (efficiency of getting all desired data at once) and "bad" ones (amplification), with mining for zone data being a "dual-use technology". The text doesn't really help the reader reach that conclusion, though -- a few extra words at the start of each paragraph might help, like the "legitmiately used" in the very first one, or "On the other hand, ANY queries are frequently abused to [...]" might help set the intended tone. Section 4 Should "return a conventional ANY response" be listed or mentioned here? Section 4.2 [...] The specific value used is hence a familiar balance when choosing TTL for any RR in any zone, and be specified according to local policy. nit: Is there a missing word or three before "be"? DATA described in this seection to distinguish between synthesised and non-synthesised HINFO RRSets. nit: "section" I'm a little surprised to see a "SHOULD NOT" for relying the RDATA 'CPU' contents of "RFC" for the final RFC number, since I can't come up with an other reason why that CPU value would be used. But I do not object to it. Section 4.4 Why are we enumerating transports instead of talking about the properties they provide? We've got multiple new transports in the works, and it would be a shame to ignore them out of the gate. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-terminology-bis-13: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-terminology-bis-13: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ -- COMMENT: -- First off, thank you all for the effort that went into this document -- it's quite helpful to have a central resource to refer to. I agree with Mirja about further clarity for the 2308 updates being nice, and about the "primary master" definition's clarification. (The latter seems like it would meet a DISCUSS criterion, as internal inconsistency makes it difficult to have a clear specification. But it would be absurd to apply it here when the fix is clear.) I appreciate that "privacy of names" and "privacy of data associated with names" are called out as potential facets of a naming system to consider, but I would like to understand better why they are not given more treatment in this document. The surrounding text seems to imply that they are not needed to describe the DNS and that a pure lexicon need not explore the privacy considerations of the terms being defined; is this correct, and was there much discussion on this question? In a similar vein, it was a little surprising to only see the facets be expounded upon for the global DNS and not the other related naming systems, though it's unclear that there would be much non-overlap for the other systems considered. In Section 6: I'm a little confused about the interaction between "stealth server" and "hidden master" -- if a hidden master is a stealth server, it is "like a slave" and would thus be expected to get its configuration from yet another master? But this doesn't jibe with being listed as the MNAME. I accept that DNS terminology is a complicated area and there may not be a right answer, of course. The "privacy-enabling DNS server" definition seems too narrowly scoped to particular existing technologies as opposed to describing the properties provided (or mentioning the possibility for future protocols to be included). Is a DNS-over-HTTP server "privacy-enabling"? How about DNS-over-QUIC? Section 8 Interesting to see the term "Opt-Out zone" used but not defined in this document. (No action needed, and I do see the definition of "Opt-Out".) Finally, I am somewhat sympathetic to the indications that this document may (also) be appropriate as Informational; I look forward to seeing how that discussion unfolds. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)
On Thu, Aug 02, 2018 at 10:53:57AM -0400, Ted Lemon wrote: > On Thu, Aug 2, 2018 at 9:54 AM, Benjamin Kaduk wrote: > > > > We specifically didn’t want to reference DoH since HTTP is unsuitable > > for long lived connections and DSO wouldn’t apply here. We didn’t want to > > imply that DoH was suitable by referencing it. > > > > Hmm. I think DoH is clearly a non-UDP transport for DNS, and it is hard to > > argue that it is not being specified. My parenthetical suggestion was > > probably a bit unclear -- I was proposing to add DNS over HTTP to the list > > in the first sentence, and change the second sentence to start as "Some > > such transports can offer persistent[...]". Does that still seem like it > > runs the risk of implying that DoH is suitable, to you? > > > > Rr. Okay, I agree with you and when I went to do this, it occurred to me > that we are being silly here—this document has no applicability section. > Adding one will really clean this up a lot. So I've done that: > [diff trimmed] That does clean up quite a few things; thank you for putting in the effort to makme the broader change! (Do we care that we no longer talk about SRV discovery? I don't think I do, just wanted to check...) > > > > How about: > > > > > > When a new TLV is defined, the specification MUST include whether the > > DSO-TYPE can be used as the Primary TLV, used as an Additional TLV, or used > > in either context for both requests and responses. > > > > That's probably better (but maybe another comma before "for both requests > > and responses"? OTOH, the RFC Editor has a consistent style book to > > apply...) > > > > I updated the text to make it more generally imperative, and to be really > explicit about the point you're making rather than just hoping the comma > will be enough. :) > > Specifications that define new TLVs must specify whether the DSO-TYPE > can be used as the Primary TLV, used as an Additional TLV, or used in either > context, both in the case of requests and of responses. > The specification for a TLV must also state whether, > when used as the Primary (i.e., first) TLV in a DNS request message (i.e., > QR=0), > that DSO message is to be acknowledged. > If the DSO message is to be acknowledged, the specification > must also state which TLVs, if any, are to be included in the response. > The Primary TLV may or may not be contained in the response, > depending on what is specified for that TLV. The epitome of clarity :) Thanks again, Benjamin ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)
On Tue, Jul 31, 2018 at 03:53:57PM -0400, Tom Pusateri wrote: > > > > On Jul 27, 2018, at 11:24 AM, Benjamin Kaduk wrote: > > > > > > -- > > DISCUSS: > > -- > > > > Hopefully this first point is simple to resolve (whether by changing text > > or merely > > un-confusing me). The other ones may require some actual discussion, > > though. > > > > Section 6.6.1.2 has: > > > > After a DSO Session is ended by the server (either by sending the > > client a Retry Delay message, or by forcibly aborting the underlying > > transport connection) the client SHOULD try to reconnect, to that > > service instance, or to another suitable service instance, if more > > than one is available. > > > > which seems to contradict the text from Section 3: > > > > % [...] Given that these fatal error > > % conditions signify defective software, and given that defective > > % software is likely to remain defective for some time until it is > > % fixed, after forcibly aborting a connection, a client SHOULD refrain > > % from automatically reconnecting to that same service instance for at > > % least one hour. > > > > Given some other mentions in the document about aborting the connection, it > > may be that I am just reading the "refrain from reconnecting for an hour" > > more strongly than I should be. > > Section 3 discusses fatal errors on the server side that aren’t likely to > change until the software is modified so there’s no use having the client > retry quickly (hence the one hour). Section 6.6.1.2 is about receiving a > Retry Delay message and the server having the close the connection because > the client didn’t follow the spec and close the connection when asked. > > I think the difference can be described as Section 3 talks about how the > client deals with server bugs and Section 6.6.1.2 describes how the server > deals with client bugs. > > Does that help? That helps with the intent; I'll need some time to go through the document and see whether the document text matches the intent and I was just confused, or if I should suggest some text changes. > > > > Is Section 5.1.2 expected to be considered an "application protocol > > profile" that defines the use of TLS 1.3 0-RTT data for DSO? (If so, I do > > not personally feel that it provides adequate treatment to be considered as > > such.) > > > > > > I should probably leave this to my (transport-area?) colleagues to discuss > > further, but I'm not sure that the interaction of this mechanism with > > high-RTT connections is fully covered -- for example, the inactivity > > timeout in Section 6.4(.x) could behave poorly when the timeout is set to a > > smaller value than the RTT, as the server would potentially end up starting > > the "forcibly abort" process (and potentially causing the client to lose > > for an hour) because the server's timer starts when it sends the DSO > > response that initiates its idea of the session, and would not recieve > > graceful shutdown messages from a properly-behaving client in time. > > > > The 0 RTT discussion is also happening in another thread so I will not > address it here. > > > > > I'm not sure that the behavior specified in Section 7.1.2 is entirely safe. > > Consider when a client sends a DSO keepalive to try to request a DSO > > session, but subsequently sends EDNS(0) TCP Keepalive (whether "just in > > case" or for some other reason). The Server will receive the DSO keepalive > > and respond, creating a session, but the EDNS(0) TCP Keepalive is already > > in flight. I don't remember seeing any text that prevents this client > > behavior explicitly, but that seems like the right sort of thing to do. > > Ok, is this more clear? > > The inactivity timeout value in the Keepalive TLV (DSO-TYPE=1) has similar > intent to the edns-tcp-keepalive EDNS0 Option [RFC7828] > . > A client/server pair that supports DSO MUST NOT use the edns-tcp-keepalive > EDNS0 Option within any message after a DSO Session has been established. A > client that has sent a DSO message to establish a session MUST NOT send an > edns-tcp-keepalive EDNS0 Option from this point on. Once a DSO Session has > been established, if either client or server receives a DNS message over the > DSO Session that contains an edns-tcp-keepalive EDNS0 Option, this is a fatal > error and the
Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)
On Tue, Jul 31, 2018 at 04:14:41PM -0400, Tom Pusateri wrote: > > > > On Jul 31, 2018, at 3:53 PM, Tom Pusateri wrote: > > > >> > >> If the RCODE is set to any value other than NOERROR (0) or DSOTYPENI > >> ([TBA2] tentatively 11), then the client MUST assume that the server > >> does not implement DSO at all. In this case the client is permitted > >> to continue sending DNS messages on that connection, but the client > >> SHOULD NOT issue further DSO messages on that connection. > >> > >> I'm confused how the server would still have proper framing for subsequent > >> DNS messages, since the DSO TLVs would be "spurious extra data" after a > >> request header and potentially subject to misinterpretation as the start of > >> another DNS message header. > > > > Yes, this is a serious oversight. I think we are going to need to encode > > differently to make all the TLVs look like an RR externally so the RDLEN > > can be used to skip them and add a single count or switch the TLV syntax > > back to RR syntax. The existing DNS header format / RR format is less than > > ideal... > > > > My co-authors reminded me about the TCP framing for DNS which gives the > length of the DNS message so it can easily be skipped so this isn’t a problem. Ah, that would do the trick. It looks like I only chased up through the header format in 1035 and didn't scroll down to the "TCP usage" section. Sorry for the noise. -Benjamin ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)
Hi Mirja, On Mon, Jul 30, 2018 at 08:11:52PM +0200, Mirja Kuehlewind (IETF) wrote: > Hi Ben, hi all, > > as you summoned an TSV AD... > > > Am 27.07.2018 um 17:24 schrieb Benjamin Kaduk : > > > > I should probably leave this to my (transport-area?) colleagues to discuss > > further, but I'm not sure that the interaction of this mechanism with > > high-RTT connections is fully covered -- for example, the inactivity > > timeout in Section 6.4(.x) could behave poorly when the timeout is set to a > > smaller value than the RTT, as the server would potentially end up starting > > the "forcibly abort" process (and potentially causing the client to lose > > for an hour) because the server's timer starts when it sends the DSO > > response that initiates its idea of the session, and would not recieve > > graceful shutdown messages from a properly-behaving client in time. > > My understanding is that they require a minimum time-out of 5 second at the > server side, which seems reasonably safe to me. However, maybe this could be > further clarified or explained in the doc. I'm happy to defer to your expertise -- thanks! -Benjamin ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Spencer Dawkins' Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)
On Thu, Jul 26, 2018 at 09:33:20PM -0700, Spencer Dawkins wrote: > -- > COMMENT: > -- [snip] > > This next one is well within the "Spencer wouldn't have done it this way, but > Spencer's not the working group, or the IETF" range, but > > However, in the typical case a server will not know in advance >whether a client supports DSO, so in general, unless it is known in >advance by other means that a client does support DSO, a server MUST >NOT initiate DSO request messages or DSO unacknowledged messages >until a DSO Session has been mutually established by at least one >successful DSO request/response exchange initiated by the client, as >described below. Similarly, unless it is known in advance by other >means that a server does support DSO, a client MUST NOT initiate DSO >unacknowledged messages until after a DSO Session has been mutually >established. > > seems fragile, especially in environments where clients can come and go, and > servers may be addressed using anycast (so I knew in advance that the four > servers at that anycast address supported DSO, but somebody installed a fifth > server that does not). Is that unlikely to be a problem? Note that the client is only prohibted from using "unacknowledged" (one-shot) messages -- it can send always normal requests and use the presence of a reply to determine server support, on this connection. So this seems like a pretty vanilla "client initiates" thing, if I understand correctly. -Benjamin [snip] ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-session-signal-12: Discuss 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ -- DISCUSS: -- Hopefully this first point is simple to resolve (whether by changing text or merely un-confusing me). The other ones may require some actual discussion, though. Section 6.6.1.2 has: After a DSO Session is ended by the server (either by sending the client a Retry Delay message, or by forcibly aborting the underlying transport connection) the client SHOULD try to reconnect, to that service instance, or to another suitable service instance, if more than one is available. which seems to contradict the text from Section 3: % [...] Given that these fatal error % conditions signify defective software, and given that defective % software is likely to remain defective for some time until it is % fixed, after forcibly aborting a connection, a client SHOULD refrain % from automatically reconnecting to that same service instance for at % least one hour. Given some other mentions in the document about aborting the connection, it may be that I am just reading the "refrain from reconnecting for an hour" more strongly than I should be. Is Section 5.1.2 expected to be considered an "application protocol profile" that defines the use of TLS 1.3 0-RTT data for DSO? (If so, I do not personally feel that it provides adequate treatment to be considered as such.) I should probably leave this to my (transport-area?) colleagues to discuss further, but I'm not sure that the interaction of this mechanism with high-RTT connections is fully covered -- for example, the inactivity timeout in Section 6.4(.x) could behave poorly when the timeout is set to a smaller value than the RTT, as the server would potentially end up starting the "forcibly abort" process (and potentially causing the client to lose for an hour) because the server's timer starts when it sends the DSO response that initiates its idea of the session, and would not recieve graceful shutdown messages from a properly-behaving client in time. I'm not sure that the behavior specified in Section 7.1.2 is entirely safe. Consider when a client sends a DSO keepalive to try to request a DSO session, but subsequently sends EDNS(0) TCP Keepalive (whether "just in case" or for some other reason). The Server will receive the DSO keepalive and respond, creating a session, but the EDNS(0) TCP Keepalive is already in flight. I don't remember seeing any text that prevents this client behavior explicitly, but that seems like the right sort of thing to do. -- COMMENT: -- Six authors exceeds five, so "there is likely to be discussion" about this being too large a number of authors. What is the justification for the author count? Do we need to specify some GREASE (per draft-ietf-tls-grease) for new TLV types in order to ensure the proper handling of unknown types? Section-by-section comments follow. Section 1 A DoH reference seems timely/apt. (But maybe then it is only "Some such transports" that can offer persistent sessions.) Maybe give some examples of advantages of server-initiated messages? Are we talking about letting the server push records with larger TTLs or notifying when the response to a query is changing, or just more mundane keepalive-type things? Section 3 The terms "initiator" and "responder" correspond respectively to the initial sender and subsequent receiver of a DSO request message or unacknowledged message, regardless of which was the "client" and "server" in the usual DNS sense. We just defined "client" and "server" explictly (without reference to the "usual DNS sense"), so probably it's best to have this definition refer to the previous client/server definitions or clarify that the above definitions match the "usual DNS sense". When an anycast service is configured on a particular IP address and port, it must be the case that although there is more than one physical server responding on that IP address, each such server can be treated as equivalent. If a change in network topology causes p
