Hi Karl and list, No and Yes.
The introduction section says "out of scope" not "there are different attack vectors and operational concerns". ... and then I got to thinking. (sorry about that) But, I do agree that there are differences between the types of attackers for recursers and authoritatives based on the different outcomes of complete loss of service. Recursive resolvers serve a wide variety of stub resolvers over varying operating systems from some network(s), which the operator gets to choose, but the resolvers need to be within those network(s). Some companies choose to offer recursive resolvers that serve the entire internet (8.8.8.8, 1.1.1.1 etc.), but these are currently the tiniest minority of recursive resolvers (*), though this is likely to change with "recurser as a service". The consequence of total failure of these resolver services for the community within those network(s) is "the internet does not work" (for them). So, a recursive operator chooses which community (via networks) they serve, must be amongst those networks, and the consequence of loss of service is "the internet does not work" for clients within those networks. An authoritative server is different. It does not get to choose its community. Ostensibly it is serving recursive resolvers (**), but they could be anywhere, so this amounts to serving the global internet. But, the authoritative servers can be in any reachable network. The consequence of loss of all authoritative resolvers for a collection of zones is that the services described in its zones become increasingly globally unavailable as caches of its records expire. So, an authoritative operator must serve the entire internet, can be anywhere, and the loss of service is "these sites dont work" progressively for everybody. >From this we can see who is motivated to attack what. By attack I mean limit or completely prevent service delivery by non-military actors. Notably, recursive resolvers that serve networks that are limited geographically to a nation state have no defence against the government of that nation state, but authoritatives can skip around to avoid government attacks (aka laws). Many governments and corporations attack recursors for censorship purposes with political and/or cultural motives (see "Pirate Bay"). Authoritative regimes may wish to remove all (public) recursors to create an internet blackout, but this is countered by (*) above so they have to prevent access to the globally reachable resolvers too (see "Great Firewall"). Authoritative resolvers may be attacked by extortionists for money or miscreants for fame (see DDOS), or by competitors of services described in the zone(s) for competitive advantage (see "this is never published/I've got a furtive imagination"). So, yes the threat landscape is different because the consequences of loss of service are different. Note that adding encryption or session based query services for authoritatives changes none of this and is countered by money (more CPU/RAM etc.). Obviously, authoritative operators are legitimately motivated to minimize this burden (and should carefully review proposed changes so that no new attacks methods are admitted by new standards). One of the defences for authoritatives is to prioritise serving recursive resolvers, as they are their legitimate clientele (**). One can identify recursive resolvers because they will honour your TTL values and will be a sparse collection of addresses within network(s). This is not a perfect protection because recursers can "go rogue" (cracked) or deliberately behave nicely for a while (planned attack), but it should help with DDOS type attacks that are not well planned. Similarly, you can grade your deliberate refusal of service to network(s) when under attack from them. Refuse service to all not already known recursers for a while before refusing service to the entire network(s) if the initial service restriction doesn't help. But, if that's the case, you have a good idea who is attacking you from those network(s). Regards, Hugo Connery On Fri, 2018-11-30 at 19:13 +0000, Henderson, Karl wrote: > Hi Paul, > > The attack vectors and operational concerns are different for communication > between the recursive-to-authoritative than for communication between the > stub-to-recursive. For instance, a stub will > typically communicate with one or two recursive resolvers while recursive > resolvers may communicate with many authoritative resolvers - thus changing > the nature of persistent TLS connections for > this communication path. > > The authors of [RFC8310] recognized this difference and highlight it in the > Introduction section with this statement: > > "The proposals here might be adapted or extended in future to be used for > recursive clients and authoritative servers, but this application was out of > scope for the DNS PRIVate Exchange (dprive) > Working Group charter at the time this document was published." > > Regards, > Karl > > On 11/30/18, 12:34 PM, "Paul Wouters" <p...@nohats.ca> wrote: > > On Fri, 30 Nov 2018, Hollenbeck, Scott wrote: > > >> times have changed, and it deserves another look, but some note that > says > >> "If running out of resources, drop the encryption and serve DNS data in > >> the clear might be needed". Ideally in a way that querying clients that > >> want to insist on privacy can bail out instead of receiving cleartext. > > > > Possibly, but it may also be worth discussing how to avoid getting into > resource exhaustion situations in the first place. Do you have any thoughts > on Karl's "need for a profile of encryption > standards" comment? > > I am not sure I see a need for a different TLS/DTLS profile compared to > regular (web) based (D)TLS connections. What do you or Karl think would > be different? > > Paul > > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy -- Hugo Connery, Head of IT, DTU Environment "There is no cloud, only other people's computers". FSF _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
