Re: [DNSOP] my dnse vision

"Hosnieh Rafiee" <ietf@rozanak.com> Wed, 05 March 2014 11:20 UTC

Return-Path: <ietf@rozanak.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA7D1A040E for <dnsop@ietfa.amsl.com>; Wed, 5 Mar 2014 03:20:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level:
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjmjss4orQQw for <dnsop@ietfa.amsl.com>; Wed, 5 Mar 2014 03:20:44 -0800 (PST)
Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) by ietfa.amsl.com (Postfix) with ESMTP id A04921A04AC for <dnsop@ietf.org>; Wed, 5 Mar 2014 03:20:41 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 976EC23E2D59; Wed, 5 Mar 2014 11:20:36 +0000 (UTC)
X-Virus-Scanned: amavisd-new at rozanak.com
Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7zwfzu6F6k6; Wed, 5 Mar 2014 12:20:35 +0100 (CET)
Received: from kopoli (f052010124.adsl.alicedsl.de [78.52.10.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 804F123E2D58; Wed, 5 Mar 2014 12:20:35 +0100 (CET)
From: Hosnieh Rafiee <ietf@rozanak.com>
To: 'Francis Dupont' <Francis.Dupont@fdupont.fr>, dnsop@ietf.org
References: <201403051107.s25B7ext069332@givry.fdupont.fr>
In-Reply-To: <201403051107.s25B7ext069332@givry.fdupont.fr>
Date: Wed, 05 Mar 2014 12:20:33 +0100
Message-ID: <00de01cf3864$ec8f67e0$c5ae37a0$@rozanak.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJiS6q6T1tlkOYN1eNhaY5UvPV96JmsMGBA
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/8LSUbq08RmpLF2670P-sMoeekao
Subject: Re: [DNSOP] my dnse vision
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Mar 2014 11:20:46 -0000

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