Subject: [dns-privacy] Alternative signalling propsals

From: "Reed, Jon" <[email-masked]>
Date: Fri, 14 Dec 2018 17:43:34 +0000

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

---

From: Warren Kumari <[email-masked]>
Date: Fri, 14 Dec 2018 16:19:10 -0500

On Fri, Dec 14, 2018 at 12:43 PM Reed, Jon <[email-masked]> 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 AAAA. 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
> [email-masked]
> 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

---

From: Jon Reed <[email-masked]>
Date: Fri, 14 Dec 2018 16:38:42 -0500

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 AAAA. 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

---

From: Warren Kumari <[email-masked]>
Date: Fri, 14 Dec 2018 16:48:29 -0500

On Fri, Dec 14, 2018 at 4:38 PM Jon Reed <[email-masked]> 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 AAAA. 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

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

---

From: Paul Wouters <[email-masked]>
Date: Fri, 14 Dec 2018 17:43:44 -0500 (EST)

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 AAAA. 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:
> 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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 14 Dec 2018 22:58:09 +0000

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.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 14 Dec 2018 17:54:05 -0500

> 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

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 14 Dec 2018 19:37:01 -0500

> 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

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 15 Dec 2018 01:34:23 +0000

Hiya,

> is that what you're proposing?

I wasn't proposing, just asking:-) But yes, a starttls like scheme
could be one approach.

> against passive attack, which is something that signalling in the name

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.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 15 Dec 2018 13:26:20 +1100

> On 15 Dec 2018, at 11:37 am, Daniel Kahn Gillmor <[email-masked]> wrote:
> 

Not if the zone is signed.

> 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.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 17 Dec 2018 10:04:23 -0800

"Reed, Jon" <[email-masked]> 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/

---

From: Paul Wouters <[email-masked]>
Date: Mon, 17 Dec 2018 14:36:50 -0500 (EST)

>  this camp but still think this is a better solution than a name-based one.

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

---

From: Warren Kumari <[email-masked]>
Date: Mon, 17 Dec 2018 16:12:53 -0500

> 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

---

From: Tony Finch <[email-masked]>
Date: Tue, 18 Dec 2018 12:36:32 +0000

>   the forward zones its serving

Reverse zones plural (v4 + v6) :-)

>   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.

> - 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.finch  <[email-masked]>  http://dotat.at/
public services available on equal terms to all

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 18 Dec 2018 06:39:11 -0800

Warren Kumari <[email-masked]> writes:

> 1: "OK, click Start, then Shutdown... Now press the power key and and we'll wait for it
> to boot"
> 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 <big telco> and they
won't let us do reverse DNS for you even though you're static.  Sorry."

---

From: Petr Špaček <[email-masked]>
Date: Wed, 19 Dec 2018 19:27:24 +0100

> 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