Subject: [DNSOP] my dnse vision

From: Francis Dupont <[email-masked]>
Date: Wed, 05 Mar 2014 12:07:40 +0100

>From discussions with Stephane Bortzmeyer and Mark Andrews...

First I come back to the fact there are two different problems
(aka divide and conquer):
 * stubs <-> resolver
 * resolver <-> auth servers

I consider the first one to be already solved, cf. the Microsoft
deployed solution which puts clients, local networks, the resolver
(also the Microsoft Domain Server :-), in the same area and uses
IPsec to protect it. You can do other ways but IMHO we can assume
you don't need confidentiality with far or untrusted resolvers.
Or with other words you don't need confidentiality with 8.8.8.8

So we have the second (and *hard*) problem to address.
A thing we can do now is to minimize qnames (Stephane should
write a dedicated draft about this): it doesn't change the protocol,
and IMHO to change referrals by direct queries about name servers
should not be a bad thing.

The last step is to design an encryption solution.
My requirements are:

 1- the solution SHOULD NOT add extra round trips

 2- the solution MUST NOT add per client state on servers

 3- the solution MUST work without prior arrangements

In details: 1- is about extra delays but for higher level domains
a validating resolver will anyway make other related requests
so the extra delays will be diluted.
 2- is about scalability and anycast, e.g., we want the solution
to work with a common setup where requests are load-balanced
between multiple server instances. Note the keyword is "state",
we can accept a state associated with a TCP connection but
a solution relying on even medium key TTL should be rejected.
 3- is common sense, and includes circular dependencies if
for instance the server public key is itself delivered through
the DNS.

At the other hand we only need a weak (== not very strong) protection
against passive attacks, so it doesn't matter that the standard mutually
authenticated Diffie-Hellman + symmetical A+E cipher doesn't fit.

Regards

[email-masked]

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 05 Mar 2014 11:13:51 +0000

Francis,

This is some good summarizing.  With your solution, you don't mention 
UDP. I would consider the lack of UDP an issue with moving forward at 
least for wide deployment.  Others seem to think otherwise.

I'd be interested in hearing opinions on this.

The WG will help us chair form the discussion, but I still feel there is 
a need for a more formalized problem statement. Stephane's draft goes a 
long way, do we think it covers all the bases?

tim

On 3/5/14, 11:07 AM, Francis Dupont wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 5 Mar 2014 12:20:33 +0100

Hi Francis,
> First I come back to the fact there are two different problems (aka divide
and
> conquer):
> I consider the first one to be already solved, cf. the Microsoft deployed
> solution which puts clients, local networks, the resolver (also the
Microsoft
> Domain Server :-), in the same area and uses IPsec to protect it. You can
do
> other ways but IMHO we can assume you don't need confidentiality with far
> or untrusted resolvers.

Why don't we need confidentiality with open resolvers like google? 
One might not like that anybody on his/her network knows what he is
browsing. This is a part of privacy.

> A thing we can do now is to minimize qnames (Stephane should write a
> dedicated draft about this): it doesn't change the protocol, and IMHO to
> change referrals by direct queries about name servers should not be a bad
> thing.
> 

Probably you need a miracle. Because with no arrangement, I do not think it
is possible. I would change your sentence to with minimal arrangements.

> In details: 1- is about extra delays but for higher level domains a
validating
> resolver will anyway make other related requests so the extra delays will
be
> diluted.
>  2- is about scalability and anycast, e.g., we want the solution to work
with a
> common setup where requests are load-balanced between multiple server
> instances. Note the keyword is "state", we can accept a state associated
with a
> TCP connection but a solution relying on even medium key TTL should be
> rejected.
>  3- is common sense, and includes circular dependencies if for instance
the
> server public key is itself delivered through the DNS.
> 

If you use a weak approach, IMHO, it is better to forget encryption since
you do not know how powerful an attacker can be and you only bother your
computer.

Best,
Hosnieh

---

From: Miek Gieben <[email-masked]>
Date: Wed, 5 Mar 2014 11:33:07 +0000

[ Quoting <[email-masked]> in "Re: [DNSOP] my dnse vision..." ]
> I'd be interested in hearing opinions on this.

Can't we use QUIC
(http://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf) ?

It seems to me that a lot of use cases covered in dnse are being addressed
in this protocol.

Kind regards,
Miek

---

From: Tony Finch <[email-masked]>
Date: Wed, 5 Mar 2014 11:42:56 +0000

> On 5 Mar 2014, at 11:20, "Hosnieh Rafiee" <[email-masked]> wrote:
> 

Right. Encrypting to distant resolvers has to be at least as important as local ones. The usual argument against encryption does not apply since there will be eavesdroppers who cannot also see the user's non-DNS traffic.

I think dnse is important because it removes an obstacle to putting interesting data in the DNS. At the moment your DNS traffic might reveal that you are doing email but not who with. If your MUA starts looking up PGP or S/MIME keys then privacy becomes a lot more important. Email is just an example; I am sure there are other really interesting uses for a more secure DNS.

Tony.
--
f.anthony.n.finch  <[email-masked]>  http://dotat.at/

---

From: Dan York <[email-masked]>
Date: Wed, 5 Mar 2014 12:11:16 +0000

Francis,

> * resolver <-> auth servers

Agreed.

> IPsec to protect it.

Which may be great if you are: 1) in an environment using Microsoft
solutions; and 2) connected to those networks.  Not so great if you are
NOT in a Microsoft environment or are mobile or on other networks (and
yes, I realize you could VPN back into the corporate network).

>You can do other ways but IMHO we can assume

And I will disagree with that assumption.  I personally want
confidentiality between my stub resolver and whatever recursive resolvers
I may choose to use, including 8.8.8.8 (and its IPv6 equivalent). I'd like
to remove that connection as a place where an attacker can monitor /
observe / log my DNS queries.

Regards,
Dan

--
Dan York
Senior Content Strategist, Internet Society
[email-masked] <mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked] <mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/

---

From: Tony Finch <[email-masked]>
Date: Wed, 5 Mar 2014 12:41:43 +0000

> (also the Microsoft Domain Server :-), in the same area and uses

I don't know if it is solved in a particularly satisfactory way. There is also DNScrypt supported by OpenDNS and DNS-over-TLS supported by Unbound. However neither of those do autoconfiguration, and I guess the Microsoft setup is not great for mobile devices.

Tony.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 5 Mar 2014 12:51:52 +0000

> Or with other words you don't need confidentiality with 8.8.8.8

I strongly disagree, my hotel list 8.8.8.8 as one of the resolvers available on the 
network, the answers from the 8.8.8.8  there are nothing like the answers I get from 8.8.8.8 on the IETF network. 
I NEED confidence that I'm talking to the real 8.8.8.8 if the only way to get that is 
encryption then I support it. 

I'm not sure if Microsoft solution works when one attaches to new networks like the IETF network. 

The stub <--> recursive [validating] resolver 

is the one more important to protect as the that is where it is easier to lie. 

On the other one 
recursive resolver <--->  auth servers 
 I would prefer that before we start talking about encryption is we agree on 
label stripping by recursive resolvers as that minimizes the leak of information to 
root/tld servers. 

	Olafur

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 05 Mar 2014 12:55:41 +0000

> label stripping by recursive resolvers as that minimizes the leak of information to
Agreed. I think Encryption discussions are putting the cart before the 
horse.

tim

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 Mar 2014 14:09:43 +0100

>  least for wide deployment.  Others seem to think otherwise.

=> I didn't add UDP in constraints but I made the "state" term loose
enough to be able to be intepreted as same state lifetime than for DNS
over TCP as currently specified. You have the extra round trip too...

>  I'd be interested in hearing opinions on this.

=> I am too. In theory the encription is in the session layer so
we can't avoid a transport (i.e., UDP vs TCP) dependency.

>  long way, do we think it covers all the bases?

=> yes, we need the problem before the solution (I said less than
one hour ago that XXX was another example of an IETF solution
looking for its problem :-).

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 Mar 2014 14:27:49 +0100

>  Why don't we need confidentiality with open resolvers like google? 

=> because the goal is not confidentiality at the level a Microsoft
environment needs (because Microsoft adopted and extended DNS
with far stronger security requirement) but to make 3 letter
agencies (4 letters in France) the global surveillance more expensive.
And I don't trust Google for this (nor to pay its taxes :-).

>  browsing. This is a part of privacy.

=> IMHO this is more the second problem. Note I consider too you
want your "own" DNSSEC validating resolver too.

>  is possible.

=> Michael Richardson's opportunistic encryption shows it is possible.
BTW what we want is really opportunistic encryption as defined in
Wikipedia (so don't object there are at least 3 OE at the IETF :-).

>  you do not know how powerful an attacker can be and you only bother your

=> not my computer, my resolver. And the goal is not strict/strong
privacy which BTW is impossible because 3/4 letter agencies can
anyway ask for .com or .fr server logs. Personally I don't like the
idea of DNS encryption but because I don't want to give a reason to
ISPs to filter port 53.

Regards

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 5 Mar 2014 14:19:51 +0000

On Wed, Mar 05, 2014 at 11:33:07AM +0000,
 Miek Gieben <[email-masked]> wrote 

> It seems to me that a lot of use cases covered in dnse are being addressed

It's partly a problem of timing. How long before QUIC is ready and
implemented?

But you're right, I'll add it to the next version of
draft-bortzmeyer-dnsop-privacy-sol.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 5 Mar 2014 14:16:01 +0000

On Wed, Mar 05, 2014 at 12:07:40PM +0100,
 Francis Dupont <[email-masked]> wrote 

> Or with other words you don't need confidentiality with 8.8.8.8

Like many other people here, I disagree. We need confidentiality for
open public resolvers more than we need it for an on-campus or on-LAN
resolver, because, for OpenDNS or Google Public DNS, the "last mile"
is very long and offers much more possibilities of sniffing.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 5 Mar 2014 14:30:30 +0000

On Wed, Mar 05, 2014 at 12:41:43PM +0000,
 Tony Finch <[email-masked]> wrote 
 a message of 16 lines which said:

> There is also DNScrypt supported by OpenDNS and DNS-over-TLS
> supported by Unbound. However neither of those do autoconfiguration, 

It's OK for some use cases (the typical OpenDNS user stays with
OpenDNS even when he moves and connects to other networks) and it has
a big plus, it seriously limits the number of RTT before the first
query.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 5 Mar 2014 14:23:15 +0000

On Wed, Mar 05, 2014 at 02:27:49PM +0100,
 Francis Dupont <[email-masked]> wrote 
 a message of 45 lines which said:

> 3/4 letter agencies can anyway ask for .com or .fr server logs.

This is a separate issue, surveillance by name servers. It is not
addressed by DNS encryption but by QNAME minimization, local caching
resolver on your machine and other techniques to minimize the amount
of queries.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 Mar 2014 15:46:18 +0100

In your previous mail you wrote:

>  solutions; and 2) connected to those networks.

=> I gave this as a deployed example for the stub <-> resolver
where the resolver is local and under your control (the second is
likely if it is a DNSSEC validating resolver too).

>  Not so great if you are NOT in a Microsoft environment

=> I am very far to be a Microsoft addict (:-)! But if Microsoft can
do it (or enforce it to its customers) there is no reason you can't do
it too...

>  or are mobile or on other networks (and

=> you took words from my mouth: just go back to the known case
(note in this case you are likely leaking the corporate name but
nothing else).

>  And I will disagree with that assumption.

=> I make the assumption the resolver is under your control
(so by definition it is not an open recursive resolver :-).
This is more about what means confidentiality in this context,
so a topic by itself.

>  I personally want confidentiality between my stub resolver and
>  whatever recursive resolvers I may choose to use, including 8.8.8.8
>  (and its IPv6 equivalent). I'd like to remove that connection as a
>  place where an attacker can monitor / observe / log my DNS queries.

=> to go further we need to know what/if open recursive resolver
operators (there are only a few) want to do, and if they want
the IETF to charter a WG to design something. IMHO it is very
different from the initial perpass concern so should be addressed
(if it needs to be addressed) independently.

Regards

PS: for ISP recursive resolvers the issue is simpler: DNS is a part
of the ISP service and to protect it is just an easy sub case to
protect ISP customers' communications. With other words either
you trust your ISP, you don't trust it and there are a lot of
things more critical than the DNS.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 5 Mar 2014 14:42:13 +0000

On Wed, Mar 05, 2014 at 12:51:52PM +0000,
 Olafur Gudmundsson <[email-masked]> wrote 
 a message of 41 lines which said:

> I NEED confidence that I'm talking to the real 8.8.8.8 if the only
> way to get that is encryption then I support it.

The goal of the DNSE BoF was privacy, not authentication. For
authentication, we have DNSSEC :-) For the case where the validating
resolver is far away and we need to secure the last mile against
AD-bit tampering, well... no problem statement published, no I-D and
no BoF yet.

> I would prefer that before we start talking about encryption is we
> agree on label stripping by recursive resolvers as that minimizes
> the leak of information to root/tld servers.

Why before? Encryption and QNAME minimization are both great things
and should be done but they solve different privacy problems:

* surveillance by a third-party sniffing the wire (encryption)
* surveillance by the name servers' operators (QNAME minimization)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 5 Mar 2014 14:53:02 +0000

On Wed, Mar 05, 2014 at 12:07:40PM +0100,
 Francis Dupont <[email-masked]> wrote 
 a message of 53 lines which said:

> minimize qnames (Stephane should write a dedicated draft about this):

In the mean time, it is section 2.2.2 of draft-bortzmeyer-dnsop-privacy-sol-00.txt

---

From: Jelte Jansen <[email-masked]>
Date: Wed, 5 Mar 2014 14:58:49 +0000

On 03/05/2014 01:27 PM, Francis Dupont wrote:
> 
> Personally I don't like the idea of DNS encryption but because I
> don't want to give a reason to ISPs to filter port 53.
>

This is something I worry about too. If we consider the resolver itself
out of scope, and only protect the wire, all the more reasons for ISPs
to try and force you to use theirs (perhaps even after some friendly
coercion from the nearest three-letter agency (four in the netherlands
as well)). In which case we'd need even better channel encryption, to
the point where you can't tell it's DNS, so it can be tunneled out of
the network (and that is an avenue only reserved for us geeks, I wager).

Jelte

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 5 Mar 2014 15:05:29 +0000

> AD-bit tampering, well... no problem statement published, no I-D and

Fair enough 
> * surveillance by the name servers' operators (QNAME minimization)

You and I can in theory write up an BCP candidate on this QNAME minimization, 
topic in one day and have it published in about 3 months and we are done. 
Any recursive resolver can make this change in their next version as an option and we can 
evaluate the impact, and then recommend when to turn on "label stripping" i.e. I'm not sure
if reverse tree should have any QNAME minimization. 

Encryption will take much longer to gain traction, in my mind I do not like that 
for example tad servers can see what is asked for in a sub-domain as xTLD are
most natural collection points thus we need to make the data that they see have as little value
as possible
To my encrypting full QNAME to everyone is non-sensical. 

	Olafur

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 5 Mar 2014 15:11:59 +0000

> The goal of the DNSE BoF was privacy, not authentication. For

Stephane,

Do you mean data authentication, or who-I-am-talking to authentication?

DW

---

From: Tony Finch <[email-masked]>
Date: Wed, 5 Mar 2014 16:38:20 +0000

Stephane Bortzmeyer <[email-masked]> wrote:
>
> For authentication, we have DNSSEC :-)

DNSSEC authenticates data not servers. Client/server authentication is
done by TSIG/SIG(0).

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Portland, Plymouth, North Biscay: Variable 4, becoming southerly or
southwesterly 4 or 5, occasionally 6 later. Moderate or rough. Rain later.
Good, occasionally poor later.

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 06 Mar 2014 13:48:55 +0000

Talked with Jim Roskind who did the QUIC talk back in Vancouver.  I 
include his comments:

----

I actually discussed this in a hallway discussion at the Canada IETF 
meeting.

I think it would fit well, as it has the potential to offer zero-RTT 
connect (similar to what DNS over UDP effectively supports today), and 
yet it will better (actually) handle guaranteed delivery, as well as 
deal with large return packages (DNS Sec).  DNS currently supports 
(sadly) an amplification attack of about 50x, and in QUIC, we worked 
hard to control this problem.

IT is also nice that it is encrypted.... which means that folks will get 
some extra privacy, and not reveal (to observers) what they are 
resolving ;-).

One hassle is that we do try to encrypt/authenticate... and with an IP 
address only (pointing to the DNS resolver), I don't see a clean way to 
have a cert providing authentication :-/.  I guess you *could* implant 
(into a client) a combination of both the  DNS resolver's IP address, 
*plus* an expected server name.  Fun stuff to ponder ;-).

IMO, interesting, and plausibly nice, fit.

Jim

---------

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 6 Mar 2014 14:39:51 +0000

On Wed, Mar 05, 2014 at 02:58:49PM +0000,
 Jelte Jansen <[email-masked]> wrote 
 a message of 20 lines which said:

> all the more reasons for ISPs to try and force you to use theirs
> (perhaps even after some friendly coercion from the nearest
> three-letter agency (four in the netherlands as well)). In which
> case we'd need even better channel encryption, to the point where
> you can't tell it's DNS, so it can be tunneled out of the network

If we follow this line of reasoning, why do we deploy more security,
then? With this argument, we would never have deployed HTTPS
either. (Or SSH: most hotspots and many ISP block SSH.)

We promised in Vancouver to seriously strengthen the Internet against
surveillance. Was it an empty promise, politician-style?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 6 Mar 2014 14:44:35 +0000

On Wed, Mar 05, 2014 at 03:11:59PM +0000,
 Wessels, Duane <[email-masked]> wrote 

> Do you mean data authentication, or who-I-am-talking to authentication?

Data authentication. In the DNS, where the authoritative name servers
for a given zone can be under ≠ organisations (the root...) and where
there are relays and caches everywhere, the authentication of the
server has little value (that's one of the reasons I'm not a big fan
of DNScurve).

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 6 Mar 2014 14:50:20 +0000

On Wed, Mar 05, 2014 at 04:38:20PM +0000,
 Tony Finch <[email-masked]> wrote 
 a message of 13 lines which said:

> DNSSEC authenticates data not servers. 

See my reply to Duane. Athenticating an autoritative name server or a
forwarder has little value (because they could have cheated and
changed the data).

The only place where server authentication could be useful is between
a stub and the first resolver.

---

From: Jelte Jansen <[email-masked]>
Date: Thu, 6 Mar 2014 15:35:43 +0000

> either. (Or SSH: most hotspots and many ISP block SSH.)

And lo and behold, you do see forced breakage of SSL, and 'friendly'
MITM attacks forced on people.

But I'm not saying we shouldn't do anything. I'm saying that I'm worried
that if we blindly splat some channel encryption on, we may actually
lower security for a number of people, in which case we need to go even
further and hide the fact that DNS data is being sent in the first
place. Now this may very well have been solved (VPN/SSL tunneling, one
of the existing specific-to-dns channel solutions), but in that case we
should probably be explicit about it.

But really I was working up to my next message, that was a +1 on
splitting up the various problems, and fix (or not fix) those
separately. That might even include not trusting your resolver in the
first place.

> surveillance. Was it an empty promise, politician-style?

I think we are all trying to do exactly that.

Or, to be a bit more precise and/or cynical: Of course it was, but we
are trying to do it anyway.

Jelte

---

From: Francis Dupont <[email-masked]>
Date: Thu, 06 Mar 2014 16:55:47 +0100

In your previous mail you wrote:

>  then?

=> because we want (and as you noticed they don't want).

>  With this argument, we would never have deployed HTTPS
>  either.

=> have we? I am afraid most HTTPS are MITM'ed where SSH & co are
blocked.

>  (Or SSH: most hotspots and many ISP block SSH.)

=> I know and it is a shame! BTW for ISP it is for me a good (and
enough) reason to go another one (fortunately in France ISP
competition is high: no NAT, no silly filters, less than 20 EUR
per month for 20Mbits/s triple play...)

>  surveillance. Was it an empty promise, politician-style?

=> the political side is politician-style, do you have a doubt?

Regards

---

From: Evan Hunt <[email-masked]>
Date: Thu, 6 Mar 2014 17:31:32 +0000

> a stub and the first resolver.

I think that's exactly the point that was under discussion, though:
How can people who don't want their DNS traffic snooped and analyzed,
but have decided for some reason to use 8.8.8.8 anyway, be sure they're
talking to the "real" 8.8.8.8? :)

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 6 Mar 2014 18:37:17 +0100

> -----Original Message-----
> From: DNSOP [mailto:[email-masked]] On Behalf Of Evan Hunt
> Sent: Thursday, March 06, 2014 6:32 PM
> To: Stephane Bortzmeyer
> Cc: Tony Finch; [email-masked]
> Subject: Re: [DNSOP] my dnse vision
> 
> How can people who don't want their DNS traffic snooped and analyzed, but
> have decided for some reason to use 8.8.8.8 anyway, be sure they're
talking
> to the "real" 8.8.8.8? :)
> 
> --

This is actually addressed in CGA-TSIG draft (a secure authentication) and
also confidentiality

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 6 Mar 2014 18:39:07 +0100

On Thu, Mar 06, 2014 at 05:31:32PM +0000,
 Evan Hunt <[email-masked]> wrote 
 a message of 12 lines which said:

> I think that's exactly the point that was under discussion,

It's a very valid and interesting point but it has not a lot of
relationship with the privacy issues. I suggest that it deserves a
separate effort, which could start with a nice I-D describing the
problem statement/analysis (and then to proposed solutions).

Unless we want to solve all the security problems of the DNS at once,
with the same solution?

---

From: Evan Hunt <[email-masked]>
Date: Thu, 6 Mar 2014 17:57:01 +0000

On Thu, Mar 06, 2014 at 06:39:07PM +0100, Stephane Bortzmeyer wrote:
> relationship with the privacy issues.

I don't entirely agree: if a MITM can spoof a trusted remote resolver,
then QNAME minimization won't help you.  DNSSEC ensures that you get
legitimate answers; it doesn't ensure that the server on the other
end belongs to someone you trust to keep your queries confidential.

> I suggest that it deserves a

I agree it would be appropriate to treat stub-to-resolver channel
security as a separate problem space.

(I will note in passing that I'm intrigued by the CGA-TSIG draft
being circulated by Mr. Raffieh.)

> Unless we want to solve all the security problems of the DNS at once,

Oh, I didn't realize it was an option. Yes, that sounds excellent,
please do that.

---

From: Tony Finch <[email-masked]>
Date: Mon, 10 Mar 2014 17:11:08 +0000

> a stub and the first resolver.

I don't think it is as simple as that.

There are good reasons for using a recursive resolver that is close to
you, e.g. to avoid untrustworthy shared resolvers. However the more people
do this the more demand there will be for intercepting iterative queries
between resolvers and authorities. You need to authenticate authoritative
servers to protect against active interception.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Hebrides: South or southwest 4 or 5, increasing 6 to gale 8. Moderate or
rough, becoming very rough in northwest. Mainly fair. Moderate or good,
occasionally poor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 10 Mar 2014 13:36:14 -0400

> servers to protect against active interception.

What we are talking about here is cryptographically binding the request and
response under a key.

Since we are going to encrypt we have already agreed to spend the cycles
needed for key setup. So adding a 128 bit MAC only costs us 16 bytes and a
trivial number of cycles.

The benefits we get are significant. First off it means that if the
recursive is being used in discovery-only mode it can simply pass data from
the authoritative to the stub without checking the DNSSEC chain.

Secondly in the case we have a trusted resolver that is validating the
DNSSEC chain as a proxy for the stub, it means that an attacker can't
meddle with responses as a way to DoS the resolver, possibly causing it to
abort DNSSEC checking completely.

The problem comes in that unlike the stub-resolver interaction where we can
do one key exchange with a service and keep the relationship going for the
life of the device (i.e. years), a resolver has to maintain relationships
with thousands to millions of authoritative servers and we probably can't
rely on these for more than a month or two at a time.

So the key exchange to do the encryption is a bigger cost. It is certainly
justified if we are connecting to the VeriSign or GoDaddy authoritative
servers or for any of the big services. But thats a harder case to make on
the long tail.

What might make sense is to support a symmetric, secure after first use key
exchange as an alternative to using a full public key exchange. We could
further deter intercept as follows:

Resolver is connecting to an authoritative to make a request
really-obvious.com to answer a query from a stub (i.e. this is not a
pre-fetch).

Resolver has no session key on file so it sends the request in plaintext.
It can however be alerted to support for the security protocol in the
DNSSEC information for the zone. So assume that there is some flag there
that tells us that we can make a query as follows:

Resolver:
      really-obvious.com ? A
      TICKET = {NULL, key}

Authoritative [Encrypt, Sign under Key]
      really-obvious.com/A = 10.1.2.3
      key-exchanger.example.com/PVT  WitnessValue
      TICKET = {TID, key2}

The ticket returned by the Authoritative  {TID, key2} may be used to secure
further requests until a full key agreement has been achieved.

If/when the resolver performs a key exchange, it presents the Witness value
and original key to the key exchange service. This allows the service to
detect an attempt at an active attack.

-- 
Website: http://hallambaker.com/

---

From: Tony Finch <[email-masked]>
Date: Mon, 10 Mar 2014 17:44:25 +0000

Phillip Hallam-Baker <[email-masked]> wrote:
>
> First off it means that if the recursive is being used in discovery-only
> mode it can simply pass data from the authoritative to the stub without
> checking the DNSSEC chain.

If the recursive server is cacheing it needs to do DNSSEC validation to
protect its cache from poisonous authorities.

> rely on these for more than a month or two at a time.

Yes :-/

[...]

> Resolver has no session key on file so it sends the request in plaintext.

This leakage is bad expecially for recursors with few users and / or
queries for infrequently visited domains.

> DNSSEC information for the zone.

This is a bad idea because it makes partial deployment difficult - e.g.
staged roll-out of encryption. DNSSEC information is per-zone but
encryption has to be per-server.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
German Bight, Humber, Thames: North or northeast 5 or 6, decreasing 4 or 5.
Slight or moderate. Mainly fair. Moderate or good, occasionally poor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 10 Mar 2014 14:28:56 -0400

> protect its cache from poisonous authorities.

But that would be an offline activity rather than within the response loop
to service the request from the stub.

> queries for infrequently visited domains.

If a Russian citizen is visiting Putler.com and the authoritative for that
zone only has that entry and nothing else, then traffic analysis is going
to give away the request subject.

That is just something we have to live with, lessons in not being seen and
all that.

> encryption has to be per-server.

I can't see the point of a partial rollout of encryption at an
authoritative. But worst case it just means that the client is going to
assume the service does not support encryption until it sees an EDNS record
saying that it does.

In the example I was trying to show what the maximal cover we could achieve
for this case might look like. Obviously if there is even one authoritative
that isn't encrypting we don't need to worry about odd
secure-after-first-contact requests that go unencrypted.

The other reason to tie the signalling to DNSSEC is that it then avoids
people getting confused about the authentication being proposed here as
being an alternative to the authentication in DNSSEC. It isn't an either/or
situation. We need both sets of authentication controls.

---

From: Tony Finch <[email-masked]>
Date: Mon, 10 Mar 2014 18:59:23 +0000

> to give away the request subject.

That does not imply we should make it easy for attackers in other
situations.

> authoritative.

It is a natural consequence of cautious deployment. Also, a zone has
multiple authoritative servers, so the partial roll-out I was talking
about is partial per-zone not partial per-server. Which is why the
encryption flag has to be per-server not per-zone as you suggested.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Hebrides: South or southwest 5 to 7, increasing gale 8 for a time in
northwest. Moderate or rough, becoming very rough in northwest. Mainly fair.
Moderate or good, occasionally poor later.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 12 Mar 2014 02:18:32 +1100

In message <CAMm+LwhnDGJftdSZMyOHi3kjocP6Pw=[email-masked]>
> to service the request from the stub.
 
Actually it needs to be within the response loop so it can discard
bad data and move onto a different server.

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