On Mon, Jun 06, 2016 at 09:35:42AM -0700,
John Heidemann wrote
a message of 53 lines which said:
> Other well approaches are striping queries across multiple servers,
> and adding "chaff" queries. (I'm not sure that those approaches
> require standardization---they could be done by any intere
On Fri, Jun 03, 2016 at 01:33:32PM -0400,
Paul Wouters wrote
a message of 40 lines which said:
> You would chain various DNS caches together, so a query to one
> populates them all.
Cool idea. We could take inspiration from RFC 2186/2187.
___
dns-
On Fri, 03 Jun 2016 10:26:50 -0700, "Christian Huitema" wrote:
>On Thursday, June 2, 2016 3:50 PM, Paul Wouters wrote:
>>
>> On Thu, 2 Jun 2016, Hugo Maxwell Connery wrote:
>>
>> > so, lets get 8.8.8.8 running TLS DNS as a push.
>> >
>> > Hang on, they are a sruveillence/advertising business! N
still need the recursive to auth encryption ...
/Hugo
From: Christian Huitema [huit...@huitema.net]
Sent: Friday, 3 June 2016 19:26
To: 'Paul Wouters'; Hugo Maxwell Connery
Cc: dns-privacy@ietf.org
Subject: RE: [dns-privacy] Deployment issues
On Thur
On Fri, 3 Jun 2016, Christian Huitema wrote:
It still makes sense to reduce the number of people that can read your DNS
requests, just like it makes sense to use https to google.com.
Yes. And we have an interesting issue with the size of the service. In
theory, anybody could set up a recursive
On Thursday, June 2, 2016 3:50 PM, Paul Wouters wrote:
>
> On Thu, 2 Jun 2016, Hugo Maxwell Connery wrote:
>
> > so, lets get 8.8.8.8 running TLS DNS as a push.
> >
> > Hang on, they are a sruveillence/advertising business! No problem, it
> > is just they who can surveill.
>
> It still makes se
> On Jun 2, 2016, at 6:50 PM, Paul Wouters wrote:
>
> On Thu, 2 Jun 2016, Hugo Maxwell Connery wrote:
>
>> so, lets get 8.8.8.8 running TLS DNS as a push.
>>
>> Hang on, they are a sruveillence/advertising business! No problem,
>> it is just they who can surveill.
>
> It still makes sense to
On Thu, 2 Jun 2016, Hugo Maxwell Connery wrote:
so, lets get 8.8.8.8 running TLS DNS as a push.
Hang on, they are a sruveillence/advertising business! No problem,
it is just they who can surveill.
It still makes sense to reduce the number of people that can read your
DNS requests, just like
...@env.dtu.dk]
Sent: Friday, 3 June 2016 00:01
To: Dan York; Robert Edmonds
Cc: dns-privacy@ietf.org; Christian Huitema
Subject: Re: [dns-privacy] Deployment issues
Hi,
I hope the WG will start looking at that "next step".
There are resource issues with running TLS to auth servers.
But, that
go Connery
From: dns-privacy [dns-privacy-boun...@ietf.org] on behalf of Dan York
[y...@isoc.org]
Sent: Thursday, 2 June 2016 20:39
To: Robert Edmonds
Cc: dns-privacy@ietf.org; Christian Huitema
Subject: Re: [dns-privacy] Deployment issues
> On Jun 2, 2016, at 2:11 PM, R
> On Jun 2, 2016, at 2:11 PM, Robert Edmonds wrote:
>
> Christian Huitema wrote:
>> Is this part of DPRIVE's charter?
>
>"...but it may also later consider mechanisms that provide
>confidentiality between Iterative Resolvers and Authoritative
>Servers, or provide end-to-end confiden
Hi,
I tried to point this out at the beginning;
encrypting connections to local caching resolvers
without encrypting the auth resolver connection
gives the same security as Tor Browser.
But, something is better than nothing. Better for the world
having the "I live in an anonymity set"
Christian Huitema wrote:
> Is this part of DPRIVE's charter?
"...but it may also later consider mechanisms that provide
confidentiality between Iterative Resolvers and Authoritative
Servers, or provide end-to-end confidentiality of DNS transactions."
--
Robert Edmonds
__
I have been pondering DNS Privacy issues for some times, and I read with
interest a recent blog by Geoff Huston and Joao Luis Silva Damas
(http://www.circleid.com/posts/20160526_the_path_to_dns_privacy/).
Basically, we have two trends, somewhat conflicting. On one side, DPRIVE is
standardizing an e
14 matches
Mail list logo