Re: hampering progress

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 21 April 2021 17:56 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 4F0163A3143 for <ietf@ietfa.amsl.com>; Wed, 21 Apr 2021 10:56:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, 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 KVSXL7nnWIC6 for <ietf@ietfa.amsl.com>; Wed, 21 Apr 2021 10:56:18 -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 5FEB93A3140 for <ietf@ietf.org>; Wed, 21 Apr 2021 10:56:13 -0700 (PDT)
Received: by mail-yb1-f171.google.com with SMTP id y2so46110824ybq.13 for <ietf@ietf.org>; Wed, 21 Apr 2021 10:56:13 -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=pqTiCjCymiT5Qcv2n/VsrVd+MtlGohHU1sy9p2V2Tms=; b=Y2JAOmi2Heu5efcPnncN4zITGo8Z4UENyk9IIFokWjaSOjKLdVvJP1APFQTPCQxz0L T5uY5/c69sPkxdNJSPdgs6i5Om+fE6umDYRq2DVPRXnYfblkQ4b9KeF1bUEmotHccBxJ OiLGJnMd36ZWqdXbJr9KTDG+8fpSztBMZiK4G2cADYyoR3STBYhIp9MOU+rymQ/7SxUz FuVZUEWYkMrBfcEmq/qFjVSgejEWsF6dZn3NNSCtodxpoEX6SDqJa7IFpgK2kEfSf2VE 9Kq/7pBO7qG1XEJMQjjCCyUkBX+Q9hz8ToK5DHMM5qlbKCErpQOsCVL3TKERsooeOBFP 1UXQ==
X-Gm-Message-State: AOAM530oa/9tM0GffpbKPeQOqYEfvaXn0guQ9fVcGDK6RxYR6vYUrORZ YhkQAhTWkcKsVoiuFY7JLCdJbi3lEAGENgmyzh9uxc40JI8XuQ==
X-Google-Smtp-Source: ABdhPJxslBSTnkukUuabm5iRby+vxGtXa2ngNMLF0Byh52emUNsRzJ4DeZKc0FVa/lF3ZTKirrqtvRuLTvwR9YzGBx8=
X-Received: by 2002:a5b:585:: with SMTP id l5mr31828243ybp.213.1619027772253; Wed, 21 Apr 2021 10:56:12 -0700 (PDT)
MIME-Version: 1.0
References: <93fedaa0-5ad0-dcc0-ff01-43b8e1c97989@mtcc.com> <19f2b2e1-6365-480a-86f2-111377cac2de@www.fastmail.com> <b69b742f-bc1d-9e00-7119-ff5b3ad6cfc5@gmail.com> <58650505-ce3c-e99f-fdf8-89e52ccb185e@mtcc.com> <1e150d1b-328f-071d-77a1-9cb7824abbd4@joelhalpern.com>
In-Reply-To: <1e150d1b-328f-071d-77a1-9cb7824abbd4@joelhalpern.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Wed, 21 Apr 2021 13:56:02 -0400
Message-ID: <CAMm+LwhhrtF+Zg9PAZKtwU0bGwVwYTPFf8tN7n5Z-KrBUxeBDQ@mail.gmail.com>
Subject: Re: hampering progress
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: Michael Thomas <mike@mtcc.com>, IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003f28ca05c07f4707"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/sHNl0ygnSHnRQnkeipAoolOJ2uY>
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: Wed, 21 Apr 2021 17:56:22 -0000

+1

The issue here is not just the charter. QUIC is a WG with over 100 active
participants. It has far greater need to keep focus than others.

In particular, when a WG chair asks 'why are you bringing this here when it
is really not QUIC specific', it is important to have a better answer than:

"I'm not asking this working group to do anything. Just socializing
something that generated a lot of discussion on the IETF list that might
be of interest to the Quic community."


The problem I have with your approach is that when people raised issues,
you didn't try to address them, you just told them they weren't issues.

One of the things I really like about the new RFC/ID format is that we can
now have diagrams showing the impact of a proposal. Turning a two party
protocol (initiator/responder) into a three party protocol (adding a DNS
resolver) to shave a couple of packets doesn't look like a win to me. In
fact it looks like a de-optimization if the information needed isn't
already in-cache.

Managing the number of Web servers Google has facing the world is hard. Its
the sort of infrastructure that when scoping a possible acquisition, I
would always have to budget several million dollars for a ground up
replacement simply because such infrastructures must by their very nature
rely on a great depth of local arcana that will walk out of the door the
day the people carrying it in their heads walk out the door. I would
certainly never presume to tell the operators of such systems that moving
from the WebPKI to DANE is easy.

Google already has free WebPKI certs for itself through GTS and for
everyone else through LetsEncrypt. So the value prop for DANE is limited to
shaving packets. And that requires people to sign their Zones which is
expensive because someone is going to have to crack open a manual and read
it. And that costs real money when folk are billing at $300-$500/hr.


The whole problem with DANE start to finish was that it was DNSSEC people
looking for a problem to solve. And they chose the wrong problem. The only
good reason to deploy DNSSEC is to publish security policy. And that isn't
viable unless you have

1) A means of expressing the security policy

2) A means of automating publication of the security policy to the DNS zone

3) A complete overhaul of the DNS client-resolver protocol to make THAT
efficient.

SMTP over TLS is not a useful paradigm because email is store and forward
and we don't care about latency.


The DNS world keeps shooting itself in the foot here and then complaining
nobody is taking them seriously. TLSA is too limited as a means of
describing security policy. RFC 6763 is the approach to build on as I show
in:

draft-hallambaker-web-service-discovery-05 - DNS Web Service Discovery
(ietf.org)
<https://tools.ietf.org/html/draft-hallambaker-web-service-discovery-05>


I do not have a mechanism for automating publication of the security policy
to the DNS but that is going to be one of the things the Mesh eventually
does for free as devices are connected to a personal Mesh.


DPRIV is another example of DNS world refusing to see beyond its limited
horizons and then complaining nobody is using their stuff. It was
abundantly clear that we needed to fix the broken DNS client resolver
protocol if there was going to be any takeup of DPRIV. Instead we were told
we must do this in a year so the only thing we can look at is DNS over TLS
which will require TCP fast start to be sufficiently performant.


I don't just suspect my work was sabotaged under BULLRUN, I know because
one of the people responsible apologized to me personally. I am pretty sure
that DPRIV and DANE were among the proposals deliberately sabotaged so as
to delay deployment of cryptographic systems that worked.

It is so easy for a whispering campaign to persuade people that the 'evil
CAs' are the ones only working for themselves. So ignore the proposals they
have been working on and circulating for five years now, schemes that don't
require a kernel change and instead do this thing someone just scribbled on
the back of a paper napkin in crayon.


That is all in the past now. We all have a job to do and it is to secure
the net. And we can't do that by thinking small. And we certainly can't do
that if we don't listen to and try to understand the stakeholders who have
to deploy if it is going to work.



On Wed, Apr 21, 2021 at 1:07 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:

> Michael, I hav eno idea whether your work was or was not appropriate for
> the QUIC working group.
>
> Arguing that working group chairs an not declare things out of scope
> weakens your overall argument.  Working groups have charters.  The
> chairs are expected to work within the charter.  Working group email
> lists are for discussion of topics relevant to the working group.
>
> Now, I will grant that charters are not precise.  Topics are not
> precise.  And chairs should (and generally do) err on the side of
> allowing some latitude.
> But claiming that chairs can not rule things as being out of scope does
> not match our process, and would hamper our work.  (Who has, as WG
> co-chair, suggested to more than one author team that the independent
> stream would make a better home for their work, as it does not fit the
> charter of the working group.)
>
> Yours,
> Joel
>
> On 4/21/2021 12:47 PM, Michael Thomas wrote:
> >
> > On 4/20/21 10:26 PM, Brian E Carpenter wrote:
> >>
> >> Every WG Chair, especially for a WG that has tight focus on a specific
> >> goal, meets the problem of potentially off-charter discussions that
> >> potentially hamper progress.
> >
> > This is an often repeated refrain, but I question its actual impact.
> > People reply to things because they have an opinion and are interested
> > enough in the subject to make time for it. Posing this as a zero sum
> > game is a fallacy: if they aren't interested enough at the business at
> > hand they simply won't reply at all. At some point things become noise,
> > but a few messages back and forth is hardly that point. In fact,
> > slightly off topic posts can bring useful insight to working groups, and
> > can be extremely useful for outsiders to understand what is going on. I
> > know of no other way to get that understanding other than simply asking
> > on the working group list. Do you?
> >
> > That and to be told by a working group chair *in their capacity* to go
> > away (and away to where? no answer) is dysfunctional, and sends a clear
> > message that interlopers will not be tolerated.
> >
> > Mike
> >
>
>