Re: [stir] stir-certs-01: Expert Review?

Brian Rosen <br@brianrosen.net> Mon, 20 April 2020 19:46 UTC

Return-Path: <br@brianrosen.net>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9283A0E45 for <stir@ietfa.amsl.com>; Mon, 20 Apr 2020 12:46:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.012
X-Spam-Level:
X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
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 vkyZi6EPluxB for <stir@ietfa.amsl.com>; Mon, 20 Apr 2020 12:46:55 -0700 (PDT)
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 D84D13A0E49 for <stir@ietf.org>; Mon, 20 Apr 2020 12:46:54 -0700 (PDT)
Received: by mail-qt1-x833.google.com with SMTP id x2so9684713qtr.0 for <stir@ietf.org>; Mon, 20 Apr 2020 12:46:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bUzXjztXXO+aQPod/QLqNtDg2sSilaVf/Wp+ibNalns=; b=jKwJgP+bkUdXMIvT94Vn6PtxruzWXB80J4gtidEr8BacH60FZh1fy0W6RJKHjprGhK jdT75sFniWiKixX9/H0DN7F2UmdQThRiHXubtHCQLVd8nH2ilcc7HaZfjL/xMBF0hyPO AqEDg/buV9UiOw48i50Aj3ySXwctoBQ3gu15k7Pmx/5dBM5o7y8gyvhckM7zlKiy+OBn d4haWmqToyX+ce08UHSOdPgL3P3bdhrf1/ab9ADeeEZKrb/rCab3XyIFfs0Apjn+vBVK 2/i/j05Il/ZGJc0cE98O+gVj6Z4sjTF7RDYQTI3OPfrPBMy/MI2i/mEzcz907a4FwU2T ByGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bUzXjztXXO+aQPod/QLqNtDg2sSilaVf/Wp+ibNalns=; b=cyZHp3unKpRV4WF5tytw89c76Ig2QMKgmrFZuEd0OHwqCg9ZPvB53YcFcPrdcrz9y4 6u2KF1BgTN8nPZ9CCJ2p1umSLSvtz5lWDUa/xL6fsF7jBP0ULR3I/VkX3bquwP0BpbFF GQxIDQtz5W1oDgRJ7xDXrt+MsVUUA7hrnkMJnik4wbY4r4BUJecY2cym52oZXa2j9sTI FepitZU9xsTDQFF1PEmqBTkElFUML9p6lqW+BEw1Wh2d/TQhhpykIqVxzI37XH0ld4Bc 1wTNhmxaZtLZYgTgigpns4YMB5xEq3WJkG5GCFawfxSjWcss+Ojp4CpNJNIYgjn0p1B3 eoKQ==
X-Gm-Message-State: AGi0PuZAZQY63K11oIbfEa9G3m/stvhggQYPVb6pYk3ad1lMw9hZOQ1W /S50prfZ45IzCL9nyhBXAUlbdYzsD5g=
X-Google-Smtp-Source: APiQypKI/Kqpr9V2lgHnAYXQ9beARiBCZpMY+KZH0ojY6lfpMMcH47b5FHL4ApgkAbaVYrn3F2RoXg==
X-Received: by 2002:ac8:678c:: with SMTP id b12mr18072989qtp.375.1587412013799; Mon, 20 Apr 2020 12:46:53 -0700 (PDT)
Received: from brians-mbp-2871.lan ([72.23.94.147]) by smtp.gmail.com with ESMTPSA id d26sm351332qkk.69.2020.04.20.12.46.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Apr 2020 12:46:53 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Brian Rosen <br@brianrosen.net>
In-Reply-To: <FC4D5270-23BB-4DB4-9770-92C452E44AA8@standardstrack.com>
Date: Mon, 20 Apr 2020 15:46:51 -0400
Cc: stir@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <60A0873B-CF40-4641-BDFC-8F068D276CA9@brianrosen.net>
References: <FC4D5270-23BB-4DB4-9770-92C452E44AA8@standardstrack.com>
To: Eric Burger <eburger@standardstrack.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/CxHXGFGMYja6vHaT3mzVjTaWZ8s>
Subject: Re: [stir] stir-certs-01: Expert Review?
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Apr 2020 19:47:07 -0000

Generally, I think we have to decide if a registry is actually needed/helpful and then decide what the management policy is.

I really do think that the folks running verification will be able to easily determine who is authoritative for a given prefix, and thus the registry has only marginal value.  There is some value, so the question is whether the grief of running it exceeds the value.

I think it’s pretty clear that if it vexes IANA, then it’s not worth it.

However, I’m fairly optimistic an expert, equipped with “when in doubt, allow it” guidance, can do what is needed, and then perhaps the utility is more than the grief, assuming we have experts who will agree to serve.

On the other, other hand, if we get into a tussle with ITU or anyone else over running a registry, then I’d drop the registry in a heart beat - not enough value to spend much time on.

Brian


> On Apr 20, 2020, at 1:24 PM, Eric Burger <eburger@standardstrack.com> wrote:
> 
> I heard two broad schools of thought on expert review. One theory is that since making determinations of who is authorized to update registrations is fraught with unsolvable Layer-9 issues, and since IANA is ill equipped to solve unsolvable Layer-9 issues, that IANA should take an extreme hands-off position and register anything that comes their way that meets the “identify the registrant” criteria specified in the draft. The other theory is that IANA can pass off requests to an expert that can triage registrations that would pass the “identify the registrant” criteria yet be obviously bogus. E.g., 10,000 registrations come in at once from the same place registering things that have a globally accepted, well-known authority, and it would be obvious the registrant does not have those authorities. However, we would “know it when we see it” and stay clear of the many jurisdictions where various governments, some UN recognized and others not, lay claim to a particular resource. In those instances, as laid out in the draft, we could have multiple registrations and not have IANA get into the Layer-9 (Layer-10, as now we’re talking governments of governments?) unsolvable problem.
> 
> Opinions? I did hear Alyssa say that if we lay out easy to follow, clear, uncontroversial steps, IANA can cleanly execute them. So, if you’ve got an algorithm, put it forth now.
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir