Re: Using DNS system as a Global Root Certificate Authority - possible ?

John C Klensin <john-ietf@jck.com> Sun, 27 December 2015 23:58 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0EF1A701A for <ietf@ietfa.amsl.com>; Sun, 27 Dec 2015 15:58:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.101
X-Spam-Level: ****
X-Spam-Status: No, score=4.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] autolearn=no
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 xHl7ziTIMEBS for <ietf@ietfa.amsl.com>; Sun, 27 Dec 2015 15:58:51 -0800 (PST)
Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5561A7018 for <ietf@ietf.org>; Sun, 27 Dec 2015 15:58:51 -0800 (PST)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1aDLCy-000M4O-Kl; Sun, 27 Dec 2015 18:58:40 -0500
Date: Sun, 27 Dec 2015 18:58:35 -0500
From: John C Klensin <john-ietf@jck.com>
To: Patrik Fältström <paf@frobbit.se>, Eliot Lear <lear@cisco.com>
Subject: Re: Using DNS system as a Global Root Certificate Authority - possible ?
Message-ID: <2BDFA6F6BDEDC6658D9EABE6@JcK-HP5.jck.com>
In-Reply-To: <67A5A7EF-BDDA-4507-88F5-4021D685479E@frobbit.se>
References: <CAOJ6w=EdXPzK7f=zS0epuYXkkEcwtop11Ttt6QUR1-FtN1rGWg@mail.gmail.com> <CAMm+LwgGhs_W9g2yG-HC6YDBiz++Z-G5hbNL=bFGAcDQXJK9AA@mail.gmail.c om> <D24618171F1482DB31C6B8AB@JcK-HP5.jck.com> <23F80B32-B026-4122-8EFD-52EA70A9D5B9@frobbit.se> <567FDBD1.4010703@cisco.com> <67A5A7EF-BDDA-4507-88F5-4021D685479E@frobbit.se>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/A3fJdx1RLlMhaPd-6zzHrLILyzc>
Cc: ietf <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Dec 2015 23:58:53 -0000


--On Sunday, December 27, 2015 2:42 PM +0100 Patrik Fältström
<paf@frobbit.se> wrote:

> My only point was that it is not at all the case that all
> registrars can make changes to any subdomain of a domain
> managed by a registry, which was what I read in what John
> wrote:
> 
>> At that point, the number of trusted intermediaries gets back
>> toward order 40 or 100, not one, unless the question is "do
>> you control this domain" rather than "are you who you say you
>> are".
> 
> The registry do keep track of which ones of the registrars can
> make changes, so not every registrar (i.e. intermediary) can
> become "trusted".
> 
> If I misunderstood what he wrote, my apologies.

You did misunderstand the point I was trying to make, which
isn't about "who can make a change" but about "who can put the
name there in the first place", i.e., make an initial
registration.  The issue, as usual, comes down to what threats,
and threat model, one is concerned about.  If, as Victor's note
seems to suggest, the main concern is being able to find a key
with which to encrypt and have some reasonable confidence that
whoever controls the key also controls the relevent domain, then
that is one sort of problem.  If one is concerned about assuring
the user that the site is the intended one and, more to the
point, that anything encrypted to a particular key (whether
found/certified through a "normal" X.509 PKI mechanism or
something DANE-like) will be readable only to the intended
recipient, then that is a different sort of problem.

As a handy real-world example, consider
  ford.com
  fordmotorcompany.com
  fordcarcompany.com

The first two use the same registrar, the same name servers, and
have admin information that points to Ford Motor Company's
corporate HQ information.   The third uses a registrar in
Australia, identifying information that is as hidden as
possible, and a web site that apparently won't expose any
information at all unless one allows it to run scripts on the
local machine.   Nothing prevents such a registration, nor
prevents if from being used in a deceptive manner, nor setting
up keys that are bound to it, except the integrity of the
registrar, and I (much less a typical user) has no practical way
of determining whether "Fabulous.com Pty Ltd." is trustworthy.  

Moreover, were Ford to let "fordmotorcompany.com" lapse --
intentionally or not -- there is nothing in ICANNs systems or
that of Verisign (as the registry operator for COM.) that would
prevent FraudRUs, operating as, or as a reseller of, an
ICANN-accredited registrar, grabbing the name, generating new
keys and/or certs, and committing evil deeds against any user
who stumbled upon that site, perhaps through habits or
established bookmarks.

So, again, it depends on what problem one is trying to solve,
which threat models are of interest, etc.

  best,
    john




> [1] SAC-057:
> https://www.icann.org/en/groups/ssac/documents/sac-057-en.pdf
> [2] SAC-075:
> https://www.icann.org/en/groups/ssac/documents/sac-075-en.pdf