[DNSOP] my dnse vision

Francis Dupont <Francis.Dupont@fdupont.fr> Wed, 05 March 2014 11:07 UTC

Return-Path: <Francis.Dupont@fdupont.fr>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id EC5321A0462 for <dnsop@ietfa.amsl.com>; Wed, 5 Mar 2014 03:07:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id gGq9OaGX_VEO for <dnsop@ietfa.amsl.com>; Wed, 5 Mar 2014 03:07:45 -0800 (PST)
Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id A4DEC1A045B for <dnsop@ietf.org>; Wed, 5 Mar 2014 03:07:44 -0800 (PST)
Received: from givry.fdupont.fr (localhost []) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id s25B7ext069332 for <dnsop@ietf.org>; Wed, 5 Mar 2014 12:07:40 +0100 (CET) (envelope-from dupont@givry.fdupont.fr)
Message-Id: <201403051107.s25B7ext069332@givry.fdupont.fr>
From: Francis Dupont <Francis.Dupont@fdupont.fr>
To: dnsop@ietf.org
Date: Wed, 05 Mar 2014 12:07:40 +0100
Sender: Francis.Dupont@fdupont.fr
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/Z6AK-mOJrWVdw-U0Tue_d_qwhbE
Subject: [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:07:48 -0000

>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

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.