Re: [Trans] Martin Duke's No Objection on draft-ietf-trans-rfc6962-bis-39: (with COMMENT)

Paul Wouters <paul@nohats.ca> Fri, 30 July 2021 03:38 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FEFC3A18D5 for <trans@ietfa.amsl.com>; Thu, 29 Jul 2021 20:38:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 CTP5WRdda_ou for <trans@ietfa.amsl.com>; Thu, 29 Jul 2021 20:38:25 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AA993A18D3 for <trans@ietf.org>; Thu, 29 Jul 2021 20:38:25 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4GbY5V3qtYz2pC; Fri, 30 Jul 2021 05:38:22 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1627616302; bh=DCr2wLFLE4tiTZaDLyQ/LXJEfswPMjBIEuGi7Cy+uBc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=VGkW3UXfIpC4FCvgmk62XdqwAND3m5aZ/XDJQo5HUs5vopWBpuEAFdsWocgxOFHWK t5K6MG7mM4+0+zDFXXL5l/H8k9AoE32H8TB3LYAh8N+PnZijbtx7h1p5itiWpSOMPH uAdGF2y5UUioDEWZScSxtjjV4rGmP4MEqFBi2z8w=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id JY5S7GRjyqWV; Fri, 30 Jul 2021 05:38:21 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 30 Jul 2021 05:38:21 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id EF0FBD3971; Thu, 29 Jul 2021 23:38:19 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EB7C9D3970; Thu, 29 Jul 2021 23:38:19 -0400 (EDT)
Date: Thu, 29 Jul 2021 23:38:19 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Ryan Sleevi <ryan-ietf@sleevi.com>
cc: Martin Duke <martin.h.duke@gmail.com>, "Salz, Rich" <rsalz@akamai.com>, "trans@ietf.org" <trans@ietf.org>
In-Reply-To: <CAErg=HF+15b_XsTSEO2z1nXctTp1uSLPYqrqVt1M_gCf+KB7vw@mail.gmail.com>
Message-ID: <e9f6bf7-4c6e-9a57-37d4-f072ffa2c76b@nohats.ca>
References: <97FC6C54-5642-4E0B-B6CB-F3231C58D7AF@akamai.com> <CAErg=HG3-TT++aU6mRQ7uyp_d0gLbUWU-3qVBzZ7fdAzHthtPA@mail.gmail.com> <C6F3ECDF-D16A-4BFC-BBF5-14F6577D26D2@akamai.com> <CAErg=HFo3AAV+=-C5wjvmcANF-PFvp+qzSupBJ-60VXsC-otcA@mail.gmail.com> <CAM4esxR_U6DNVnsjrY5B4v1zZRNQMjcz-fiK1iF+dL+3zrw0Rg@mail.gmail.com> <CAErg=HF+15b_XsTSEO2z1nXctTp1uSLPYqrqVt1M_gCf+KB7vw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/1ncFOeK8CJRo5ORF2j66HdN-lag>
Subject: Re: [Trans] Martin Duke's No Objection on draft-ietf-trans-rfc6962-bis-39: (with COMMENT)
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Jul 2021 03:38:30 -0000

On Thu, 29 Jul 2021, Ryan Sleevi wrote:

> On Thu, Jul 29, 2021 at 5:44 PM Martin Duke <martin.h.duke@gmail.com> wrote:
>       So returning to my previous point, it seems rather heavyweight to update the IANA registry
>       every time this happens, and it would arguably be efficient to assign a given operator a range
>       so that these need not be deconflicted in perpetuity?
> 
> 
> Isn’t that just reinventing PENs under a shorter arc, at that point?
> 
> In practice, what we see is log operators creating multiple logs at once (e.g. for six annual shards), and
> then updating annually or semi-annually to add new temporal shards.
> 
> So I’m not sure which part of the heavy handed is being optimized for, mostly due to ignorance on my part:
> is the concern this is process intensive on the IANA part, or the log operator part? If the log operator
> sees this as intensive, then they’ve got the PEN route as a readily deployable alternative (at the cost of
> larger messages). If it’s overhead on the IANA part, then that would seem to argue scrapping the whole
> “too clever and a half” idea of “use a short OID because, for historic reasons, IANA has some”, and just
> pay the 4-10byte tax for using PENs.

Martin,

Thanks for your thorough review and voluntary Merkle Tree diving.

It seems the above answers your question. Log operators have a choice on
how to get their unique log ID(s). They can get a larger assignment and
use numbers within their assignment trivially, so there is no problem
of something being too "heave handed" I believe. They don't have to use
IANA if they already have their own OID space, and if they don't they
can easilly get a suitably large assignment by a one-time action.

I think we are really late into the game to go and change anything
related to this now, especially as we have seen years of no issues with
RFC 6962 and log IDs. As you stated your comment was "non-blocking",
we will consider this comment resolved.

Thanks,

Paul