[DNSOP] DNS privacy and AS 112: the case of home.arpa
During the discussions about draft-bortzmeyer-dname-root or about draft-wkumari-dnsop-internal, there have been many remarks about the risk for privacy if we delegate things to AS 112: unlike the root (or .arpa), AS 112 is managed by many different people we don't know and cannot know. So, leaked requests are more at risk of surveillance with AS 112. But I notice that draft-ietf-homenet-dot, currently in the RFC Editor queue, delegates home.arpa to AS 112, in its section 7 (unless I'm wrong, it will be the first delegation to the new AS 112, the one with DNAME, described in RFC 7535). Does it mean the privacy problem is solved? Or simply overlooked? Can we delegate RFC 6761 special-use domains such as .internal to AS 112? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS privacy and AS 112: the case of home.arpa
Stephane Bortzmeyer wrote: ... Does it mean the privacy problem is solved? Or simply overlooked? Can we delegate RFC 6761 special-use domains such as .internal to AS 112? any AS112 operator can tell you that the world doesn't care about privacy, based on the amount of organizationally sensitive information that's leaked in queries for PTR in RFC 1918 address blocks. so, privacy was never my concern. rather, AS112 has no authoritative operator registry. we don't know who is running these servers, and we have no way to assure that they hear a request that they add more secondary DNS zones to such servers. so if we delegate more zones that way, there will be a lot of SERVFAIL except for servers who send REFUSED. either way we have to consider the matter. i think as long as we keep the traffic away from the ARPA and root servers, we should not care what response is received -- should be NXDOMAIN but could be pretty much anything. ideally we'd sign all of these zones with DNSSEC and put DS RR's into the delegations, to assure that poison wasn't getting believed by modern validating resolvers. but we should concern ourselves with the question: did the AS112 operators realize that we'd be adding zones over time, and will they see the new RFC and/or announcements here/elsewhere and know to update their configs? and will any of them consider this an imposition? -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS privacy and AS 112: the case of home.arpa
On Mon, Dec 11, 2017 at 01:10:20AM -0800, Paul Vixie wrote a message of 31 lines which said: > we have no way to assure that they hear a request that they add more > secondary DNS zones to such servers. so if we delegate more zones > that way, there will be a lot of SERVFAIL except for servers who > send REFUSED. either way we have to consider the matter. This problem was solved a long time ago by RFC 7535 (the new AS 112). > but we should concern ourselves with the question: No. Problem solved (check with sink.bortzmeyer.fr, which is delegated to the unspecting operators of AS 112 nodes). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS privacy and AS 112: the case of home.arpa
Stephane Bortzmeyer wrote: On Mon, Dec 11, 2017 at 01:10:20AM -0800, Paul Vixie wrote a message of 31 lines which said: we have no way to assure that they hear a request that they add more secondary DNS zones to such servers. so if we delegate more zones that way, there will be a lot of SERVFAIL except for servers who send REFUSED. either way we have to consider the matter. This problem was solved a long time ago by RFC 7535 (the new AS 112). ok. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Please review in terminology-bis: QNAME
Greetings again. Some of the new terms added to the terminology-bis draft (https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/)since RFC 7719 can expose what some (but not all) people perceive as lack of clarity in RFC 1034/1035. This week, we hope you will look at the definition in the draft for "QNAME". Please review the lengthy explanation and comment on the list if you think the definition should change. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS privacy and AS 112: the case of home.arpa
Hi Stéphane, On 11 Dec 2017, at 04:18, Stephane Bortzmeyer wrote: > On Mon, Dec 11, 2017 at 01:10:20AM -0800, > Paul Vixie wrote > a message of 31 lines which said: > >> we have no way to assure that they hear a request that they add more >> secondary DNS zones to such servers. so if we delegate more zones >> that way, there will be a lot of SERVFAIL except for servers who >> send REFUSED. either way we have to consider the matter. > > This problem was solved a long time ago by RFC 7535 (the new AS 112). Note though that the homenet document specifically requests a delegation. IANA are currently working through their process and trying to get AS112 operators to add the home.arpa zone, to avoid it being lame. This is apparently a good first thing to try because the idea of adding a DNAME record to the ARPA zone is scary and expected to receive push-back from root server operators. (I may be putting words into Kim's mouth by abbreviating the situation that way, but my point is that the IANA team are aware of the disconnect between the likely-lame delegation to AS112 vs. the approach this working group documented in 7535 and are doing their best). There is some related mail on the as112-ops list hosted at OARC. I think you need to subscribe to see the archive, so no deep link. https://lists.dns-oarc.net/mailman/listinfo/as112-ops Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS privacy and AS 112: the case of home.arpa
You don’t add the DNAME to the ARPA domain because it does not add the insecure delegation that is REQUIRED. You add the DNAME to the HOME.ARPA domain if you really want to redirect the traffic. For some reason IANA wants to make this more complicated than it needs to be. You don’t need to contact the AS112 server operators (a impossible task). You just contact the existing ARPA server operators to install HOME.ARPA on those servers. Add each NS as the operator say that their servers are reconfigured to support HOME.ARPA. This is what I would end up with. HOME.ARPA. SOA A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2017121101 1800 900 604800 86400 HOME.ARPA. NS A.ROOT-SERVERS.NET. HOME.ARPA. NS B.ROOT-SERVERS.NET. HOME.ARPA. NS C.ROOT-SERVERS.NET. HOME.ARPA. NS D.ROOT-SERVERS.NET. HOME.ARPA. NS E.ROOT-SERVERS.NET. HOME.ARPA. NS F.ROOT-SERVERS.NET. HOME.ARPA. NS G.ROOT-SERVERS.NET. HOME.ARPA. NS H.ROOT-SERVERS.NET. HOME.ARPA. NS I.ROOT-SERVERS.NET. HOME.ARPA. NS K.ROOT-SERVERS.NET. HOME.ARPA. NS L.ROOT-SERVERS.NET. HOME.ARPA. NS M.ROOT-SERVERS.NET. HOME.ARPA. DNAME EMPTY.AS112.ARPA. Mark > On 12 Dec 2017, at 3:17 am, Joe Abley wrote: > > Hi Stéphane, > > On 11 Dec 2017, at 04:18, Stephane Bortzmeyer wrote: > >> On Mon, Dec 11, 2017 at 01:10:20AM -0800, >> Paul Vixie wrote >> a message of 31 lines which said: >> >>> we have no way to assure that they hear a request that they add more >>> secondary DNS zones to such servers. so if we delegate more zones >>> that way, there will be a lot of SERVFAIL except for servers who >>> send REFUSED. either way we have to consider the matter. >> >> This problem was solved a long time ago by RFC 7535 (the new AS 112). > > Note though that the homenet document specifically requests a delegation. > > IANA are currently working through their process and trying to get AS112 > operators to add the home.arpa zone, to avoid it being lame. This is > apparently a good first thing to try because the idea of adding a DNAME > record to the ARPA zone is scary and expected to receive push-back from root > server operators. > > (I may be putting words into Kim's mouth by abbreviating the situation that > way, but my point is that the IANA team are aware of the disconnect between > the likely-lame delegation to AS112 vs. the approach this working group > documented in 7535 and are doing their best). > > There is some related mail on the as112-ops list hosted at OARC. I think you > need to subscribe to see the archive, so no deep link. > > https://lists.dns-oarc.net/mailman/listinfo/as112-ops > > > Joe > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- 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 https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: DNS privacy and AS 112: the case of home.arpa
Hi Mark, Quoting Mark Andrews on Tuesday December 12, 2017: > > HOME.ARPA. SOAA.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2017121101 > 1800 900 604800 86400 > HOME.ARPA.NS A.ROOT-SERVERS.NET. .. > HOME.ARPA. DNAME EMPTY.AS112.ARPA. It is unclear to me how this avoids having root servers process DNAME records. Given the process of consultation, coordination and testing support for DNAME records in the root servers (or relocating the .arpa authorities) is likely to take longer than is desirable to have home.arpa insecurely delegated, the delegation to AS112 was considered as the best short-term approach even if it is not without its own difficulties. kim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] DNS privacy and AS 112: the case of home.arpa
Firstly they are HOME.ARPA servers. Just because they are the same physical servers it doesn’t mean that policy for the root zone content has to apply to other zones on that server. Maintaining that distinction is important. Secondly a otherwise empty zone on these servers will fulfil the requirements to provide a insecure delegation. Just drop the DNAME from the zone contents below. All the servers involved can serve SOA and NS records and return NXDOMAIN for names under HOME.ARPA. If you need to delegate to a different set of servers create a seperate constellation of servers that you control directly or by contract. Trying to re-use AS112 servers will never work reliably as you don’t have agreements with *all* the operators. This also applies to the operators of EMPTY.AS112.ARPA. As for DNAME, that is a requirement of DNSSEC which, in theory, all the root servers support fully. Mark > On 12 Dec 2017, at 10:16 am, Kim Davies wrote: > > Hi Mark, > > Quoting Mark Andrews on Tuesday December 12, 2017: >> >> HOME.ARPA. SOA A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2017121101 >> 1800 900 604800 86400 >> HOME.ARPA. NS A.ROOT-SERVERS.NET. > .. >> HOME.ARPA. DNAME EMPTY.AS112.ARPA. > > It is unclear to me how this avoids having root servers process DNAME > records. Given the process of consultation, coordination and testing > support for DNAME records in the root servers (or relocating the .arpa > authorities) is likely to take longer than is desirable to have home.arpa > insecurely delegated, the delegation to AS112 was considered as the best > short-term approach even if it is not without its own difficulties. > > kim -- 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 https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS privacy and AS 112: the case of home.arpa
On Dec 11, 2017, at 11:17 AM, Joe Abley wrote: > Note though that the homenet document specifically requests a delegation. Please do not read more into the document than was intended. What Mark is saying looks to me like an accurate representation of what we intended. The goal is simply for it to be the case that there is not an unsigned delegation for home.arpa, which means that it has to point _somewhere_. I am a bit frustrated to hear that this is turning into a substantial amount of effort. It should be extremely simple. There is no wrong answer for what the delegation looks like other than "signed." ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt
Michael StJohns writes: Hi Mike, Thanks for explaining your thinking because I think, after reading it: we're actually in agreement but using different terms for where to put in the slop you're worried about. Specifically: > A perfectly operating resolver with perfect clock and perfect > connectivity and no outages MIGHT possibly keep a perfect interval > between each query it makes (making your activeRefreshOffset > meaningful), but 1 resolvers ALL keeping perfect intervals? Yes, I agree. But, this is why I want the majority of the equation to be defining the mathematical perfect certainty. And then *after* that, add the operational slop factor (safetyMargin) to account for both problems and reality (you forgot to add "speed of light issues" in your text above, for example). Thus, I break the equation into two critical parts: addWallClockTime = lastSigExpirationTime + addHoldDownTime + activeRefresh ^ + activeRefreshOffset | | Precise Math | -| Needed Fuzz | | + safetyMargin| v IE, if a perfect resolver hitting a RFC5011 zone with an activeRefresh that evenly divides into 30 days: 1) queries at T--- = lastSigExpirationTime - .01 2) queries at T+1--- = lastSigExpirationTime - .01 + activeRefresh 3) Notes that it just saw a new key (assuming worst case #1 is replayed) 4) starts timer 5) will query again at lastSigExpirationTime + 30 days - .01 6) notes this is still in waiting period 7) will query again at lastSigExpirationTime + 30 days - .01 + activeRefresh 8) now notes that it's been 30 days and accepts key There is only 1 activeRefresh in that sequence. And that's what's in the equation. Because the timing distance between #7 and #2 is still 30 days when queried to the perfect sub-nano second. Then there should be a bunch of delays inserted, network timeouts, etc. That's where the safetyMargin should come in and catch all the issues with the impreciseness of the real world. Now, if you want to add an activeRefresh to the already defined safetyMargin suggested term, I'm willing to consider that. But it shouldn't be listed as part of anything but the slop term for security analysis clarity. Would you like to add more time to the safetyMargin to deal with the non-perfect world, including clock drift because of time delays in a bunch of queries back to back or any other reason? Ending note about the precise timeline: when 30 days isn't divisible by the activeRefresh, then you need to add the other term we haven't talked about much which is the activeRefreshOffset which accounts for this case. Cheers, Wes ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt
On 12/11/2017 8:03 PM, Wes Hardaker wrote: Michael StJohns writes: Hi Mike, Thanks for explaining your thinking because I think, after reading it: we're actually in agreement but using different terms for where to put in the slop you're worried about. Specifically: A perfectly operating resolver with perfect clock and perfect connectivity and no outages MIGHT possibly keep a perfect interval between each query it makes (making your activeRefreshOffset meaningful), but 1 resolvers ALL keeping perfect intervals? Yes, I agree. But, this is why I want the majority of the equation to be defining the mathematical perfect certainty. And then *after* that, add the operational slop factor (safetyMargin) to account for both problems and reality (you forgot to add "speed of light issues" in your text above, for example ). (sigh - safety factor deals with speed of light issuesDUH) No, no, no, no, no. Thus, I break the equation into two critical parts: addWallClockTime = lastSigExpirationTime + addHoldDownTime + activeRefresh ^ + activeRefreshOffset | | Precise Math | -| Needed Fuzz | | + safetyMargin| v If you'd reorder this properly, you can probably get the right answer - For the first part of the discussion assume no drifts or retransmits between (1) and (2) and between (3) and (4). 1) T == lastSigExpirationTime and microscopically after this the time that the server sees the first query from any resolver starting their trust anchor installation. 2) T + activeRefresh is the time at which the server sees the last query from the last resolver just starting their trust anchor installation. 3) T + activeRefresh + addHoldDownTime is the time at which the server sees the first query from any resolver finalizing its trust anchor installation. 4) T + activeRefresh + addHoldDownTime + activeRefresh is the time at which the server sees the last query from the last resolver finalizing its trust anchor installation. (1) is the earliest time any resolver can start its installation (assuming an attack) because its also the time when all of the old signatures expire. (2) is the time at which a resolver who had its last activeRefresh just before T (and because of that wasn't able to start its installation) will send its first installation query. Between (2) and (3) any given resolver may drift/retransmit with the result that any given resolver may end up making a query just before (3) placing its next and final query at (3) plus activeRefresh. Finally, to deal with drift and retransmits between (1) and (2), and between (3) and (4) we add a safetyFactor. That deals with about 99.% of drift and retransmits but will never deal with the servers that have been offline or otherwise unable to get their queries completed. The retransmits in a given clients addHoldDown period only really move the end point for a given resolver and don't affect the overall safetyFactor of the set of resolvers. IE, if a perfect resolver hitting a RFC5011 zone with an activeRefresh that evenly divides into 30 days: 1) queries at T--- = lastSigExpirationTime - .01 2) queries at T+1--- = lastSigExpirationTime - .01 + activeRefresh Yes. 3) Notes that it just saw a new key (assuming worst case #1 is replayed) 4) starts timer 5) will query again at lastSigExpirationTime + 30 days - .01 No - from the servers point of view, the worst client (which is the only one the server cares about) will make its last query before trust anchor installation at lastSigExpirationTime + activeRefresh (when the last CLIENT saw its first valid update) + 30 days -.001. 6) notes this is still in waiting period 7) will query again at lastSigExpirationTime + 30 days - .01 + activeRefresh Nope. The worst client will query again at (from the servers point of view) lastSigExpiration + activeRefresh + addHoldDown (30) + activeRefresh From a given client's point of view the last query can happen anywhere from (lastSigExpiration + addHoldDown + .0001) to (lastSigExpriration + activeRefresh + addHoldDown + activeRefresh). The server only cares about the worst (latest) case. 8) now notes that it's been 30 days and accepts key There is only 1 activeRefresh in that sequence. And that's what's in the equation. Because the timing distance between #7 and #2 is still 30 days when queried to the perfect sub-nano second. Nope. Not from the servers point of view. Then there should be a bunch of delays inserted, network timeouts, etc. That's
