In message CAMm+LwhnDGJftdSZMyOHi3kjocP6Pw=notcnqr5kr+pomal...@mail.gmail.com
, Phillip Hallam-Baker writes:
On Mon, Mar 10, 2014 at 1:44 PM, Tony Finch d...@dotat.at wrote:
Phillip Hallam-Baker hal...@gmail.com wrote:
First off it means that if the recursive is being used in
Stephane Bortzmeyer bortzme...@nic.fr 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
On Mon, Mar 10, 2014 at 1:11 PM, Tony Finch d...@dotat.at wrote:
Stephane Bortzmeyer bortzme...@nic.fr 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
Phillip Hallam-Baker hal...@gmail.com 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
On Mon, Mar 10, 2014 at 1:44 PM, Tony Finch d...@dotat.at wrote:
Phillip Hallam-Baker hal...@gmail.com 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
Phillip Hallam-Baker hal...@gmail.com wrote:
On Mon, Mar 10, 2014 at 1:44 PM, Tony Finch d...@dotat.at 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
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
On Wed, Mar 05, 2014 at 02:58:49PM +,
Jelte Jansen jelte.jan...@sidn.nl 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
On Wed, Mar 05, 2014 at 03:11:59PM +,
Wessels, Duane dwess...@verisign.com 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,
On Wed, Mar 05, 2014 at 04:38:20PM +,
Tony Finch d...@dotat.at 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
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
-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
On Thu, Mar 06, 2014 at 05:31:32PM +,
Evan Hunt e...@isc.org 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
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
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
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
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
[ Quoting tjw.i...@gmail.com 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
On 5 Mar 2014, at 11:20, Hosnieh Rafiee i...@rozanak.com 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
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
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
On Wed, Mar 05, 2014 at 12:07:40PM +0100,
Francis Dupont francis.dup...@fdupont.fr 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
On Wed, Mar 05, 2014 at 12:41:43PM +,
Tony Finch d...@dotat.at 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
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
On Wed, Mar 05, 2014 at 12:51:52PM +,
Olafur Gudmundsson o...@ogud.com 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.
On Wed, Mar 05, 2014 at 12:07:40PM +0100,
Francis Dupont francis.dup...@fdupont.fr 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
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
On Mar 5, 2014, at 2:42 PM, Stephane Bortzmeyer bortzme...@nic.fr wrote:
On Wed, Mar 05, 2014 at 12:51:52PM +,
Olafur Gudmundsson o...@ogud.com 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
On Mar 5, 2014, at 2:42 PM, Stephane Bortzmeyer bortzme...@nic.fr 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
Stephane Bortzmeyer bortzme...@nic.fr 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 d...@dotat.at http://dotat.at/
Portland, Plymouth, North Biscay: Variable 4, becoming
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
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
32 matches
Mail list logo
