Re: new RRTYPEs, was DNSSEC architecture vs reality
Phillip Hallam-Baker <phill@hallambaker.com> Thu, 15 April 2021 14:34 UTC
Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809173A2240 for <ietf@ietfa.amsl.com>; Thu, 15 Apr 2021 07:34:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 gwLWPgXxyeqX for <ietf@ietfa.amsl.com>; Thu, 15 Apr 2021 07:34:43 -0700 (PDT)
Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com [209.85.219.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BB003A223D for <ietf@ietf.org>; Thu, 15 Apr 2021 07:34:43 -0700 (PDT)
Received: by mail-yb1-f171.google.com with SMTP id x8so21232287ybx.2 for <ietf@ietf.org>; Thu, 15 Apr 2021 07:34:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jJiRMQibnBTCMCva63IplvNN+N+bW4TwkMpH+8bxJt4=; b=bVg40WYy+pcb/KLgUhFCvvvtWYWxhFSopMIYWv/id/BXeODDYFMgd7mFY8deafRErn o6FgV17uH+BajcnhmhzC21DcPnfanrKy4+ymtpF8o4Vn0srDngBkALrmBacNApp4z0Cv rpABgwF5iZVh9lFH1aEieuLC/bhv8Kvb0kawIklkKM54pkiHbkd8kno63tgkxlKBL0v3 glIvh6ATMUw+Zj8OYnnf8LXnVCL5miIAA5hoQ2/nuuXbjT0XsR71iYu93iLiKvhgJGbk jeHSb8yTXLcN6D39MdPwB6vJhfDgz7UXP1ZFuPrmYMPyFQjBSvWc2GxU7GPVjstrZIDR seLg==
X-Gm-Message-State: AOAM5309vBFjOwHLM/ZquOgzPTg6rub/icw8KDumSmQ8Wm4uyxjj5m8c jFL5KnOjobanYsCeJKY4AsgZvCtuGCLYRX7ny1U=
X-Google-Smtp-Source: ABdhPJwm2Ab+e9s6fuiC0lxGC5ugk0FA2g3+Pr8k4ODHHR/D9VEqjrjUA/IZR+MfCs25vsgeP9ubtbRN2ZY3pK+v/Yk=
X-Received: by 2002:a25:316:: with SMTP id 22mr5126284ybd.523.1618497282258; Thu, 15 Apr 2021 07:34:42 -0700 (PDT)
MIME-Version: 1.0
References: <20210413015000.9297272C47BA@ary.qy> <C8C39247-226E-4C78-88E8-3AC215F2FF21@isc.org> <1c90249a-a9ad-52dd-bbc5-5e4bc6e6bdf@taugh.com> <CAMm+LwhEmiQOYtP807n2Gm2MKq7cGhMoCB_hkJxPZCQ9uatW8Q@mail.gmail.com> <YHdE/p3Oz5f6PVa2@straasha.imrryr.org> <CAMm+Lwj0BAb6nNQT13xT06jgEYA=pBh1OpPhiK2PQ_4CtfbHPQ@mail.gmail.com> <354449086.84554.1618481473526@appsuite-gw2.open-xchange.com>
In-Reply-To: <354449086.84554.1618481473526@appsuite-gw2.open-xchange.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Thu, 15 Apr 2021 10:34:30 -0400
Message-ID: <CAMm+Lwgkeg_tytUpk0nW6f3ooVHwHHVRmej9f5wj4pJzw1=PMw@mail.gmail.com>
Subject: Re: new RRTYPEs, was DNSSEC architecture vs reality
To: Vittorio Bertola <vittorio.bertola@open-xchange.com>
Cc: IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000943cf605c003c3de"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/akJXQF3KIlnN6dUa4iBbkXHSuwY>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 15 Apr 2021 14:34:49 -0000
On Thu, Apr 15, 2021 at 6:11 AM Vittorio Bertola < vittorio.bertola@open-xchange.com> wrote: > > Il 14/04/2021 21:57 Phillip Hallam-Baker <phill@hallambaker.com> ha > scritto: > > Yes, this does leave money on the table but I reckon that there Mesh > foundation needs an income of about $10 million /year to do what I want it > to achieve. Running the registry should cost less than a million. The rest > will go to funding open source specs and reference code, funding > conferences, etc. etc. > > And the IETF. I mean, the IETF, through several indirection layers, gets a > big chunk of its funding from the fact that ISOC runs .org. If this dries > up in favour of your foundation, I'm sure that you will be willing to pick > up the sponsorship of the IETF - and also of all other events and > organizations that currently get sponsored by a gTLD registry. > That is not my concern and should not be the concern of the IETF. A member of ISOC told me the potential conflict of interest was one of the motivations for the sale. It is a real pity that the EFF decided to stab us in the back with their own fund raising effort. I am not the guy who is creating the conflict of interest here, that is for ISOC to sort out. Of course, the fact I am putting a proposal on the table that makes the conflict relevant might well give them the ability to submit a new proposal. I would suggest that the jack up the prices first so that concern is also neutralized. At this point I have been a part in starting or making major changes in direction to two other standards bodies and played a leading role in forming two industry associations. I am using IETF to provide the Note Well IPR cover, I am not asking anyone for permission, that is not how I work. But wait, there's more: in many countries, ccTLD registries are a > significant source of funding for all sorts of national Internet projects - > research, localization of technology, education, events, industry > standardization, governance discussions, content policy enforcement, you > name it. You would of course need to spread your funds evenly throughout > the planet. > Not my problem to replace other people's rents. even if they give a pittance back in charity. In case you hadn't noticed, the mail system and the telephone numbering system are both in widespread use today despite the underlying technologies being obsolete. Most people still have fax numbers on their business cards (!). I think it really unlikely DNS names are going to go away in our lifetimes. The 'worst' that could happen is the pace of growth slows somewhat and the speculative activity moves away. I don't think we will seeing the denizens of ICANN-land selling their yachts. No, as they put it in the Godfather, I am not a communist. The not for > profit registry is separate from my for-profit Mesh Service Provider and > apps businesses. > > The tricky part here will be to make sure that certain names with valid > IPR claims end up in the right place. Obviously, @microsoft, @apple, @cisco > etc. have to go to the right place or there is a security issue. But again, > read the draft. > > Well, it took seven years for ICANN to decide whether ".amazon" should go > to Amazon the company or to Amazon the geographic region as represented by > ACTO ( > https://en.wikipedia.org/wiki/Amazon_Cooperation_Treaty_Organization) and > by the sovereign countries that formed it, and even after the decision was > taken, the concerns and the complaints have not ended yet. Perhaps you can > come up with a better, more fair solution that will not create > international tensions and will not just award politically, socially or > religiously relevant names to those that show up with the biggest pile of > money (speaking of diversity and inclusiveness...). However, your draft > seems silent on this kind of problems, which are also part of the reason > why domain names have a price way higher than their operational cost. > I am sure it doesn't cost a quarter million dollars to do this. In fact I know that it doesn't. I was Principal Scientist for VeriSign for over a dozen years. I know these issues at least as well as anyone else. In my case the answer is very easy: I need Jeff Bezos on my side for the Mesh to be successful and it is essential that @amazon resolve to the place most expect. For similar reasons, the claims made for @google by those claiming to represent the number are not something to worry about. [Oh and no, I am not so naive as to accept for an instant the premise that the .amazon bunfight is anything more than an attempt to use indigenous rights as a pretext to extort a large amount of cash from a party with deep pockets, absolutely none of which will ever go to the people on behalf of whom the claim is being made.] Did they take seven years because it was a difficult problem or because it was easier to not make a decision? I rather think the latter. What you are showing is how the ad hoc rentier model failed. > I do not necessarily disagree with your idea, but it looks to me that you > are underestimating its non-technical impact if it ever succeded - or, if > you prefer, the amount of pushback against implementation for non-technical > reasons. > I have done core crypto for over 25 years. That work makes a heck of a lot of governments unhappy. It is the main reason I live in the US rather than the UK: the legality of my work was certainly not accepted by HMG when I started. The Callsign registry isn't just a name registry, it is the hub of a PKI. Which is why I believe it has a chance of being successful. Every callsign registered is bound to a public key by definition. And that binding is immutable, it can be superseded but never erased. So it provides a functionality the legacy systems never can. There will be no such thing as 'callsign validated certificates': The callsign is the key. There is a business model for CAs of course. Just not the current model which Google is trying to dismantle anyway. Dismissing complex claims by incumbent rent seekers is not 'ignorance', it is a deliberate design decision taken with full awareness of the consequences. There are some stakeholders I need, some that can be helpful and others I choose to ignore.
- Quic: the elephant in the room Michael Thomas
- Re: Quic: the elephant in the room Phillip Hallam-Baker
- Re: Quic: the elephant in the room Michael Thomas
- Re: Quic: the elephant in the room Ben Laurie
- Re: Quic: the elephant in the room Stephane Bortzmeyer
- Re: Quic: the elephant in the room Ben Laurie
- Re: Quic: the elephant in the room Phillip Hallam-Baker
- Re: Quic: the elephant in the room Michael Thomas
- Re: Quic: the elephant in the room Nico Williams
- Re: Quic: the elephant in the room Viktor Dukhovni
- Re: Quic: the elephant in the room Michael Thomas
- Re: DNS vs PKI, was Quic: the elephant in the room John Levine
- Re: DNS vs PKI, was Quic: the elephant in the room Michael Thomas
- Re: Quic: the elephant in the room Nico Williams
- Re: Quic: the elephant in the room Michael Thomas
- Re: Quic: the elephant in the room Nico Williams
- Re: Quic: the elephant in the room Viktor Dukhovni
- Re: Quic: the elephant in the room Michael Thomas
- Re: Quic: the elephant in the room Michael Thomas
- Re: Quic: the elephant in the room Phillip Hallam-Baker
- Re: Quic: the elephant in the room Viktor Dukhovni
- Re: Quic: the elephant in the room Phillip Hallam-Baker
- Re: Quic: the elephant in the room Ben Laurie
- Re: Quic: the elephant in the room Ben Laurie
- Re: Quic: the elephant in the room Ben Laurie
- Re: Quic: the elephant in the room Michael Thomas
- Re: Quic: the elephant in the room Michael Thomas
- Re: Quic: the elephant in the room Viktor Dukhovni
- Re: Quic: the elephant in the room Michael Thomas
- Re: Quic: the elephant in the room Nico Williams
- Re: Quic: the elephant in the room Nico Williams
- Re: Quic: the elephant in the room Salz, Rich
- Re: Quic: the elephant in the room Michael Thomas
- Re: Quic: the elephant in the room Phillip Hallam-Baker
- Re: Quic: the elephant in the room Michael Thomas
- Re: Quic: the elephant in the room Phillip Hallam-Baker
- Re: Quic: the elephant in the room Nico Williams
- Re: Quic: the elephant in the room Michael Thomas
- Re: Quic: the elephant in the room Phillip Hallam-Baker
- Re: Quic: the elephant in the room Salz, Rich
- Re: Quic: the elephant in the room Ben Laurie
- Re: Quic: the elephant in the room Ben Laurie
- Re: Quic: the elephant in the room Michael Thomas
- Re: Quic: the elephant in the room Viktor Dukhovni
- Re: Quic: the elephant in the room Ben Laurie
- Re: Quic: the elephant in the room Phillip Hallam-Baker
- Re: Quic: the elephant in the room David Conrad
- Re: Quic: the elephant in the room David Conrad
- Re: Quic: the elephant in the room Viktor Dukhovni
- DNSSEC architecture vs reality (was: Re: Quic: th… Keith Moore
- Re: DNSSEC architecture vs reality (was: Re: Quic… Michael Thomas
- Re: Quic: the elephant in the room Nico Williams
- Re: Quic: the elephant in the room Salz, Rich
- Re: Quic: the elephant in the room Nico Williams
- Re: Quic: the elephant in the room Viktor Dukhovni
- Re: Quic: the elephant in the room Phillip Hallam-Baker
- Re: DNSSEC architecture vs reality (was: Re: Quic… Viktor Dukhovni
- Re: Quic: the elephant in the room Andrew McConachie
- Re: DNSSEC architecture vs reality Keith Moore
- Re: DNSSEC architecture vs reality Petite Abeille
- Re: Quic: the elephant in the room Salz, Rich
- Re: Quic: the elephant in the room Salz, Rich
- Re: Quic: the elephant in the room Phillip Hallam-Baker
- Re: DNSSEC architecture vs reality Marco Davids
- Re: Quic: the elephant in the room Phillip Hallam-Baker
- Re: Quic: the elephant in the room Michael Thomas
- Re: Quic: the elephant in the room Michael Thomas
- Re: Quic: the elephant in the room Phillip Hallam-Baker
- Re: Quic: the elephant in the room Michael Thomas
- Re: Quic: the elephant in the room Michael Thomas
- Re: Quic: the elephant in the room Salz, Rich
- Re: Quic: the elephant in the room Phillip Hallam-Baker
- Re: Quic: the elephant in the room Michael Thomas
- Re: Quic: the elephant in the room Michael Thomas
- Re: Quic: the elephant in the room Nico Williams
- Re: Quic: the elephant in the room Viktor Dukhovni
- Re: Quic: the elephant in the room Nico Williams
- Re: Quic: the elephant in the room Viktor Dukhovni
- Re: Quic: the elephant in the room Phillip Hallam-Baker
- Re: Quic: the elephant in the room Michael Thomas
- Re: Quic: the elephant in the room Nico Williams
- Re: Quic: the elephant in the room Nico Williams
- Re: Quic: the elephant in the room Viktor Dukhovni
- Re: Quic: the elephant in the room Michael Thomas
- Re: Quic: the elephant in the room Salz, Rich
- Re: Quic: the elephant in the room Viktor Dukhovni
- Re: Quic: the elephant in the room Phillip Hallam-Baker
- Re: Quic: the elephant in the room Nico Williams
- Re: Quic: the elephant in the room Salz, Rich
- Re: Quic: the elephant in the room Viktor Dukhovni
- Re: Quic: the elephant in the room Salz, Rich
- Re: DNSSEC architecture vs reality Michael Thomas
- Re: DNSSEC architecture vs reality Nico Williams
- Re: DNSSEC architecture vs reality Michael Thomas
- Re: DNSSEC architecture vs reality Nico Williams
- Re: DNSSEC architecture vs reality Michael Thomas
- Re: DNSSEC architecture vs reality Nico Williams
- Re: DNSSEC architecture vs reality Michael Thomas
- Re: DNSSEC architecture vs reality John C Klensin
- Re: DNSSEC architecture vs reality Keith Moore
- Re: DNSSEC architecture vs reality Michael Thomas
- Re: DNSSEC architecture vs reality Michael Thomas
- Re: DNSSEC architecture vs reality Keith Moore
- Re: DNSSEC architecture vs reality Nico Williams
- Re: DNSSEC architecture vs reality Michael Thomas
- Re: DNSSEC architecture vs reality John C Klensin
- Re: DNSSEC architecture vs reality Keith Moore
- Re: DNSSEC architecture vs reality Michael Thomas
- Re: DNSSEC architecture vs reality Nico Williams
- Re: new RRTYPEs, was DNSSEC architecture vs reali… John Levine
- Re: new RRTYPEs, was DNSSEC architecture vs reali… Mark Andrews
- Re: DNSSEC architecture vs reality Petite Abeille
- Re: DNSSEC architecture vs reality Petite Abeille
- Re: DNSSEC architecture vs reality Andrew McConachie
- Re: DNSSEC architecture vs reality Patrik Fältström
- Re: DNSSEC architecture vs reality Eliot Lear
- Re: DNSSEC architecture vs reality Patrik Fältström
- Re: DNSSEC architecture vs reality Patrik Fältström
- Re: new RRTYPEs, was DNSSEC architecture vs reali… John R Levine
- Re: DNSSEC architecture vs reality Nico Williams
- Re: DNSSEC architecture vs reality Nico Williams
- Re: DNSSEC architecture vs reality Jim Fenton
- Re: DNSSEC architecture vs reality Masataka Ohta
- Re: DNSSEC architecture vs reality Petite Abeille
- Re: new RRTYPEs, was DNSSEC architecture vs reali… Phillip Hallam-Baker
- Re: new RRTYPEs, was DNSSEC architecture vs reali… Nico Williams
- Re: new RRTYPEs, was DNSSEC architecture vs reali… Donald Eastlake
- Re: new RRTYPEs, was DNSSEC architecture vs reali… Phillip Hallam-Baker
- Re: new RRTYPEs, was DNSSEC architecture vs reali… Viktor Dukhovni
- Re: new RRTYPEs, was DNSSEC architecture vs reali… Phillip Hallam-Baker
- Re: new RRTYPEs, was DNSSEC architecture vs reali… Vittorio Bertola
- Re: new RRTYPEs, was DNSSEC architecture vs reali… Phillip Hallam-Baker
- Re: Fwd: Quic: the Elephant in the Room Michael Thomas
- Fwd: Quic: the Elephant in the Room Lars Eggert
- RE: Fwd: Quic: the Elephant in the Room Vasilenko Eduard
- Re: Quic: the elephant in the room Ben Laurie
- Re: Quic: the elephant in the room Phillip Hallam-Baker