Re: [TLS] ECH & HPKE versions as an example of too much githubbery

Stephen Farrell <> Tue, 27 October 2020 22:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 848373A03C9 for <>; Tue, 27 Oct 2020 15:59:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.246
X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jtIBmLG7fskn for <>; Tue, 27 Oct 2020 15:59:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 76FC23A03AA for <>; Tue, 27 Oct 2020 15:59:40 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 54222BE4D; Tue, 27 Oct 2020 22:59:39 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g0-J6kFC-fDm; Tue, 27 Oct 2020 22:59:35 +0000 (GMT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 9293EBE4C; Tue, 27 Oct 2020 22:59:35 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1603839575; bh=VGgzCGM1hFR/BjM1F5PWvw3pI8sTjsiGOujA536myms=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=awN5KaxGOXF2bQ8gwF9RGdmba/yV3R3fLpQ7rVttwGh/NZQcb8KaIMX5WKKZRgvXC J6/peslYDRxYGgg1g0gtcZvii70Lfas0wMQwRtJIk2ZIJvz5SYdPVFxtwgYNH/bSU+ lK+VphxbdpjWCjREVr1C73PstKJINIvyMKwCSCpU=
To: Mark Nottingham <>
Cc: "" <>
References: <> <>
From: Stephen Farrell <>
Message-ID: <>
Date: Tue, 27 Oct 2020 22:59:34 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="sXFkAEjGspmt0bFLp8dBV4wlxKquLYhdI"
Archived-At: <>
Subject: Re: [TLS] ECH & HPKE versions as an example of too much githubbery
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Oct 2020 22:59:44 -0000


On 27/10/2020 22:28, Mark Nottingham wrote:
> Stephen,
> I don't think what you're complaining about can be attributed to
> GitHub. Tools are just tools, how they're used is what's relevant
> (i.e., this could just as easily happen over e-mail).

Sorta. I doubt the volume of traffic would've happened via
email for non-contentious, not-trivial-but-not-earthshaking

I "watch" the repos for these drafts, and in just the last
month, I've seen 401 esni emails, 127 hpke emails and 157
dns-alt-svc emails. That's too many, is encouraged by the
tools IMO and has to mean a lot not being discussed on the
list that ought be.

So I do think the tooling is really part of this. But yes,
had someone taken on the mega-task of bringing the useful
bits of those 683 mails per month to the list, it may have
been that the mismatch would've been avoided.


PS: I neglected to say in my earlier mail that hpke-05 has
an interop bug that we discovered when I was verifying the
test vectors a few months ago. It's not the right basis to
pick if we want esni-08 to be used for interop really. But
more to the point, nor is a moving target.

> Cheers,
>> On 28 Oct 2020, at 7:31 am, Stephen Farrell
>> <> wrote:
>> Hiya,
>> The latest ECH draft from Oct 16 says "ECH uses draft-05 of HPKE
>> for public key encryption."
>> The latest HPKE draft (-06) from Oct 23 has a few minor 
>> incompatible changes (for good but relatively trivial reasons).
>> So for interop ECH apparently requires use of an outdated I-D,
>> despite the one week difference in publishing and a common
>> co-author.
>> It seems a bit mad that all that githubbery results in such a lack
>> of co-ordination in two closely related specs.
>> Anyway, I can manage to handle both HPKE-05 and HPKE-06 but this
>> seems like yet another case where there is too much githubbery
>> going on with the result that two closely linked drafts with a
>> common co-author end up out of whack despite being issued within a
>> week of one another.
>> That and the velocity of discussion and changes on github are a
>> major disincentive (for me) for implementing ECH. I simply do not
>> have the cycles to keep up with it as it has been happening these
>> last months. If that were the goal of the authors and those
>> endlessly commenting on github (and I do not believe it is), then
>> they would be close to reaching that goal.
>> Can we not please freeze this stuff for at least long enough to get
>> implementations done and somewhat tested?
>> Frankly, I expect my plea here to be more or less ignored just as
>> my previous entreaties were. I decided to send it anyway on the
>> basis that the perhaps what seems like an obvious failure of the
>> current approach (ECH can't interop unless you use an outdated I-D
>> for HPKE) might show that all this apparent high velocity
>> discussion on github is not as effetcive as claimed (in at least
>> this case).
>> Thanks, Stephen.
>> _______________________________________________ TLS mailing list 
> -- Mark Nottingham