Re: [DNSOP] my dnse vision

"Hosnieh Rafiee" <> Wed, 05 March 2014 11:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4EA7D1A040E for <>; Wed, 5 Mar 2014 03:20:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.447
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wjmjss4orQQw for <>; Wed, 5 Mar 2014 03:20:44 -0800 (PST)
Received: from ( [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) by (Postfix) with ESMTP id A04921A04AC for <>; Wed, 5 Mar 2014 03:20:41 -0800 (PST)
Received: from localhost (unknown []) by (Postfix) with ESMTP id 976EC23E2D59; Wed, 5 Mar 2014 11:20:36 +0000 (UTC)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w7zwfzu6F6k6; Wed, 5 Mar 2014 12:20:35 +0100 (CET)
Received: from kopoli ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 804F123E2D58; Wed, 5 Mar 2014 12:20:35 +0100 (CET)
From: "Hosnieh Rafiee" <>
To: "'Francis Dupont'" <>, <>
References: <>
In-Reply-To: <>
Date: Wed, 5 Mar 2014 12:20:33 +0100
Message-ID: <00de01cf3864$ec8f67e0$c5ae37a0$>
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
Subject: Re: [DNSOP] my dnse vision
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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
> 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
> Domain Server :-), in the same area and uses IPsec to protect it. You can
> 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

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
> resolver will anyway make other related requests so the extra delays will
> 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
> 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