Hi Warren, It seems to me that the intended use-case is access to corporate-like network environments where intranet.corporate-like. <http://intranet.corporate-like.com/>com might exist on the inside but not on the outside. Whether access is through a VPN or WPA2-protected WiFi or an RJ45 jack on the wall in a locked room seems orthogonal to the problem space, so I'm not sure why the VPN example needs additional facilities that the others don't have.
If you sign both your internal-facing and external-facing view of your zone with the same KSK, surely you don't need an additional TA to make it work in any of those example cases? The DS RRSet in your parent is all anybody needs. I share your concern that there's no obvious way to limit the scope of the TA when the only administrator in the picture is a baking-obsessed, jet-lagged, non-technical user in a hotel room at 4am. In general, I think dissemination of a new TA to a validator is a serious business and shouldn't be done quietly if there's a chance that a non-technical end-user is driving. Joe > On 26 Nov 2018, at 11:17, Warren Kumari <war...@kumari.net> wrote: > > Hi there DNSOP, > > I (and a number of IESG folken) would like some feedback / guidance on > draft-ietf-ipsecme-split-dns. > > This document (which has gone through IESG eval, and on which I'm currently > holding a DISCUSS) attempts to solve the problem of accessing internal > domains when using a split-tunnel VPN. > > Here is the abstract: > > "This document defines two Configuration Payload Attribute Types > (INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA) for the Internet Key > Exchange Protocol Version 2 (IKEv2). These payloads add support for > private (internal-only) DNS domains. These domains are intended to > be resolved using non-public DNS servers that are only reachable > through the IPsec connection. DNS resolution for other domains > remains unchanged. These Configuration Payloads only apply to split > tunnel configurations." > > Okey dokey, this sounds reasonable, and solves a problem which probably > shouldn't exist, but does. > > The concerning scenario for me (and where I'd like the WG to provide feedback > if I'm being overly twitchy) is: > "The INTERNAL_DNSSEC_TA attribute type is used to convey a DNSSEC > trust anchor for such a domain. This is required if the external > view uses DNSSEC that would prove the internal view does not exist or > would expect a different DNSSEC key on the different versions > (internal and external) of the enterprise domain." > > Let's say I'm visiting Elbonia and really really want to watch "The Great > British Baking Show" on Netflix. Elbonia blocks all baking shows[0], and so I > figure I'll fire up my VPN, provided by "VPNs-R-Us - only $1.99 per month, > don't torrent without it!". > As you can guess from the name, VPNs-R-Us is sketchy, but, hey, they were > cheap! (They make up the profit by being malicious). > > So, I fire up my IPSEC VPN client, and it pops up a box saying "VPNs-R-Us > wants to provide you with DNS servers for [.com, farfetch.com > <http://farfetch.com/> ] and DNSSEC Trust Anchors for the same. Continue > [Y/N]?". Being a users, desperate to watch Paul Hollywood disapprove of > someone's puff pastry, I click "Yes" (admit it, you would too!).. > I then browse to www.paypal.com <http://www.paypal.com/> to see if I can buy > a shirt just like Noel Fielding's. > > My DNS request goes to VPNs-R-Us, who (because they have provided me with a > DNSSEC TA for .com) answers with 6.6.6.6 and a "validly" signed DNSSEC > answer. They also "helpfully" provide me with a TLSA record, and when I > connect provide me with a certificate with the DNSSEEC chain extension.. > > The document attempt to mitigate issues like this with: "Other generic or > public domains, such as top-level domains (TLDs), similarly MUST be ignored > if these appear in a whitelist unless the entity actually is the operator of > the TLD. To determine this, an implementation MAY interactively ask the user > when a VPN profile is installed or activated to confirm this. Alternatively, > it MAY provide a special override keyword in its provisioning configuration > to ensure non-interactive agreement can be achieved only by the party > provisioning the VPN client, who presumbly is a trusted entity by the > end-user.", discussions in the Security Considerations, etc. > > I believe that the document is trying to solve a real world problem, but I'm > concerned by the ability to push DNSSEC TAs, and rely on user's ability to > make an informed decision (keeping in mind their behavior when presented with > big red "Are you sure you want to accept this random TLS certificate?!" > browser boxes). > > So, would y'all mind weighing in to help me decide what I do with my DISCUSS? > Do the benefits outweigh the risks? Allowing this potentially allows for > DNSSEC signing of things like internal TLDs / internal namespaces, increasing > DNSSEC deployment. Am I being overly cautious here? Should users know better > than to blindly click OK on things they don't understand? > > I'd really like your advice, preferably before Friday. > > The document: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ > <https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/> > The balloting: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ballot/ > <https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ballot/> > > The thread on my DISCUSS: > https://mailarchive.ietf..org/arch/msg/ipsec/5xvXIidXt3DgxO_V0V8Haosb1Uc > <https://mailarchive.ietf.org/arch/msg/ipsec/5xvXIidXt3DgxO_V0V8Haosb1Uc> > > > W > [0]: Lest their citizens start wondering why they don't also have cake. > > > -- > I don't think the execution is relevant when it was obviously a bad idea in > the first place. > This is like putting rabid weasels in your pants, and later expressing regret > at having chosen those particular rabid weasels and that pair of pants. > ---maf > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
