Re: [DNSOP] Time to update RSAMD5 and perhaps DSA (algs 1 and 3) to MUST NOT?
On Sat, 1 Dec 2018, Viktor Dukhovni wrote: The IANA DNSSEC parameter registry lists RSAMD5 (algorithm 1) as deprecated, and refers to [RFC3110], [RFC4034] which state that RSAMD5 is "NOT RECOMMENDED". https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1 And our draft is going further and says you MUST NOT implement it :) https://tools.ietf.org/html/draft-ietf-dnsop-algorithm-update-04#section-3.1 This suggests to me that the deprecation of RSAMD5 is a stunning success, it is gone, and perhaps it is time to say so: I think more that it never really saw any deployment, so it seems a little weird to claim success here. It shouldn't ever have gotten an allocation even back then :P * Authoritative zones SHOULD NOT publish RSAMD5 DS RRs or DNSKEY records. * Validating resolvers MUST ignore RSAMD5 DS RRs and DNSKEY RRs, and MUST treat any zones with only ignored or unsupported DS records as "insecure". How weak. We went for MUST NOT :) Perhaps we could be bolder and say the same for DSA (algorithm 3), Funny, we also have MUST NOT there :) this too is largely gone, but there's a cluster of ~4700 ".me" domains with DSA keys. It is not clear that enabling those domains to validate merits ongoing support for algorithm 3. So we might also add DSA to the list, encouraging resolver implementations to drop support for both RSAMD5 and DSA. Done, as soon as the document gets a write up and goes into IETF LC :) ping chairs :) Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Time to update RSAMD5 and perhaps DSA (algs 1 and 3) to MUST NOT?
The IANA DNSSEC parameter registry lists RSAMD5 (algorithm 1) as deprecated, and refers to [RFC3110], [RFC4034] which state that RSAMD5 is "NOT RECOMMENDED". https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1 "Survey says" that RSAMD5 is not only deprecated, but is in fact no longer used, by any of the ~9 million DNSSEC-delegated domains I've been able to find on the public Internet: https://lists.dns-oarc.net/pipermail/dns-operations/2018-December/018146.html It only has the effect of breaking two domains that have only RSAMD5 in the DS RRset, but have no DNSKEY RRs. 11 domains, have working keys for algorithms 5, 7, 8 or 13 with a DS RRset that also lists an orphaned algorithm 1 with no RSAMD5 keys at the zone apex. A further 18 domains have RSAMD5 DS RRs, but are simply out of service even sans validation. This suggests to me that the deprecation of RSAMD5 is a stunning success, it is gone, and perhaps it is time to say so: * Authoritative zones SHOULD NOT publish RSAMD5 DS RRs or DNSKEY records. * Validating resolvers MUST ignore RSAMD5 DS RRs and DNSKEY RRs, and MUST treat any zones with only ignored or unsupported DS records as "insecure". Perhaps we could be bolder and say the same for DSA (algorithm 3), this too is largely gone, but there's a cluster of ~4700 ".me" domains with DSA keys. It is not clear that enabling those domains to validate merits ongoing support for algorithm 3. So we might also add DSA to the list, encouraging resolver implementations to drop support for both RSAMD5 and DSA. -- Viktor. ___ 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, 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. We employed manual trust anchors at different phases of our implementation, but now have very few in place. One is to establish trust for an internal zone for which we do not control the administration of the parent zone. So the interesting question here is, how is this one zone securely resolved when you are connected to the network via a VPN? Or is this zone not available for VPN users? And if this draft could make it available, would you? Or, do your VPN users not use split-tunnel, and connect to an inside DNS server once connected? This scheme seems to require both inside and outside zones are signed with the same key, or as Mark pointed out, both internal and external zones need to share their DS records and keep these in sync. As these are usually different organisations/groups/vendors/services, that is an actual management problem. Or you can do what we did and place DS records for both the internal and external KSKs (using public placeholder versions of the internal child zones just to establish the delegation point) in the parent zone. That establishes chain of trust whichever version of the zone is resolved. That works whether the public version is just a placeholder with nothing else of significance in it or if it is a zone where both the external and internal records matter and are used by the appropriate source for the query, but differ. That is a good solution as well. Although I would be a little worried that a compromise of the public view could trick people into establishing the "internal" zones in the external view to trick people into logging on and giving out their password. But that is surely far down the list of easy attacks to run. I don't really have any thoughts on the draft itself That is too bad, because I'd be very curious how you handle DNSSEC with your VPN clients. Not many large organizations run DNSSEC on both internal and external views. So I am curious how you handle DNSSEC for your (split?) VPN clients. But I understand if you cannot share more data about that in a public forum. , but wanted to add my own real world experience with managing DNSSEC trust. On the validation side, we also don't allow any device in the enterprise network, including internal nameservers, to send or receive DNS queries to the Internet. Period. Only our perimeter recursive, DNS caches can do that and those will only accept queries from authorized enterprise recursive, caching nameservers. And we have protections, including different DNS blacklists, at each layer. So we have a lot of control over what devices connected to our network can and cannot do and they do not have unrestricted ability to query Internet DNS even through our multiple layers. We also use the cli version of dnsviz a lot to ensure we understand what different points on the recursive side of our enterprise DNS infrastructure are seeing. So I guess the interesting thing here is the device that is in split-tunnel mode. It would not receive the protection of your DNS infrastructure for external lookups, so if you allow BYOD to connect to your network, it would be bypassing those DNS security checks for non-organisation DNS queries, which would put the BYOD under greater risk. Perhaps you do not allow split-tunnel or BYOD for those reasons :) Thanks for your input, Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Favor: Weigh in on draft-ietf-ipsecme-split-dns?
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 (operational and security-related) since we began the process of signing our zones in 2011. We have universal DNSSEC validation in place across our enterprise recursive layers and almost all zones, internal and external, are DNSSEC signed. I forget the exact count without checking, but we have 100+ 3rd level and lower internal zones. Outside public placeholder zones required for proper delegation and chain of trust at the appropriate level where internal/external divisions are made (typically the 3rd level) we do not normally maintain differing versions of external/internal zones, but we have a few explicitly defined for that purpose because there is a legitimate requirement for differing internal/external resolution. Those needs are always segregated into zones defined for that purpose to simplify ongoing administration. (We never want to be in a situation where normal, routine record updates require changes in multiple versions of a zone. That would be an administrative nightmare.) We employed manual trust anchors at different phases of our implementation, but now have very few in place. One is to establish trust for an internal zone for which we do not control the administration of the parent zone. Off the top of my head, I believe that's the only significant one left. Maintain trust anchors was unpleasant and always viewed as a transitional mechanism, not something we wanted to do on a lasting basis. On Fri, Nov 30, 2018 at 11:22 AM Paul Wouters wrote: > On Fri, 30 Nov 2018, Ted Lemon wrote: > That means your public DNS zone must be signed for your internal DNS > zone to be signed? Otherwise you cannot have this signed delegation? > That would mean you cannot run DNSSEC internally before you run it > externally. > > Outside placing trust anchors on every device performing validation, that's true. Establishing trust in a zone when the parent zone is insecure is a pain. I guess DLV could still be used. I considered it at one point. I forget why I decided not to go that route. It was too many years ago. Then again, from the signing side, I'm hard-pressed to imagine a reason to start signing internal zones without signing their external parents except in the situation where you do not control the public parent zone. Normally you want to start at the top of the hierarchy and work your way down. > > When you look things up in that zone outside the firewall, you get > NXDOMAIN for everything but the SOA on the zone, which returns an old > serial number. Inside the firewall, they get answers, which > > are signed, and which validate. There's no need for a special trust > anchor here. > > This scheme seems to require both inside and outside zones are signed > with the same key, or as Mark pointed out, both internal and external > zones need to share their DS records and keep these in sync. As these > are usually different organisations/groups/vendors/services, that is > an actual management problem. Or you can do what we did and place DS records for both the internal and external KSKs (using public placeholder versions of the internal child zones just to establish the delegation point) in the parent zone. That establishes chain of trust whichever version of the zone is resolved. That works whether the public version is just a placeholder with nothing else of significance in it or if it is a zone where both the external and internal records matter and are used by the appropriate source for the query, but differ. > > There are two ways to approach this. One is to assume that the > validator never checks the SOA on the zone. This is almost certainly the > case for nearly any use case. In that case, you just > > run the internal and external name servers with the same ZSK, and have a > delegation above it. You don't worry about zone serial numbers, because > they don't affect validation. When you're inside the VPN, > > you get answers for the internal zone; when you're outside the vpn, you > get answers for the outside. Both validate, because the DS record(s) are > referring to the same ZSK(s). > > coordinating shared ZSK's is even harder then requiring sharing DS > records! ZSKs roll every month, and a lot of software auto-generates > and performs the roll without any humans involved. It seems extremely > fragile to need to coordinate ZSKs between different organisations, > be ready for the same algorithm rollovers, etc etc. > > Yes, absolutely. I wouldn't want to try to coordinate sharing signing keys (KSK or ZSK) across different zones under any circumstance. I know some places that do it with KSKs because the product they use supports it as long as both versions of the zone are signed on the same device, but we don't even sign internal and external zones in the same place. Or maintain the master data in the same place for
