Re: [DNSOP] my dnse vision

[Mark Andrews]

In message 
, Phillip Hallam-Baker writes:
> On Mon, Mar 10, 2014 at 1:44 PM, Tony Finch  wrote:
> 
> > Phillip Hallam-Baker  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.
> 
> 
> But that would be an offline activity rather than within the response loop
> 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: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Tony Finch]

Phillip Hallam-Baker  wrote:
> On Mon, Mar 10, 2014 at 1:44 PM, Tony Finch  wrote:
> >
> > > 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.
>
> 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 does not imply we should make it easy for attackers in other
situations.

> > > It can however be alerted to support for the security protocol in the
> > > 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.
>
> I can't see the point of a partial rollout of encryption at an
> 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.finchhttp://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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Phillip Hallam-Baker]

On Mon, Mar 10, 2014 at 1:44 PM, Tony Finch  wrote:

> Phillip Hallam-Baker  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.


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

> 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.
>
> This leakage is bad expecially for recursors with few users and / or
> 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.



> > It can however be alerted to support for the security protocol in the
> > 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.


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.

-- 
Website: http://hallambaker.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Tony Finch]

Phillip Hallam-Baker  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.

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

Yes :-/

[...]

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

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

> It can however be alerted to support for the security protocol in the
> 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.finchhttp://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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Phillip Hallam-Baker]

On Mon, Mar 10, 2014 at 1:11 PM, Tony Finch  wrote:

> Stephane Bortzmeyer  wrote:
> >
> > The only place where server authentication could be useful is between
> > 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.
>

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/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Tony Finch]

Stephane Bortzmeyer  wrote:
>
> The only place where server authentication could be useful is between
> 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.finchhttp://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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Evan Hunt]

On Thu, Mar 06, 2014 at 06:39:07PM +0100, Stephane Bortzmeyer wrote:
> It's a very valid and interesting point but it has not a lot of
> 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
> separate effort, which could start with a nice I-D describing the
> problem statement/analysis (and then to proposed solutions).

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,
> with the same solution?

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

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Stephane Bortzmeyer]

On Thu, Mar 06, 2014 at 05:31:32PM +,
 Evan Hunt  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?

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Hosnieh Rafiee]

> -Original Message-
> From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Evan Hunt
> Sent: Thursday, March 06, 2014 6:32 PM
> To: Stephane Bortzmeyer
> Cc: Tony Finch; dnsop@ietf.org
> Subject: Re: [DNSOP] my dnse vision
> 
> On Thu, Mar 06, 2014 at 02:50:20PM +, Stephane Bortzmeyer wrote:
> > The only place where server authentication could be useful is between
> > 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? :)
> 
> --


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Evan Hunt]

On Thu, Mar 06, 2014 at 02:50:20PM +, Stephane Bortzmeyer wrote:
> The only place where server authentication could be useful is between
> 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 -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Jelte Jansen]

On 03/06/2014 02:39 PM, Stephane Bortzmeyer wrote:
>> 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.)
> 

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.

> We promised in Vancouver to seriously strengthen the Internet against
> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Stephane Bortzmeyer]

On Wed, Mar 05, 2014 at 04:38:20PM +,
 Tony Finch  wrote 
 a message of 13 lines which said:

> > For authentication, we have DNSSEC :-)
> 
> 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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Stephane Bortzmeyer]

On Wed, Mar 05, 2014 at 03:11:59PM +,
 Wessels, Duane  wrote 
 a message of 35 lines which said:

> > The goal of the DNSE BoF was privacy, not authentication. For
> 
> 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).


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Stephane Bortzmeyer]

On Wed, Mar 05, 2014 at 02:58:49PM +,
 Jelte Jansen  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?

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision (3 cases)

[Francis Dupont]

This is an update of my previous messages.

The generic DNS confidentiality problem can be divided into 3 cases:

 1- stubs <-> local resolver

 2- stubs <-> remote open resolver

 3- resolver <-> auth. servers

In the first case the local resolver is in the same security area
(I use "area" to avoid to overload "domain" or "zone") than clients/
stubs (and the infrastructure between them two). This covers the
case where the resolver is physically local and the one where a
mobile client is securely connected to the local network, so the
usual perimeter/VPN/etc including nomadic VPNs. As DNS is in the 1-
case only one of the services to protect I consider without a strong
argument for the opposite the security will be provided by a general
(vs. a DNS one) mechanism so doesn't need a DNSE solution.
BTW usually in the 1- case the resolver is dual headed so
authentication and authorization are already required/provided.

2- is about a very low number of remote open resolvers so
again without an explicit request I suggest we consider it is
a private issue between the open resolver service and its customers.
Note the environment is very different than 3- so even it has to
be addressed 2- should lead to a different solution too.

So we have to address 3-, and to begin by qname minimization
(which is also minimal on many aspects :-).

Regards

francis.dup...@fdupont.fr

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision (A+E vs E)

[Hosnieh Rafiee]

BTW it (the overhead) will be likely bigger in the query than in the
> response so we should not get new amplification concerns.

Amplification happens when IP spoofing is possible. When the solution stop
IP spoofing, I guess, it cannot happen as well.

Hosnieh

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision (A+E vs E)

[Francis Dupont]

Another note about builtin/inline encryption solutions: there is a
trade-off between encryption + authentication/integrity as recommended
by crypto design rules vs. performances and message sizes.  Of course
this will be addressed during the crypto design, so when/after we
reach a consensus about what we need in DNS encryption (i.e.,
message size overhead SHOULD be small). BTW it (the overhead) will
be likely bigger in the query than in the response so we should not
get new amplification concerns.

Regards

francis.dup...@fdupont.fr

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Tony Finch]

Stephane Bortzmeyer  wrote:
>
> For authentication, we have DNSSEC :-)

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

Tony.
-- 
f.anthony.n.finchhttp://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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Wessels, Duane]

On Mar 5, 2014, at 2:42 PM, Stephane Bortzmeyer  wrote:

> 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


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Olafur Gudmundsson]

On Mar 5, 2014, at 2:42 PM, Stephane Bortzmeyer  wrote:

> On Wed, Mar 05, 2014 at 12:51:52PM +,
> Olafur Gudmundsson  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.

Fair enough 
> 
>> 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)
> 
> 

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Jelte Jansen]

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Stephane Bortzmeyer]

On Wed, Mar 05, 2014 at 12:07:40PM +0100,
 Francis Dupont  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 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Stephane Bortzmeyer]

On Wed, Mar 05, 2014 at 12:51:52PM +,
 Olafur Gudmundsson  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)


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Francis Dupont]

 In your previous mail you wrote:

>  > 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.
>  
>  Which may be great if you are: 1) in an environment using Microsoft
>  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
>  yes, I realize you could VPN back into the corporate network).

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

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

francis.dup...@fdupont.fr

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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Stephane Bortzmeyer]

On Wed, Mar 05, 2014 at 12:41:43PM +,
 Tony Finch  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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Stephane Bortzmeyer]

On Wed, Mar 05, 2014 at 02:27:49PM +0100,
 Francis Dupont  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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Stephane Bortzmeyer]

On Wed, Mar 05, 2014 at 12:07:40PM +0100,
 Francis Dupont  wrote 
 a message of 53 lines which said:

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Francis Dupont]

 In your previous mail you wrote:

>  > Or with other words you don't need confidentiality with 8.8.8.8
>  
>  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 :-).

>  One might not like that anybody on his/her network knows what he is
>  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.

>  >  3- the solution MUST work without prior arrangements
>  
>  Probably you need a miracle. Because with no arrangement, I do not think it
>  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 :-).

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

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

francis.dup...@fdupont.fr

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Francis Dupont]

 In your previous mail you wrote:

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

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

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

francis.dup...@fdupont.fr

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Tim Wicinski]

On 3/5/14, 12:51 PM, Olafur Gudmundsson wrote:


  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.


Agreed. I think Encryption discussions are putting the cart before the 
horse.


tim

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Olafur Gudmundsson]

On Mar 5, 2014, at 11:07 AM, Francis Dupont  wrote:

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

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Tony Finch]

On 5 Mar 2014, at 11:07, Francis Dupont  wrote:
> 
> 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.

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.
--
f.anthony.n.finchhttp://dotat.at/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Dan York]

Francis,


On 3/5/14 11:07 AM, "Francis Dupont"  wrote:

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

Agreed.

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

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
>you don't need confidentiality with far or untrusted resolvers.
>Or with other words you don't need confidentiality with 8.8.8.8

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
y...@isoc.org    +1-802-735-1624
Jabber: y...@jabber.isoc.org 
Skype: danyork   http://twitter.com/danyork

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Tony Finch]

> On 5 Mar 2014, at 11:20, "Hosnieh Rafiee"  wrote:
> 
> 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.

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.finchhttp://dotat.at/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Miek Gieben]

[ Quoting  in "Re: [DNSOP] my dnse vision..." ]
> 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.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Hosnieh Rafiee]

Hi Francis,
> >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

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.


> 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

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

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Tim Wicinski]

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:

>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

francis.dup...@fdupont.fr

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop