Re: [dns-privacy] Alternative signalling propsals
On 14. 12. 18 23:54, Daniel Kahn Gillmor wrote: > On Fri 2018-12-14 17:43:44 -0500, Paul Wouters wrote: >> We fixed that with tls-dnssec-chain :P >> >> I'll leave it up to others to wonder why and how this did not move >> forward, and is now going via ISE. >> >> Sorry for the side-track of this discussion. > > This isn't sidetrack at all, it was one of the motivating use cases of > tls-dnssec-chain-extension from my perspective, and particularly sad to > see it fail as a result. :( I would be happy to merge pull request which implements proof-of-concept chain extension as module for Knot Resolver, but beware, it is not that easy to implement... -- Petr Špaček @ CZ.NIC ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Alternative signalling propsals
Warren Kumari writes: > I've tried contacting my ISPs over the years, and the responses have been: > 1: "OK, click Start, then Shutdown... Now press the power key and and we'll > wait for it > to boot" > 2: "What? Um. Have you tried turning it off and on again?" > 3: "What? Huh. Nope, never heard of that." > 4: "You are a dynamic customer. We cannot do anything like that for dynamic > customers... > Sorry, no we don't do static IPs for residential. Oh! You have a static > subnet routed to > you?! Weird, I didn't know we did that... " > 5: "Yes, we have plans to support IPv6 in the future" [no idea what that > has to do > with anything ] > 6: "We don't allow users to run servers, and so there is no need for you to > have reserve > DNS". my situation: 7: "Hey Wes, how's things? Yeah, I know we supported everything for you in the past because you're smart, we're smart and we're small enough to pretty much help everyone. But to get you the speed you wanted, we had to outsource your connection and address space to and they won't let us do reverse DNS for you even though you're static. Sorry." -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://blog.capturedonearth.com/ ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Alternative signalling propsals
Wes Hardaker wrote: > > My list for putting a TLSA or similar record at the reverse zone > include: > > pros: > - the authoritative server more likely in control of its reverse zone than all > the forward zones its serving Reverse zones plural (v4 + v6) :-) > - the number of reverse zone records to update on a key change is 1 per ip > address. The number of name server NS records to update per key > change is 1 per zone supported, which is very very large for some > servers. For forward DNS it is 1 per name server name (i.e. per alias), which might be 1 per zone for places that provision zones with in in-bailiwick name server names, or might be 1 per server if they prefer to provision zones with canonical name server names. > - it feels cleaner > cons: > - not everyone controls their reverse zone easily, especially for those > that don't hold at least a /24 allocation. Ironically, I fall into > this camp but still think this is a better solution than a name-based one. > - requires more lookups > - requires the reverse tree for that address be fully signed The "more lookups" thing is interesting. If the TLSA-like record is in the forward DNS, then you get into a bootstrapping problem. Assuming we can't add these new records as glue, a resolver ends up having to: * query a parent server for delegation; receive NS records and glue * query a child server publicly for TLSA-like record(s) * query child server privately for actual question i.e. in the DNS case we lose the opportunity for concurrent address + TLSA queries that DANE normally offers. If the TLSA-like record is in the reverse DNS, and the reverse DNS nameservers are cached, then the sequence of lookups is the same. The "more lookups" case happens when there's a cold reverse DNS cache as well as a cold forward cache. Putting TLSA-like records in the reverse DNS doesn't solve the bootstrap problem, in cases where the server you want the TLSA-like record for is authoritative for its own reverse zones. I started a thread discussing related things back in September... https://www.ietf.org/mail-archive/web/dns-privacy/current/msg02124.html Tony. -- f.anthony.n.finchhttp://dotat.at/ public services available on equal terms to all ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Alternative signalling propsals
On Mon, Dec 17, 2018 at 2:37 PM Paul Wouters wrote: > On Mon, 17 Dec 2018, Wes Hardaker wrote: > > > cons: > > - not everyone controls their reverse zone easily, especially for those > > that don't hold at least a /24 allocation. Ironically, I fall into > > this camp but still think this is a better solution than a name-based > one. > > - requires more lookups > > Your ISP should support Classless Delegations, RFC 2317 > > https://tools.ietf.org/html/rfc2317 > > I have deployed this successfully. > Is that a "should" or "SHOULD"? 'cos it certainly isn't a MUST :-P I've tried contacting my ISPs over the years, and the responses have been: 1: "OK, click Start, then Shutdown... Now press the power key and and we'll wait for it to boot" 2: "What? Um. Have you tried turning it off and on again?" 3: "What? Huh. Nope, never heard of that." 4: "You are a dynamic customer. We cannot do anything like that for dynamic customers... Sorry, no we don't do static IPs for residential. Oh! You have a static subnet routed to you?! Weird, I didn't know we did that... " 5: "Yes, we have plans to support IPv6 in the future" [no idea what that has to do with anything ] 6: "We don't allow users to run servers, and so there is no need for you to have reserve DNS". Perhaps you've just been lucky and gotten an ISP which sucks less? W > > > - requires the reverse tree for that address be fully signed > > That might be tricker, if your upstream ISP does not believe in DNSSEC > signing. > > Paul > > ___ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > -- 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 ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Alternative signalling propsals
On Mon, 17 Dec 2018, Wes Hardaker wrote: cons: - not everyone controls their reverse zone easily, especially for those that don't hold at least a /24 allocation. Ironically, I fall into this camp but still think this is a better solution than a name-based one. - requires more lookups Your ISP should support Classless Delegations, RFC 2317 https://tools.ietf.org/html/rfc2317 I have deployed this successfully. - requires the reverse tree for that address be fully signed That might be tricker, if your upstream ISP does not believe in DNSSEC signing. Paul ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Alternative signalling propsals
"Reed, Jon" writes: > On the call, someone (Wes?) proposed an alternative such as records in > the reverse zones. Yes, I think this solves a number of issues and creates new ones. IE, the list of pros and cons for all solutions includes no item with zero "cons" unfortunately. My list for putting a TLSA or similar record at the reverse zone include: pros: - the authoritative server more likely in control of its reverse zone than all the forward zones its serving - the number of reverse zone records to update on a key change is 1 per ip address. The number of name server NS records to update per key change is 1 per zone supported, which is very very large for some servers [1]. - it feels cleaner cons: - not everyone controls their reverse zone easily, especially for those that don't hold at least a /24 allocation. Ironically, I fall into this camp but still think this is a better solution than a name-based one. - requires more lookups - requires the reverse tree for that address be fully signed And probably more pros and cons I'm not thinking of at the moment. [1]: the latest huge DANE support jump at https://stats.dnssec-tools.org/ is due to a large number of zones suddenly enabling DANE/SMTP on one.com. That shows the scale of some of the larger zone holders. -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://blog.capturedonearth.com/ ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Alternative signalling propsals
> On 15 Dec 2018, at 11:37 am, Daniel Kahn Gillmor > wrote: > > On Fri 2018-12-14 22:58:09 +, Stephen Farrell wrote: > >> I'm probably exposing my lack of DNS-clue, but I wonder if it >> is/isn't possible to embed a "like/want/offer privacy" signal >> in the DNS protocol, rather than in the data carried by the >> protocol? (Regardless of whether the latter might be done via >> funny names or new/additional RRs.). > > i think you're suggesting some sort of "starttls"-like mechanism -- > start a DNS connection to an authoritative server, and then the server > lets you know "hey you might also want to try me in the future via > private channels" > > is that what you're proposing? > > if so, it has the unsatisfying aspect common to all starttls-like > proposals: it can be trivially stripped. Not if the zone is signed. > it is also unsatisfying in the DNS world because there typically isn't > a handshake -- the first packet contains the sensitive data that you > might want to keep private. I you can’t hide that you are talking to a nameserver. Asking for the nameserver’s TLSA record isn’t exposing much that is already exposed. > It could certainly help over the longer term against a passive monitor > -- the initial privacy leak could be amortized over many future > communications between the resolver and the authoritative -- but it > still leaves the first connection to that server unprotected even > against passive attack, which is something that signalling in the name > could potentially avoid. > > --dkg > ___ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Alternative signalling propsals
Hiya, On 15/12/2018 00:37, Daniel Kahn Gillmor wrote: > i think you're suggesting some sort of "starttls"-like mechanism -- > start a DNS connection to an authoritative server, and then the server > lets you know "hey you might also want to try me in the future via > private channels" > > is that what you're proposing? I wasn't proposing, just asking:-) But yes, a starttls like scheme could be one approach. > if so, it has the unsatisfying aspect common to all starttls-like > proposals: it can be trivially stripped. > > it is also unsatisfying in the DNS world because there typically isn't > a handshake -- the first packet contains the sensitive data that you > might want to keep private. > > It could certainly help over the longer term against a passive monitor > -- the initial privacy leak could be amortized over many future > communications between the resolver and the authoritative -- but it > still leaves the first connection to that server unprotected even > against passive attack, which is something that signalling in the name > could potentially avoid. Sure, I don't disagree with the above, and I wasn't arguing for this, more wondering for now if there're any gotcha reasons why it can't work. That said, perhaps one of the other trade-offs here is related to the potential ease/speed of deployment - if a mechanism that's TOFU-like or that needs pinning leaks a little at first but were easier to deploy and more likely to spread, (say if all that were needed was a s/w update), then that's something to take into consideration. Cheers, S. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Alternative signalling propsals
On Fri 2018-12-14 22:58:09 +, Stephen Farrell wrote: > I'm probably exposing my lack of DNS-clue, but I wonder if it > is/isn't possible to embed a "like/want/offer privacy" signal > in the DNS protocol, rather than in the data carried by the > protocol? (Regardless of whether the latter might be done via > funny names or new/additional RRs.). i think you're suggesting some sort of "starttls"-like mechanism -- start a DNS connection to an authoritative server, and then the server lets you know "hey you might also want to try me in the future via private channels" is that what you're proposing? if so, it has the unsatisfying aspect common to all starttls-like proposals: it can be trivially stripped. it is also unsatisfying in the DNS world because there typically isn't a handshake -- the first packet contains the sensitive data that you might want to keep private. It could certainly help over the longer term against a passive monitor -- the initial privacy leak could be amortized over many future communications between the resolver and the authoritative -- but it still leaves the first connection to that server unprotected even against passive attack, which is something that signalling in the name could potentially avoid. --dkg signature.asc Description: PGP signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Alternative signalling propsals
On Fri 2018-12-14 17:43:44 -0500, Paul Wouters wrote: > We fixed that with tls-dnssec-chain :P > > I'll leave it up to others to wonder why and how this did not move > forward, and is now going via ISE. > > Sorry for the side-track of this discussion. This isn't sidetrack at all, it was one of the motivating use cases of tls-dnssec-chain-extension from my perspective, and particularly sad to see it fail as a result. :( --dkg ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Alternative signalling propsals
Hiya, I'm probably exposing my lack of DNS-clue, but I wonder if it is/isn't possible to embed a "like/want/offer privacy" signal in the DNS protocol, rather than in the data carried by the protocol? (Regardless of whether the latter might be done via funny names or new/additional RRs.). The ability to turn on e.g. TLS seems to be more dependent on the server than the zone (*) so this signal would seem to more naturally be a protocol extension rather than a change to the stored data served via the protocol. Thanks, S. (*) I could buy a counter-argument that the desire to turn on the signal may be name/domain/zone specific, but that still needs a server/service change. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Alternative signalling propsals
On Fri, 14 Dec 2018, Warren Kumari wrote: One of the stated reasons for browsers not doing DANE / TLSA was having to wait for the TLSA record to come back before you can connect. "Ah! Fine..", says I, "Just do these in parallel -- you will get back the TLSA record at about the same time as the A or . You could even be smart and start making the TCP connection if you happen to get back the A first. There, I fixed it for you...[0]". Turns out this doesn't (or, at least, didn't) work -- yes, ~1/2 the time the TLSA record will come in first, and ~1/2 the time it will be second -- but, when it is second: A: you often don't know if it will ever show up and B: sometimes is it really really second / your query got lost and you need to ask again, after a suitable backoff.. We fixed that with tls-dnssec-chain :P I'll leave it up to others to wonder why and how this did not move forward, and is now going via ISE. Sorry for the side-track of this discussion. Paul ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Alternative signalling propsals
On Fri, Dec 14, 2018 at 4:38 PM Jon Reed wrote: > > > On Fri, 14 Dec 2018, Warren Kumari wrote: > > > > > > > > > On the call, someone (Wes?) proposed an alternative such as > records in the reverse zones. That would be a huge win for > > us, since we have a small finite set of nameserver IPs, and easily > control our reverse zones (as, I would imagine, do other > > large providers). I wasn't in Bangkok, so I'm not sure if there > were any specific implementation proposals kicked around, > > but I'd like to start talking about what that would look like. > Something TLSA-ish at the reverse name for the nameserver > > IP? There's obviously some overhead with the recursive having to > look up reverse names for NS IPs, but large TTL values > > could help with that. > > > > > > One of the stated reasons for browsers not doing DANE / TLSA was having > to wait for the TLSA record to come back before you can > > connect. > > "Ah! Fine..", says I, "Just do these in parallel -- you will get back > the TLSA record at about the same time as the A or . You > > could even be smart and start making the TCP connection if you happen to > get back the A first. There, I fixed it for you...[0]". > > Well, TLSA was just an example. yes, and it was for me too :-) > My point was that a signalling method > based on the nameserver IPs (however it is implemented) would be far > preferable for larger operators like us (and is no less onerous for zone > owners/registrants who are also operators). I don't think we want to be > in the position of requiring each of our customers to opt-in to this for > each of their (thousands) of zones. We want to be able to turn this on > in bulk, the same we'd support any new protocol feature. > Yup - fully understand and agree; I just didn't want us to jump to something like "parallel queries solves the latency concern" without this background / checking - it might end up being the right answer (or, even better, something like this coupled with multiple responses, where you query for NS, and get back both NS and NEW (if available) as an additional record). W > > -Jon -- 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 ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Alternative signalling propsals
On Fri, 14 Dec 2018, Warren Kumari wrote: On the call, someone (Wes?) proposed an alternative such as records in the reverse zones. That would be a huge win for us, since we have a small finite set of nameserver IPs, and easily control our reverse zones (as, I would imagine, do other large providers). I wasn't in Bangkok, so I'm not sure if there were any specific implementation proposals kicked around, but I'd like to start talking about what that would look like. Something TLSA-ish at the reverse name for the nameserver IP? There's obviously some overhead with the recursive having to look up reverse names for NS IPs, but large TTL values could help with that. One of the stated reasons for browsers not doing DANE / TLSA was having to wait for the TLSA record to come back before you can connect. "Ah! Fine..", says I, "Just do these in parallel -- you will get back the TLSA record at about the same time as the A or . You could even be smart and start making the TCP connection if you happen to get back the A first. There, I fixed it for you...[0]". Well, TLSA was just an example. My point was that a signalling method based on the nameserver IPs (however it is implemented) would be far preferable for larger operators like us (and is no less onerous for zone owners/registrants who are also operators). I don't think we want to be in the position of requiring each of our customers to opt-in to this for each of their (thousands) of zones. We want to be able to turn this on in bulk, the same we'd support any new protocol feature. -Jon___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Alternative signalling propsals
On Fri, Dec 14, 2018 at 12:43 PM Reed, Jon wrote: > I'd like to start a thread about alternatives to encoding fingerprints in > NS names. As I noted in the meeting (unless I'm significantly > misunderstanding the proposal), this is a non-starter for large operators > like us. It's not feasible to get our customers to change every NS record > in their thousands of domains, and there's no way to do any sort of > incremental rollout. Customers are reluctant to even finish KSK rotations > (by updating the DS in the parent), I can't imagine trying to get them to > update NS records to enable this feature, let alone update them for an > emergency keypair rotation. > > We use the encoding in our infrastructure zone that hosts customer > authoritative NS names (in this case, akam.net), but that creates a gap > in the chain. > > On the call, someone (Wes?) proposed an alternative such as records in the > reverse zones. That would be a huge win for us, since we have a small > finite set of nameserver IPs, and easily control our reverse zones (as, I > would imagine, do other large providers). I wasn't in Bangkok, so I'm not > sure if there were any specific implementation proposals kicked around, but > I'd like to start talking about what that would look like. Something > TLSA-ish at the reverse name for the nameserver IP? There's obviously > some overhead with the recursive having to look up reverse names for NS > IPs, but large TTL values could help with that. > One of the stated reasons for browsers not doing DANE / TLSA was having to wait for the TLSA record to come back before you can connect. "Ah! Fine..", says I, "Just do these in parallel -- you will get back the TLSA record at about the same time as the A or . You could even be smart and start making the TCP connection if you happen to get back the A first. There, I fixed it for you...[0]". Turns out this doesn't (or, at least, didn't) work -- yes, ~1/2 the time the TLSA record will come in first, and ~1/2 the time it will be second -- but, when it is second: A: you often don't know if it will ever show up and B: sometimes is it really really second / your query got lost and you need to ask again, after a suitable backoff. In a well functioning Internet you could do something clever like wait for "a little bit more" than the time it took to get the A (1.5 times?) and, if you haven't gotten an NXDOMAIN assume your query got lost -- unfortunately the DNS is messy - a notable number of servers seem to not bother sending NXDOMAIN, some middleboxes (or stupid implementations) drop Q types they don't understand, etc. Hopefully the world has gotten better since this research[1], and hopefully the Recursive to Auth path is better then the Stub to Recursive path, but it is definitely worth confirming / checking... This sort of problem was one of the motivations for Wes and my Multiple Responses ( https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/ , https://datatracker.ietf.org/meeting/96/materials/slides-96-dnsop-6 ) and various other solutions, including multiple Q types, etc (https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/, https://datatracker.ietf.org/meeting/99/materials/slides-99-dnsop-sessb-multiple-responses-multi-qtypes-00 W [0]: "Oh, that was easy," says I, and for an encore went on to prove that black is white and got myself killed on the next pedestrian crossing.” (with apologies to Douglas Adams) [1]: Citation needed :-). I've seen a number of papers showing the DNS long tail - I think Giovane was the author of at least one... > > -Jon > > ___ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > -- 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 ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] Alternative signalling propsals
I'd like to start a thread about alternatives to encoding fingerprints in NS names. As I noted in the meeting (unless I'm significantly misunderstanding the proposal), this is a non-starter for large operators like us. It's not feasible to get our customers to change every NS record in their thousands of domains, and there's no way to do any sort of incremental rollout. Customers are reluctant to even finish KSK rotations (by updating the DS in the parent), I can't imagine trying to get them to update NS records to enable this feature, let alone update them for an emergency keypair rotation. We use the encoding in our infrastructure zone that hosts customer authoritative NS names (in this case, akam.net), but that creates a gap in the chain. On the call, someone (Wes?) proposed an alternative such as records in the reverse zones. That would be a huge win for us, since we have a small finite set of nameserver IPs, and easily control our reverse zones (as, I would imagine, do other large providers). I wasn't in Bangkok, so I'm not sure if there were any specific implementation proposals kicked around, but I'd like to start talking about what that would look like. Something TLSA-ish at the reverse name for the nameserver IP? There's obviously some overhead with the recursive having to look up reverse names for NS IPs, but large TTL values could help with that. -Jon ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
