Re: [DNSOP] dnse related docs.

[Carsten Strotmann]

Hi,

Joel Jaeggli writes:

> DNSop folks,
>
> If we created a new session in the thursday evening 18:40-20:40 slot
> to accommodate expanded discussion of the Drafts discussed during DNSE
> and deconflicted that discussion with UTA on friday morning would that
> be a significant imposition? it seems unlikely that more than a 1/3 of
> the slot would be required.

would remote participation be possible during this session? I would like
to join (at least listen in).

Carsten
-- 
Carsten Strotmann
Email: c...@strotmann.de
Blog: strotmann.de

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

Re: [DNSOP] dnse related docs.

[joel jaeggli]

On 3/5/14, 9:16 AM, Carsten Strotmann wrote:
> Hi,
> 
> Joel Jaeggli writes:
> 
>> DNSop folks,
>>
>> If we created a new session in the thursday evening 18:40-20:40 slot
>> to accommodate expanded discussion of the Drafts discussed during DNSE
>> and deconflicted that discussion with UTA on friday morning would that
>> be a significant imposition? it seems unlikely that more than a 1/3 of
>> the slot would be required.
> 
> would remote participation be possible during this session? I would like
> to join (at least listen in).

yes, this is a scheduled meeting block, (scim is also meeting during
this window)

> Carsten
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Uta] dnse related docs.

[Dan York]

On 3/4/14 8:00 PM, "Joel Jaeggli"  wrote:

>If we created a new session in the thursday evening 18:40-20:40 slot to
>accommodate expanded discussion of the Drafts discussed during DNSE and
>deconflicted that discussion with UTA on friday morning would that be a
>significant imposition? it seems unlikely that more than a 1/3 of the
>slot would be required.

I think this would be useful if it enables folks proficient with TLS who
want to go to UTA Friday morning to weigh in on the DNS confidentiality
discussion and ideas and issues around the potential use (or not) of TLS.

Having said that, I think the usefulness of the session will depend upon
how many people who were part of the DNSE BOF can attend a Thursday night
session.  Do we have a sense yet of how many DNSE presenters and authors
of related drafts would be able to attend? (And people who asked questions
during the DNSE BOF?)

My 2 cents,
Dan

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

Re: [DNSOP] dnse related docs.

[Francis Dupont]

 In your previous mail you wrote:

>  If we created a new session in the thursday evening 18:40-20:40 slot

=> already booked in this slot. Sorry...

francis.dup...@fdupont.fr

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

[DNSOP] draft-fujiwara-dnsop-ds-query-increase-02

[fujiwara]

Dear Chairs and WG participants,

I updated draft-fujiwara-dnsop-ds-query-increase this Janurary.

  http://tools.ietf.org/html/draft-fujiwara-dnsop-ds-query-increase

Recent DS traffic increase seems not high, I did not request time slot
of WG meeting. However, Increasing is a fact. 

Recent DS query graph is here:
  http://member.wide.ad.jp/~fujiwara/files/DS_graph_20140305.pdf

Please comment to the draft.

What should I do about this draft from now on?  

Regards,

--
Kazunori Fujiwara, JPRS 

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

Re: [DNSOP] dnse related docs.

[Francis Dupont]

 In your previous mail you wrote:

>  And perhaps even start earlier and/or end a bit later than the
>  allocated slot (0900-1130) if it's allowed and works for many?

=> to start earlier won't fit for people leaving London Friday
(checkout, etc). For me the other side (end later) could work.

Thanks

francis.dup...@fdupont.fr

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

[DNSOP] my dnse vision

[Francis Dupont]

>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

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

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

[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

[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

[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] draft-fujiwara-dnsop-ds-query-increase-02

[Tony Finch]

It is an interesting draft and I can see why the problem concerns you. The 
dummy DS is a clever work-around, but it is a pity about the validation bug in 
Google public DNS.

I wonder about the possibility of adjusting the rules for caching delegations. 
Would it make sense to remember that a referral is insecure for the lifetime of 
the NS RRset, instead of the lifetime of the negative DS answer?

Tony.
--
f.anthony.n.finchhttp://dotat.at/

> On 5 Mar 2014, at 10:23, fujiw...@jprs.co.jp wrote:
> 
> Dear Chairs and WG participants,
> 
> I updated draft-fujiwara-dnsop-ds-query-increase this Janurary.
> 
>  http://tools.ietf.org/html/draft-fujiwara-dnsop-ds-query-increase
> 
> Recent DS traffic increase seems not high, I did not request time slot
> of WG meeting. However, Increasing is a fact. 
> 
> Recent DS query graph is here:
>  http://member.wide.ad.jp/~fujiwara/files/DS_graph_20140305.pdf
> 
> Please comment to the draft.
> 
> What should I do about this draft from now on?  
> 
> Regards,
> 
> --
> Kazunori Fujiwara, JPRS 
> 
> ___
> 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

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

[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

[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

[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

[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] On some terminology in draft-ietf-dnsop-respsize (truncation)

[Stephane Bortzmeyer]

On Mon, Mar 03, 2014 at 07:14:31AM -0800,
 Paul Vixie  wrote 
 a message of 45 lines which said:

> > I don't think that a RRset can be "possibly truncated". Either it is
> > truncated (not sent in its entirety) and the TC bit is set, the
> > resolver does not have to guess, or it is not truncated. There is
> > never an ambiguity. (Unless you use "truncation" in the sloppy sense I
> > criticized above.)
> 
> are you advising (by implication) that a receiver who hears TC=1 with
> ANCOUNT>0 or NSCOUNT>0 or ADCOUNT>0 treat it as a FORMERR?

No. And there is no path from what I wrote to this strange
conclusion. You can have several RRsets in an answer, and some can be
intact and complete.

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

Re: [DNSOP] draft-fujiwara-dnsop-ds-query-increase-02

[Olafur Gudmundsson]

On Mar 5, 2014, at 10:23 AM, fujiw...@jprs.co.jp wrote:

> Dear Chairs and WG participants,
> 
> I updated draft-fujiwara-dnsop-ds-query-increase this Janurary.
> 
>  http://tools.ietf.org/html/draft-fujiwara-dnsop-ds-query-increase
> 
> Recent DS traffic increase seems not high, I did not request time slot
> of WG meeting. However, Increasing is a fact. 
> 
> Recent DS query graph is here:
>  http://member.wide.ad.jp/~fujiwara/files/DS_graph_20140305.pdf
> 
> Please comment to the draft.
> 
> What should I do about this draft from now on?  


This is not a protocol issue this, is an implementation choice when a resolver 
is optimizing for speed of resolving by 
fetching any possible missing information 

Increasing the negative TTL will to large extend address the issue but has 
other implications

Dummy DS  an option for the high query volume domains you do not need it for 
most. 
If some validators have problem with them report it as bugs and hopefully it 
will be fixed quick.  

Your calculations on the amplification are good illustration, but assume that 
the resolvers use
the parental provided NS set, not the child side provided NS set. 
In the case of google.co.jp. 
JP side NS has TTL of 1 day but google.co.jp side has is 96 hours (4 days) 
Unbound resolver has by default of MaxTTL 1 day thus it does not matter in the 
case of google.co.jp 
which NS set is stored, but other resolvers do different things. 

In short I think the simple conclusion is 
"signed domain will see increased DS traffic for unsigned child domains" 

Olafur


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

Re: [DNSOP] some random dnse-triggered thoughts

[Stephane Bortzmeyer]

On Tue, Mar 04, 2014 at 06:15:37PM +,
 Joe Abley  wrote 
 a message of 34 lines which said:

> EDNS0 options are hop-by-hop. It's not obvious this is what we need,
> since that makes every intermediate DNS server a potential
> interception point. But perhaps that's ok anyway, if we imagine the
> 80% solution involves stub -> resolver -> authority where each arrow
> is a separate privacy domain anyway.

More generally, we need to decide whether we want a truly end-to-end
solution (which would be very much at odds with the architecture of
the DNS) or if we are happy to protect only the messages in transit,
leaving the issues of syping by intermediate servers to other
solutions (QNAME minimization, local caching resolvers...).

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

[DNSOP] QUIC for DNS confidentiality (Was: my dnse vision

[Stephane Bortzmeyer]

On Wed, Mar 05, 2014 at 11:33:07AM +,
 Miek Gieben  wrote 
 a message of 22 lines which said:

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

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.

___
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

[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: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] some random dnse-triggered thoughts

[João Damas]

On 05 Mar 2014, at 14:12, Stephane Bortzmeyer  wrote:

> More generally, we need to decide whether we want a truly end-to-end
> solution (which would be very much at odds with the architecture of
> the DNS) or if we are happy to protect only the messages in transit,
> leaving the issues of syping by intermediate servers to other
> solutions (QNAME minimization, local caching resolvers…).

perhaps there is a need to separate the problem into tractable chunks.
For the part of the problem about authenticating the recursive resolver (the 
fake 8.8.8.8 problem) we probably a different solution than for the metadata 
snooping problem (who is asking for what).
Perhaps it might be the case there are already existing features that can be 
used to get what we need (e.g. SIG(0) for the recursive resolver, wild!) and, 
as Roy Arends was mentioning over a few drinks, onion-like routing to separate 
the who from the what in questions in an effective manner.
These could be even user-triggered on demand for certain traffic types (For 
instance as a consequence of turning on private browsing in a browser), so the 
overhead penalties are only incurred for the desired subset of traffic.

Joao



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

[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] On some terminology in draft-ietf-dnsop-respsize (truncation)

[Stephane Bortzmeyer]

On Tue, Mar 04, 2014 at 05:32:09PM +1100,
 Mark Andrews  wrote 
 a message of 24 lines which said:

> *Glue records are not optional in a referral.*

Why? A resolver can always reissue A and  requests after receiving
NS RRsets without glue. This increase latency but it will work.

But there is more: in a referral, sending *all* the glue records *is*
optional.

% dig +bufsize=512 @f.root-servers.net A www.internautique.fr

; <<>> DiG 9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu1.1 <<>> 
+bufsize=512 @f.root-servers.net A www.internautique.fr
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29492
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 7
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.internautique.fr.  IN A

;; AUTHORITY SECTION:
fr. 172800 IN NS f.ext.nic.fr.
fr. 172800 IN NS d.nic.fr.
fr. 172800 IN NS d.ext.nic.fr.
fr. 172800 IN NS e.ext.nic.fr.
fr. 172800 IN NS g.ext.nic.fr.
fr. 86400 IN DS 20122 8 2 (
A4208B55FFB352EDC816D9329283DD8BBDDE44C58539
5AF9AA7275ABE3CF6795 )
fr. 86400 IN DS 35095 8 2 (
23C6CAADC9927EE98061F2B52C9B8DA6B53F3F648F81
4A4A86A0FAF9843E2C4E )
fr. 86400 IN RRSIG DS 8 1 86400 (
2014031200 2014030423 33655 .
PG6KEeoGIzsI1KnwWLFCjbmfy9Gvc8EyOlHaAR/vBMD9
kGKZW68OczNt95JwpA0xTRBBH+4wdxNZhrIiScJ4vT/A
mjrwt2sV1SPFl1+gdX0yynYVwFd+5aVhOsZO7Djo/KzZ
3HmHxttWjZGnQDbok5sUNuPwcKu2zENiwDsIS9M= )

;; ADDITIONAL SECTION:
d.ext.nic.fr.   172800 IN A 192.5.4.2
d.nic.fr.   172800 IN A 194.0.9.1
e.ext.nic.fr.   172800 IN A 193.176.144.22
f.ext.nic.fr.   172800 IN A 194.146.106.46
g.ext.nic.fr.   172800 IN A 194.0.36.1
d.ext.nic.fr.   172800 IN  2001:500:2e::2

;; Query time: 180 msec
;; SERVER: 2001:500:2f::f#53(2001:500:2f::f)
;; WHEN: Wed Mar 05 14:46:51 GMT 2014
;; MSG SIZE  rcvd: 500

Note all the glue records were sent and, yet, BIND did not set TC=1.

___
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

[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] *.DNS metaTLD [ref: additional special names]

[Stephane Bortzmeyer]

On Mon, Mar 03, 2014 at 01:09:24PM +,
 Joe Abley  wrote 
 a message of 32 lines which said:

> It's clear that it's possible to arrange very stable registration of
> domains, sufficient at least for some very valuable web properties
> to base their businesses on.

When you are a big company like amazon.com or google.com with money,
lawyers and so on. Not when you are a free software project ran by
volunteers.

> I suggest that it's entirely plausible for someone to choose a
> DNS-namespace anchor for their non-DNS namespace that is as stable
> as they want, depending on their needs.

Many people who lost their domain name would like to know how to do
that.

___
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] some random dnse-triggered thoughts

[Jelte Jansen]

On 03/05/2014 02:40 PM, João Damas wrote:
> 
> perhaps there is a need to separate the problem into tractable
> chunks. For the part of the problem about authenticating the
> recursive resolver (the fake 8.8.8.8 problem) we probably a
> different solution than for the metadata snooping problem (who is
> asking for what). Perhaps it might be the case there are already
> existing features that can be used to get what we need (e.g. SIG(0)
> for the recursive resolver, wild!) and, as Roy Arends was
> mentioning over a few drinks, onion-like routing to separate the
> who from the what in questions in an effective manner. These could
> be even user-triggered on demand for certain traffic types (For
> instance as a consequence of turning on private browsing in a
> browser), so the overhead penalties are only incurred for the
> desired subset of traffic.
> 

+1. I don't want to fight about requirements for 10 years, and it does
look like there are different and competing views as to what
constitutes confidentiality here. So a split into several problems,
which can have shared or separate solutions, seems like a good start.

Jelte

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

Re: [DNSOP] *.DNS metaTLD [ref: additional special names]

[Christian Grothoff]

On 03/05/2014 03:50 PM, Stephane Bortzmeyer wrote:
> On Mon, Mar 03, 2014 at 01:09:24PM +,
>  Joe Abley  wrote 
>  a message of 32 lines which said:
> 
>> It's clear that it's possible to arrange very stable registration of
>> domains, sufficient at least for some very valuable web properties
>> to base their businesses on.
> 
> When you are a big company like amazon.com or google.com with money,
> lawyers and so on. Not when you are a free software project ran by
> volunteers.
> 
>> I suggest that it's entirely plausible for someone to choose a
>> DNS-namespace anchor for their non-DNS namespace that is as stable
>> as they want, depending on their needs.
> 
> Many people who lost their domain name would like to know how to do
> that.

Yes, and while you're at it, please tell the people from
thepiratebay.org --- their ability to keep a stable DNS namespace anchor
has been abysmal recently.

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

Re: [DNSOP] some random dnse-triggered thoughts

[Tim Wicinski]

On 3/5/14, 3:02 PM, Jelte Jansen wrote:

+1. I don't want to fight about requirements for 10 years, and it does
look like there are different and competing views as to what
constitutes confidentiality here. So a split into several problems,
which can have shared or separate solutions, seems like a good start.

Jelte

The Chairs have no intention of letting any requirements vetting take 
the 'allotted IETF time' of 10 years.


If we split it into multiple problems, then so be it.


___
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

[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

[DNSOP] Second Session to discuss DNS Privacy et. al.

[Tim Wicinski]

All,

We have decided after much discussion (and little negative feedback) to 
hold a seperate session Thursday Evening at 16:40 to discuss DNS privacy 
and all the things that come with it.


While this is a two hour time slot, we are only going to schedule *one* 
hour for this discussion.


Additionally, we're going to publish a separate agenda attempting to 
frame this discussion, to prevent it from spiraling out of control.


If anyone has anything they wish to bring up specific points, please 
contact the chairs directly.


thanks
tim/suzanne

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

Re: [DNSOP] *.DNS metaTLD [ref: additional special names]

[Warren Kumari]

On Mon, Mar 3, 2014 at 1:20 PM, Joe Abley  wrote:
>
> On 3 Mar 2014, at 13:12, Ted Lemon  wrote:
>
>> On Mar 3, 2014, at 1:09 PM, Joe Abley  wrote:
>>> I suggest that it's entirely plausible for someone to choose a 
>>> DNS-namespace anchor for their non-DNS namespace that is as stable as they 
>>> want, depending on their needs.
>>
>> This is clearly not the case for an open protocol spec, though, since there 
>> is no one entity that could be responsible for maintaining the registration.
>
> Certainly there could be cases where that is true. I can't think of an 
> example from the candidates we've identified in this (and other threads) to 
> date, though.
>
> (e.g. tor -> eff.org; dns -> okturtles.com).
>

because I don't want my leaked query for www.nakedfurries.foo to hit
the wimble.example.com nameservers? Even if I currently trust them not
to be logging that.

Putting .foo under .alt and making it a locally served zone (return
NXDOMAIN for all queries) means that my leaked queries only hit my
local resursive. And not everyone's leaked queries get aggregated
somewhere. The ALT doc also suggests that stubs could drop queries,
and then they wouldn't even hit the recursive ( I suspect that this is
not likely, but...)

W



> There's inevitably *someone* who needs to take a lead on coordinating any 
> codebase, if the codebase is to produce anything useful. I'm suggesting that 
> that person could easily register a domain.
>
>
> Joe
> ___
> 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

Re: [DNSOP] Second Session to discuss DNS Privacy et. al.

[Tim Wicinski]

I meant to say 18:40

Apologies.

tim

On 3/5/14, 3:16 PM, Tim Wicinski wrote:


All,

We have decided after much discussion (and little negative feedback) 
to hold a seperate session Thursday Evening at 16:40 to discuss DNS 
privacy and all the things that come with it.


While this is a two hour time slot, we are only going to schedule 
*one* hour for this discussion.


Additionally, we're going to publish a separate agenda attempting to 
frame this discussion, to prevent it from spiraling out of control.


If anyone has anything they wish to bring up specific points, please 
contact the chairs directly.


thanks
tim/suzanne



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

Re: [DNSOP] Second Session to discuss DNS Privacy et. al.

[Alexander Mayrhofer]

Tim,

> We have decided after much discussion (and little negative feedback) to hold
> a seperate session Thursday Evening at 16:40 to discuss DNS privacy and all
> the things that come with it.

Is that the correct time? The Agenda does list time slots starting at either 
17:00 or 18:40 - are you sure you don't mean 18:40?

thanks for clarification,
Alex


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

[DNSOP] Agenda - Additional DNSOP meeting on DNS Privacy, Thursday 1840-1940, Sovereign

[Tim Wicinski]

dnsop,

To avoid conflict with UTA, which seems to have a lot to say about this 
topic, and turned into a conflict, we've set this meeting up.  Here is a 
very rough agenda.  Our AD will make sure other groups are informed as 
well.


Our focus is to attempt to nail down the problem space (or problem 
spaces as someone pointed out). The solutions listed below are just what 
is current, and we are attempting to take a step back and look for the 
pros and cons of each option.


thanks
tim
---


WG: DNS Operations (dnsop)
Meeting:IETF 89, London
Location:   Hilton Metropole, Sovereign
Date:   Thursday, 6 March 2014
Time:   1840-1940 GMT
Chairs: Tim Wicinski 
Suzanne Woolf 



Special Meeting to discus DNS Privacy

1) Introduction

* Summarize problem statement
Formal adoption, anointing of reviewers

* DNSE summary
* Interest in the problem
* Overview of obvious existing protocol solutions
* Where from here on specification/analysis of problem space?

* Requirements/tradeoffs
* UDP/TCP
* Middlebox Problem
* Small enough protocol changes to take only finite time
* Clarity on what we can’t do, e.g. prevent traffic analysis
entirely
* Which parts of the relationship/transaction trying to
protect? From what threats? (priorities)

* Solution space
* A Comparison of solution space ala RFC 5479 is needed
* draft-bortzmeyer-dnsop-privacy-sol
* draft-wijngaards-dnsop-confidentialdns-00
* draft-rafiee-intarea-cga-tsig
* draft-hzhwm-start-tls-for-dns
* QNAME minimization

2) Next steps
* Adopt/review problem statement
* Missing document on requirements/tradeoffs:
* who wants to write this?
* How to approach solutions?
* How much complexity is tolerable?
* Can we do anything simple?
* Backwards compatibility required?
* How much of the work can we do here (charter discussion)
* Call for someone shepherd for topic in the WG

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