Re: [DNSOP] CPE devices doing DNSSEC

Patrik Fältström <paf@frobbit.se> Sun, 09 March 2014 12:19 UTC

Return-Path: <paf@frobbit.se>
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 24CAD1A036E for <dnsop@ietfa.amsl.com>; Sun, 9 Mar 2014 05:19:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.198
X-Spam-Level:
X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 K8l7CNouG4N0 for <dnsop@ietfa.amsl.com>; Sun, 9 Mar 2014 05:19:34 -0700 (PDT)
Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3271A036C for <dnsop@ietf.org>; Sun, 9 Mar 2014 05:19:34 -0700 (PDT)
Received: from ix-2.local (unknown [194.72.72.170]) by mail.frobbit.se (Postfix) with ESMTPSA id 0F4C9206A0; Sun, 9 Mar 2014 13:19:27 +0100 (CET)
Message-ID: <531C5C4D.4010700@frobbit.se>
Date: Sun, 09 Mar 2014 12:19:25 +0000
From: =?windows-1252?Q?Patrik_F=E4ltstr=F6m?= <paf@frobbit.se>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Patrik Wallstrom <pawal@blipp.com>
References: <20140307100524.2F42810CD58F@rock.dv.isc.org> <A0D47DA8-6E19-4A61-8A7C-FE960A0FA7E9@cybersecurity.org> <20140308090009.5E51210D1595@rock.dv.isc.org> <531C2637.6020405@frobbit.se> <6175B0CC-D8E3-44BB-83DD-7DA8548E6120@blipp.com>
In-Reply-To: <6175B0CC-D8E3-44BB-83DD-7DA8548E6120@blipp.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FGNL2vn2bNguMbe16m33fhV9nTlwmimxX"
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/7rpkLsGHdEoDVJVTjeugzFaXNq8
Cc: dnsop@ietf.org, Paul Hoffman <paul.hoffman@cybersecurity.org>
Subject: Re: [DNSOP] CPE devices doing DNSSEC
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: Sun, 09 Mar 2014 12:19:36 -0000

On 2014-03-09 10:19, Patrik Wallstrom wrote:
> But the fact is that EPP is several magnitudes better harmonized
> between TLDs compared to that registrars are offering their
> customers. There is no way around that today, and the registrars have
> no incentive at all to improve the situation. For all the registrars
> to offer the same API to their customers would really remove the
> lock-in effect that the proprietary interfaces that they have today.

The same lock-in as registries use already today with registrars.

My point is that there is absolutely no difference between how
registries lock in registrars (and because of that the registrants) and
how the registrars lock in customers.

Harmonizing the interface to registrars is _extremely_hard_ given how
different the epp implementation is for the registries. The registrars
that "lock in" (using your terminology) the registrants do that mainly
because they support a specific flavor of registries, and have designed
their API for those registries. If other registries where to be
supported, the API would be different.

> So how could we change this? I don’t see this happening from a
> standard organization at all. So yes - registrars is really a big
> reason for incompatibility. Registries could easily bypass the
> current rrr model by exposing API:s directly to registrants, but it
> wouldn’t be very popular with the registrars…

In no particular order:

1. By having people stop claiming epp is one protocol and blaming the
registrars being the problem. Pointing fingers does not help, because as
in this thread, energy has to be spent on explaining the differences in
epp between TLDs.

2. By having registries agreeing on whether DS or DNSKEY is the data
they want, or by accepting both.

3. By having the IETF effort of to start with cataloging the epp
extensions used by registries, and secondly working hard to try to
harmonize the extensions.

4. By having the registrars that have an API harmonize their efforts
just like registries harmonize theirs.

Also: note that registries do sent the wholesale price for the domain
registration, and the price on the market today for domain names is set
by the ones that cross subsidize domain name costs with income from
other services. Because of that there is a price squeeze which in some
markets turn into negative revenue for registrars that sell domain
names. Registries that now and then dump the wholesale prices does not
make the situation better, as the end users start to believe the price
is very low. Registrars complain on this behavior by registries, but the
registries continue to do price dumping -- i.e. continue the price squeeze.

Given this pricing structure, and that registries do change their
implementations far too often, where do you think registrars do spend
the money they have? They MUST support what the changes the registries
do, they do not HAVE TO implement a common API.

So, the registries MUST be the ones that start. Although there are many
registrars that will follow. Including Frobbit that I am technical lead at.

Now as I wrote above, IETF have started some very good work on epp
extensions but I am amazed how many registries refuse to participate,
complain, and fight against it. As long as they do, why should
registrars be nice(r)?

The market is broken, and as I said, I think we in IETF (when I was Area
Director btw) where too nice when the whole epp work took place.

   Patrik