[DNSOP] Re: Introducing Relative Label for DNS
Dear all, Today, I released a new version of the draft: https://datatracker.ietf.org/doc/html/draft-yocto-dns-relative-label-02. I replaced the term "record" with "resource record", updated the reference to the EDNS RFC, and added an Acknowledgements section. @Peter Thomassen: Is it possible to make some list with all interop problems for this draft? With such list, I can look for ways to address them; or that I conclude to reframe the draft to be for confined systems only. Ben Ben van Hartingsveldt schreef op 2024-07-23 08:56: Dear all, Today, I released a new version of the draft: https://datatracker.ietf.org/doc/html/draft-yocto-dns-relative-label-01. I tried to clarify things a little bit more, added some examples and fixed some references. Ben Ben van Hartingsveldt schreef op 2024-07-21 18:50: Dear all, In the recent years I started working on my own coded DNS server, because I was done with the synchronization between BIND and DirectAdmin that broke all the time. It resulted in a Java server that is running on 4 IPs for some years now. Because of this, I had to read many RFCs to have it pass tests like Zonemaster, DNSViz, IntoDNS, etc. While reading and implementing things, I also came across some shortcomings of DNS. On advice of someone at SIDN, I will share my draft that I published today. It solves one of the shortcomings that DNS has in its core: relative domain names. I'm talking about https://datatracker.ietf.org/doc/html/draft-yocto-dns-relative-label-00. This draft is meant to solve the problem that we cannot use relative domain names in the DNS system, specificly in DNS UPDATE and in binary zone files. This also means that this draft is not meant for use with the QUERY opcode (except for possibly AXFR and IXFR). Let me explain those two usecases. 1) DNS UPDATE: In DNS UPDATE it is possible to update the zone using DNS itself. This can be used in routers when dynamic DNS is wanted, but also in other situations. Imagine wanting to add an MX record. Using a webinterface, you are likely able to chooses one of the following four options: - mail IN MX 10 mx - mail IN MX 10 mx.example.com. - mail.example.com. IN MX 10 mx - mail.example.com. IN MX 10 mx.example.com. However, using DNS UPDATE you are only able to add the record with fourth format; both record name and FQDN field have to be absolute. This means that when I return to the webinterface, I will likely see absolute domain names, even when I use relative domain names in my other records. My draft wants to give the client more control over when to use relative and when to use absolute domain names by adding a new label type. 2) Binary Zone Files: Since BIND 9, it is possible to save zones in a binary format. This is possible to enable/disable using `masterfile-format`. It is possible to convert the textual format to binary and vice versa. However, when converting to binary, the zone file will loose the knowledge of knowing which domain names where absolute and which where relative. This means that converting the zone back from binary to text will likely give you a zone with only absolute domain names. As with DNS UPDATE, this is a shortcoming of the wire format used by DNS. That is why I wrote this draft. Like BIND, my own DNS system also uses binary zone storage and in the future I'm planning to implement DNS UPDATE too. I also believe my draft is not yet perfect. I'm not a native English speaker and maybe just format to mention something important. That is why I want you to give your honest opinion on this topic. Do you agree with the problem? Does DNS need such label? Did I make a typo? Etc. Please let me know. Thanks in advance Ben van Hartingsveldt ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Secdir last call review of draft-ietf-dnsop-rfc8109bis-05
Reviewer: Mališa Vučinić Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. This document updates RFC 8109. It describes the steps needed for Recursive DNS resolvers to obtain names and addresses of the root servers based on initial configuration, a common implementation choice. I believe this document is Ready with Nits. Please find below two questions I had while going through the document. Section 4.1: “The priming response MUST have an RCODE of NOERROR, and MUST have the Authoritative Answer (AA) bit set. Also, it MUST have an NS RRset in the Answer section (because the NS RRset originates from the root zone), and an empty Authority section (because the NS RRset already appears in the Answer section). There will also be an Additional section with A and/or RRsets for the root servers pointed at by the NS RRset.” The original text in RFC 8109 uses the term “expected” to denote the properties of the priming response. Given that the root server cannot distinguish a priming query from any other query for the root NS RRset, I don’t see how changing “expected” used in RFC 8109 to a normative keyword “MUST” makes sense here? Section 6: “An on-path attacker who sees a priming query coming from a resolver can inject false answers before a root server can give correct answers.” How can an on-path attacker differentiate the normal query from a priming query if a root server cannot? I guess the text above is valid for any query, not just for a priming query. Perhaps it should be rephrased to read as such. ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: Potentially interesting DNSSEC library CVE
> The IETF does not create standards for APIs. So a validating stub resolver is > > not really something that can be defined, because it is not a protocol. I beg to differ here. It may not be strictly part of the DNS protocol, but then this logic needs to be a part of every single protocol dependent on DNS. Consider e.g. IMAP, something which clearly is a network protocol. There is a very convenient RFC 6186, specifying how to use DNS to locate an IMAP service. Even if you would not call this a network protocol, it clearly is within IETF scope (and on Standards Track). TL;DR: The TLS-secured IMAP server for localp...@domain.tld is whatever the SRV record at _imaps._tcp.domain.tld points at, and you can proceed sending localpart's password there in an attempt to authenticate. It should be clear that there are problems which may arise in this protocol if the used SRV records' targets can be influenced by an attacker. To do some damage control, RFC 6186 thus specifies: > In the absence of a secure DNS option, MUAs SHOULD check that the target FQDN returned in the SRV record matches the original service domain that was queried. If the target FQDN is not in the queried domain, MUAs SHOULD verify with the user that the SRV target FQDN is suitable for use before executing any connections to the host. What exactly does "secure" mean here? Which SRV records are to be investigated exactly? Most protocols do not tell, instead referring to the DNS. If effect, this gap between protocols is what leads to problems, and there is no specification that seems to have adequate security considerations addressing these points. Keep in mind, IMAP is only an example here. To ensure the security of network protocols all throughout the IETF (and beyond), there has to be a clear API. Not for applications, but for other protocols. As a related example: HKDF defines an API, which most client libraries do not copy exactly. This is fine, but the clear definition allows e.g. TLS to depend on HKDF, and be a verifiably secure protocol. The same should apply to DNS and its interaction with the wider internet. -- Thomas smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Domain Connect update
Hi, After the presentation by regext this week it turned out that this work can be also of interest of dnsop WG. Few slides from regext show especially the current implementation status and adoption https://datatracker.ietf.org/meeting/120/materials/slides-120-regext-sessa-domain-connect-update There is a refreshed draft, not yet clear which WG would be appropriate to proceed with this work however there was good feedback and support in the regext session to solve this "issue" https://datatracker.ietf.org/doc/draft-kowalik-regext-domainconnect/ I was also asked by few people already about applicability of Domain Connect for other use cases, like provisioning parent-side RRs through registrar channel (DNSSEC bootstrapping, change of delegation etc.). This is not yet covered but an interesting future work IMHO. Kind regards, Pawel OpenPGP_0xABB62115F7BCDB04.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [EXT] [dtn] Re: An Interplanetary DNS Model
Scott, Yes, new qualified names (identifiers) for new things will disambiguate from existing names. The important thing is to avoid a truly "split horizon" DNS situation where the same qualified name means different things in different contexts (the lack of specific records visible from a context is different than records with different meaning though). The DNS already provides a facility to have human-facing relative/unqualified names while the tools resolve to and manage qualified names, so there isn't a need for new terms or techniques here. > -Original Message- > From: Scott Johnson > Sent: Thursday, July 25, 2024 12:24 PM > To: Sipos, Brian J. > Cc: Marc Blanchet ; Lorenzo Breda > ; DTN WG ; dnsop > Subject: Re: [DNSOP] Re: [EXT] [dtn] Re: An Interplanetary DNS Model > > APL external email warning: Verify sender sc...@spacelypackets.com before > clicking links or attachments > > Hi Brain, > > Are you in concurrance that using new, dedicated TLDs only for off world use > (and discrete to a single world) solves this issue? > > Thanks, > ScottJ > > On Thu, 25 Jul 2024, Sipos, Brian J. wrote: > > > All, > > I'm replying to a non-specific message in this chain just to mention that, > > similar > to what Lorenzo brought up, any translation of identifiers (names or > addresses) > will be fraught with problems related to security and should not be done. > There > can be translation or mapping that happens in a way not visible to > users/clients, > but whatever identifiers are visible to the user/client need to have stable > meaning across any network. > > > > Naming authorities, such as PKIX CAs, need to rely on the fact that once a > > user > proves ownership of a specific identifier that same identifier will not be > used by > other users (at least not simultaneously over a short time interval). Part of > the > reason why public CAs such as Let's Encrypt will not issue certificates for IP > addresses is the prevalence of IP NATs, even though IP identifiers are > allowed by > the CA/Browser TLS baseline [1]. > > > > [1] > > https://cabforum.org/working-groups/server/baseline-requirements/docum > > ents/CA-Browser-Forum-TLS-BR-2.0.5.pdf > > > >> -Original Message- > >> From: Scott Johnson > >> Sent: Wednesday, July 24, 2024 4:44 PM > >> To: Marc Blanchet > >> Cc: Lorenzo Breda ; DTN WG ; dnsop > >> > >> Subject: [EXT] [dtn] Re: [DNSOP] An Interplanetary DNS Model > >> > >> APL external email warning: Verify sender > >> forwardingalgori...@ietf.org before clicking links or attachments > >> > >> Hi Marc, > >> > >> On Wed, 24 Jul 2024, Marc Blanchet wrote: > >> > >>> > >>> > >>> Le 24 juill. 2024 à 11:42, Lorenzo Breda > >>>a écrit : > >>> > >>> > >>> Why are you against leaving the current TLDs implicitly on Earth by > >>> default? > >>> > >>> > >>> Right. One do not need a special TLD for space. We can use what we > >>> have and it just works fine. > >> > >> I do not disagree with this notion as respects my proposed architecture. > >> 3rd level domains mapped to off-world domains works just fine, for > >> the low low price of annual domain renewal. a tld representing each > >> remote world is preferable, however, because it is just "cooler;" > >> easier to use and more memorable than a much longer domain. This, > >> however, assumes we are talking about the same proposal, which we are > not. > >> > >>> One has just to be careful on remote resolution so that it contains > >>> what is needed: trust chain, local names, ... > >>> > >> > >> Lets be clear here, Marc. You are talking about a completely > >> different solution than I am; one predicated on IP only. Your > >> comment on this thread, without context, only serves to confuse the other > participants. > >> > >> For example, you are talking about using F-root, right? That is a > >> very different thing than the functionality which I am describing, > >> with significantly more network resource usage requirements. My > >> solution uses BP in some network segments. Personally, I don't think > >> your method will ever fly, primarily due to security reasons, but I > >> don't troll your threads about it in a manner which would muddy the > >> waters of those considering your proposal. I don't mind healthy > >> competition of ideas, but I do expect fair play. If you wish to > >> contrast the two methods, thats fine, yet unproductive, IMHO. Just make > sure the reader knows you are talking about your proposal, and not mine. > >> > >> ScottJ > >> > >> > >> > >>> This is discussed in: > >>> - running IP in deep space (noBP<->IP): > >>> https://www.ietf.org/archive/id/draft-many-deepspace-ip-asse > >>> ssment-01.txt > >>> - running DNS in remote places: > >>> https://www.ietf.org/archive/id/draft-many-dnsop-dns-isolated-networ > >>> k > >>> s-01.txt > >>> > >>> > >>> Regards, Marc. > >>> > >>> > >>> > >>> -- > >>> Lorenzo Breda > >>> ___ > >>> dtn mailing list
[DNSOP] Re: Potentially interesting DNSSEC library CVE
> On 25 Jul 2024, at 05:49, Martin Schanzenbach wrote: > > > > On Thu, 2024-07-25 at 14:39 +0200, Philip Homburg wrote: >>> As hinted to in the CVE description, Thomas asked here where this >>> behaviour is defined exactly and did not receive a response that >>> fits this issue: >>> https://mailarchive.ietf.org/arch/msg/dnsop/X7ul3Updo4XP0EYdExuZ6pkp-Gk/ >>> >>> Yes, of course a stub resolver will have to sift through the CNAMEs >>> (especially if DNSSEC validation is supposed to be done). But >>> where is the filtering between QNAME and received answers >>> explicitly >>> defined, exactly? >> >> By and large, the IETF defines network protocols. The IETF is not >> good >> a defining APIs for network functions. And it is not part of its core >> mission. >> >> So what happens after a stub resolver receives a response is mostly >> undefined. Low level C APIs were done in the past by the IEEE (POSIX) >> and more >> recent by the Open Group. >> >> For example RFC 3493 is not an IETF standard, but the functions >> described, >> such as getaddrinfo, are part of the Single Unix Specification. >> >>> I am pointing out that there is a root cause >>> for this CVE/bug and it may not be simple oversight. It very well >>> may be a gap in specification or missing security considerations >>> that could hit any future implementer of (stub) resolvers. >> >> The gap is that there is no good standards organisation for APIs >> related to >> internet protocols. That is unfortunate. It is not clear to me who >> would >> have enough cloud to create one. > > Are you trying to say that the behaviour of a validating stub resolver > is not in scope of the work on DNS(SEC)? > Because I was pretty sure it is. > See Thomas' post before on how separating validation from result > filtering (following the CNAME-chain) would be tricky to do outside of > the validating stub resolver (or only with significant overhead and re- > validation) for any implementation. DNSSEC was designed to be done in the client. Recursive servers return records that are needed to get from the original QNAME to the answer. Stub resolvers are expected to be able follow CNAME/DNAME and HTTPS/SVCB chains if those are the query type. If you request DNSSEC records you will also get back RRSIGs, NSEC and/or NSEC3 records which prove the none existence of the type or QNAME name. This is just RFC 1034, RFC 4034 and a couple of others in action. Now an application may call a library routine to perform this work on its behalf. gethostbyname and getaddrinfo are examples of these. Other applications directly parse the raw DNS message, MTAs typically fall into this class. If the libraries are DNSSEC aware then they should fail if the answers they are returning are unable to be validated as secure or insecure. For some applications the library routine can also return whether the answer was secure or insecure. The application or the library may make additional DNS requests to be able to validate the original response. These requests will typically be DNSKEY and DS queries. The difference between a stub resolver and a iterative resolver is who follows the referrals. Mark > BR > ___ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: Introducing Relative Label for DNS
This is not needed. Additionally when answers are returned the zone is not known. This is true of both stub resolvers and non validating recursive resolvers. As for your MX example one could use existing DNS compression mechanisms on the wire and when storing the record if desired by using an offset into the owner name of the record. For unknown record types one would also have to record the original case of the owner name and this is also desirable to known types. None of this however requires a RFC to do. This is not worth it for saving a few bytes in a DNS message. e.g. storage MX <07>example<03>com<00> 0<02>mx<13-bits-of-upper-case-flags> some other now defined type that the server knows <07>example<03>com<00> <09>example01<13-bits-of-upper-case-flags> We do something similar in BIND for case preservation of owner names. The data is all in lower case and we restore the upper case before doing case sensitive DNS name compression on the answer. As for using the new label in UPDATE you would need to know that the server supports the label type. Remember for types that it knows about it will be decoding the name to prevent garbage being inserted. Mark > On 26 Jul 2024, at 02:07, Ben van Hartingsveldt > wrote: > > Dear all, > > Today, I released a new version of the draft: > https://datatracker.ietf.org/doc/html/draft-yocto-dns-relative-label-02. I > replaced the term "record" with "resource record", updated the reference to > the EDNS RFC, and added an Acknowledgements section. > > @Peter Thomassen: Is it possible to make some list with all interop problems > for this draft? With such list, I can look for ways to address them; or that > I conclude to reframe the draft to be for confined systems only. > > Ben > > Ben van Hartingsveldt schreef op 2024-07-23 08:56: >> Dear all, >> Today, I released a new version of the draft: >> https://datatracker.ietf.org/doc/html/draft-yocto-dns-relative-label-01. I >> tried to clarify things a little bit more, added some examples and fixed >> some references. >> Ben >> Ben van Hartingsveldt schreef op 2024-07-21 18:50: >>> Dear all, >>> In the recent years I started working on my own coded DNS server, because I >>> was done with the synchronization between BIND and DirectAdmin that broke >>> all the time. It resulted in a Java server that is running on 4 IPs for >>> some years now. Because of this, I had to read many RFCs to have it pass >>> tests like Zonemaster, DNSViz, IntoDNS, etc. While reading and implementing >>> things, I also came across some shortcomings of DNS. On advice of someone >>> at SIDN, I will share my draft that I published today. It solves one of the >>> shortcomings that DNS has in its core: relative domain names. >>> I'm talking about >>> https://datatracker.ietf.org/doc/html/draft-yocto-dns-relative-label-00. >>> This draft is meant to solve the problem that we cannot use relative domain >>> names in the DNS system, specificly in DNS UPDATE and in binary zone files. >>> This also means that this draft is not meant for use with the QUERY opcode >>> (except for possibly AXFR and IXFR). Let me explain those two usecases. >>> 1) DNS UPDATE: In DNS UPDATE it is possible to update the zone using DNS >>> itself. This can be used in routers when dynamic DNS is wanted, but also in >>> other situations. Imagine wanting to add an MX record. Using a >>> webinterface, you are likely able to chooses one of the following four >>> options: >>> - mail IN MX 10 mx >>> - mail IN MX 10 mx.example.com. >>> - mail.example.com. IN MX 10 mx >>> - mail.example.com. IN MX 10 mx.example.com. >>> However, using DNS UPDATE you are only able to add the record with fourth >>> format; both record name and FQDN field have to be absolute. This means >>> that when I return to the webinterface, I will likely see absolute domain >>> names, even when I use relative domain names in my other records. My draft >>> wants to give the client more control over when to use relative and when to >>> use absolute domain names by adding a new label type. >>> 2) Binary Zone Files: Since BIND 9, it is possible to save zones in a >>> binary format. This is possible to enable/disable using >>> `masterfile-format`. It is possible to convert the textual format to binary >>> and vice versa. However, when converting to binary, the zone file will >>> loose the knowledge of knowing which domain names where absolute and which >>> where relative. This means that converting the zone back from binary to >>> text will likely give you a zone with only absolute domain names. As with >>> DNS UPDATE, this is a shortcoming of the wire format used by DNS. >>> That is why I wrote this draft. Like BIND, my own DNS system also uses >>> binary zone storage and in the future I'm planning to implement DNS UPDATE >>> too. I also believe my draft is not yet perfect. I'm not a native English >>> speaker and maybe just format to mention
[DNSOP] Re: [Ext] New draft on collision free key tags in DNSSEC
It appears that Paul Hoffman said: >The problems are listed as: > >Colliding key tags impose additional work on a validating resolver, which then >has to check >signatures for each of the candidate set of keys identified by the Key Tag. >Furthermore, they >open up resolvers to computational denial of service attacks by adversaries >deploying specially >crafted zones with many intentionally colliding key tags [KEYTRAP]. I don't see why this is a problem that needs to be solved. I did a survey of the names in all the large gTLD zones and I never found more than a single collision per delegated zone. Resolvers can stop after, say, three collisions with a negligible chance of losing real DNS data. (Zones built with deliberate collisions don't count.) This is just one more implementation limit that started with the CNAME limit suggested in 1035. I suppose we can suggest that people adjust their key generation systems to check the old and new keys, and regnerate the new key if there's a collision, but that is a minor and not very important tweak. R's, John ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] New draft on collision free key tags in DNSSEC
This expectation setting. Adjusting key generation won’t happen unless there is a written requirement for it to happen. If we where to say duplicate keys tags are no longer supported as of date X there is no way the operators of all the existing signed zones with duplicate tags would know to perform key rolls. We have a chance that when new algorithms are added the key generation software will be updated to enforce uniqueness (for all algorithm). Operators of zones that generate duplicate tags and have the validation fail will not have a leg to stand on with their complaints. "Go tell your vendor to fix their software" will be the response. Even if we where to go with one failure is allowed we still need to write down the new rules and there will be complaints that we are retrospectively changing the rules. This is grand fathering in the old rules for the old algorithms. Mark > On 26 Jul 2024, at 14:55, John Levine wrote: > > It appears that Paul Hoffman said: >> The problems are listed as: >> >> Colliding key tags impose additional work on a validating resolver, which >> then has to check >> signatures for each of the candidate set of keys identified by the Key Tag. >> Furthermore, they >> open up resolvers to computational denial of service attacks by adversaries >> deploying specially >> crafted zones with many intentionally colliding key tags [KEYTRAP]. > > I don't see why this is a problem that needs to be solved. I did a > survey of the names in all the large gTLD zones and I never found more > than a single collision per delegated zone. Resolvers can stop after, > say, three collisions with a negligible chance of losing real DNS > data. (Zones built with deliberate collisions don't count.) This is > just one more implementation limit that started with the CNAME limit > suggested in 1035. > > I suppose we can suggest that people adjust their key generation > systems to check the old and new keys, and regnerate the new key if > there's a collision, but that is a minor and not very important tweak. > > R's, > John > > ___ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: Fwd: New Version Notification - draft-ietf-dnsop-domain-verification-techniques-05.txt
On Wed, Jul 24, 2024 at 10:18 AM Shumon Huque wrote: > > On your last point, yes, I think we can say that if a verifier sees > multiple > validation records, they can abort. > > I'd think it would be better to allow looking at the full RRset and succeeding if any of the records match? This seems less likely to be surprising to operators and more robust against things like name conflicts, forgetting to remove records, etc. (ie, this is being generous with what is accepted but in a way that shouldn't impact the security properties.). We should be explicit either way though. Erik ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: Fwd: New Version Notification - draft-ietf-dnsop-domain-verification-techniques-05.txt
On Fri, 26 Jul 2024, Erik Nygren wrote: On your last point, yes, I think we can say that if a verifier sees multiple validation records, they can abort. I'd think it would be better to allow looking at the full RRset and succeeding if any of the records match? No. These records are supposed to be at unique prefixed names. If there's more than one record at the name, something is wrong. Remember that the robustness principle says to be liberal *when the spec is unclear*. When the spec is clear and the data is wrong, reject it. R's, John ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] New draft on collision free key tags in DNSSEC
Even if we where to go with one failure is allowed we still need to write down the new rules and there will be complaints that we are retrospectively changing the rules. This is grand fathering in the old rules for the old algorithms. Write a BCP, not a standard disallowing key id clashes. Right. We all know that flag days never happen, so that resolvers will always have to include too many keytags or signatures in the list of things to limit the work. So remind people that there's going to be a limit, and if you are smart your zones won't go anywhere near it, and move on. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] [Technical Errata Reported] RFC7901 (8053)
The following errata report has been submitted for RFC7901, "CHAIN Query Requests in DNS". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid8053 -- Type: Technical Reported by: Mark Andrews Section: 8.3 Original Text - 8.3. Nonexistent Data A recursive resolver receives a query for the A record for "ipv6.toronto.redhat.ca". It includes the CHAIN option with the following parameters: o Option-code, set to 13 o Option-length, set to 0x00 0x03 o The closest trust point set to "ca." Corrected Text -- 8.3. Nonexistent Data A recursive resolver receives a query for the A record for "ipv6.toronto.redhat.ca". It includes the CHAIN option with the following parameters: o Option-code, set to 13 o Option-length, set to 0x00 0x04 o The closest trust point set to "ca." Notes - The value of the option is 0x02 0x63 0x61 0x00 which has length 4 not 3. Instructions: - This erratum is currently posted as "Reported". (If it is spam, it will be removed shortly by the RFC Production Center.) Please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party will log in to change the status and edit the report, if necessary. -- RFC7901 (draft-ietf-dnsop-edns-chain-query-07) -- Title : CHAIN Query Requests in DNS Publication Date: June 2016 Author(s) : P. Wouters Category: EXPERIMENTAL Source : Domain Name System Operations Stream : IETF Verifying Party : IESG ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: Potentially interesting DNSSEC library CVE
> On 26 Jul 2024, at 04:41, Bellebaum, Thomas > wrote: > >> The IETF does not create standards for APIs. So a validating stub resolver >> is >> not really something that can be defined, because it is not a protocol. > > I beg to differ here. It may not be strictly part of the DNS protocol, but > then this logic needs to be a part of every single protocol dependent on DNS. > > Consider e.g. IMAP, something which clearly is a network protocol. There is a > very convenient RFC 6186, specifying how to use DNS to locate an IMAP > service. Even if you would not call this a network protocol, it clearly is > within IETF scope (and on Standards Track). > TL;DR: The TLS-secured IMAP server for localp...@domain.tld is whatever the > SRV record at _imaps._tcp.domain.tld points at, and you can proceed sending > localpart's password there in an attempt to authenticate. > > It should be clear that there are problems which may arise in this protocol > if the used SRV records' targets can be influenced by an attacker. To do some > damage control, RFC 6186 thus specifies: > >> In the absence of a secure DNS option, MUAs SHOULD > check that the target FQDN returned in the SRV record matches the > original service domain that was queried. If the target FQDN is not > in the queried domain, MUAs SHOULD verify with the user that the SRV > target FQDN is suitable for use before executing any connections to > the host. > > What exactly does "secure" mean here? DNSSEC signed and validated as secure. > Which SRV records are to be investigated exactly? From the example above the ones returned by the query for _imaps._tcp.domain.tld. If the target in the SRV records rdata do not end in the labels domain.tld then ask the user if we should trust this response. If the target was imap.domain.tld then the IMAP client doesn’t have to ask the user. There is some risk here as the additional A and records could be compromised. Additionally if there is a CNAME returned the target of that need to be below domain.tld or raise a flag. This applies to the whole CNAME chain. Now the IMAP client could as the user whenever the DNS response was not signed and validated as secure but the above was a pragmatic response to the slow deployment of DNSSEC. Remember the IMAP client can use DNSSEC to verify the answers returned. That is the desired end state for DNSSEC. Having resolvers verify answers is just protecting the caches from garbage. > Most protocols do not tell, instead referring to the DNS. > > If effect, this gap between protocols is what leads to problems, and there is > no specification that seems to have adequate security considerations > addressing these points. Keep in mind, IMAP is only an example here. To > ensure the security of network protocols all throughout the IETF (and > beyond), there has to be a clear API. Not for applications, but for other > protocols. DNSSEC’s job is to ensure the client can verify the answers it receives are as they where entered. If the answers are provably not signed you are running on a wing and a prayer. If you don’t bother to check if they are signed you are running on a wing and a prayer. > As a related example: HKDF defines an API, which most client libraries do not > copy exactly. This is fine, but the clear definition allows e.g. TLS to > depend on HKDF, and be a verifiably secure protocol. The same should apply to > DNS and its interaction with the wider internet. People have been told to sign their zones and to verify the answers. We have millions of resolver out there that are trying to verify as secure every response they get. > > -- Thomas > ___ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
