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

Stephen Farrell <> Wed, 28 October 2020 00:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB6733A0ABE for <>; Tue, 27 Oct 2020 17:51:54 -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 0d4PChqD86v8 for <>; Tue, 27 Oct 2020 17:51:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A0F7E3A0AC5 for <>; Tue, 27 Oct 2020 17:51:52 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C915CBE56; Wed, 28 Oct 2020 00:51:50 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bz6RLdM8AHtq; Wed, 28 Oct 2020 00:51:48 +0000 (GMT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 58811BE50; Wed, 28 Oct 2020 00:51:48 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1603846308; bh=caHYG/kssg5u84pCo7QbMP5fKZ9IwOniIKtvpWb6rE0=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=NzQTSwL/ypDv7enPyarSCavxHKMx3YEqucIgsHmQoaTQ0Xmo67kvscoa/XyQF16+t v5UrG9WF049MyGij0dEU8V65Ff6nnijguSK46uj2VSYjvq9C9kw9g2+lE4CdrlR/PG UWIE48DtDqsEun4S++CCT+BIFkoBi+/+q/J4ihwY=
To: Sean Turner <>
Cc: TLS List <>
References: <> <>
From: Stephen Farrell <>
Message-ID: <>
Date: Wed, 28 Oct 2020 00:51:46 +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="lvpgyTh5f8yne7ZHutXLrEiW1ig1PAHLZ"
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: Wed, 28 Oct 2020 00:51:55 -0000


On 28/10/2020 00:32, Sean Turner wrote:
> Stephen,
> Given that there appears to be emerging consensus around the "issue
> discussion mode with email summaries sounds" presented in Chris'
> email from just last week can we let that settle?

My bet is that yes the WG will land on that bad answer.
I contend that it is highly unlikely useful summaries of
the barrage of githubbery can be regularly generated,
unless some of those messaging there decide to send mail
to the list as needed and allow time for responses from
those with other things to do that hour. (That's not a
thing within WG chairs' power to grant of course but it
would be nice.)

I'd be much happier about all that if someone would go
back and do that summarising for e.g. the last month's
traffic. I suspect that poor person would find the task
hard or maybe give up. I encourage anyone to take a look
and see how easy/hard they think that might be.

(Just to be clear: I don't think anyone here is trying to
be a bad actor - I figure it's more a case of understandably
not taking into account that there are more people involved
in the WG's work than are active in a particular way on
github. Still, there is "not taking into account" going
on, so not all's well.)

> We can certainly get a summary together - granted there have been
> interim meetings with published minutes [0][1].

Those are fine. No complaint from me there. (Albeit that
I had to miss some, but that was my problem.)

> We could also adopt an approach similar to the QUIC WG where they
> would declare a particular draft version one that they would run
> interop on. We would need to decide on the process of declaring what
> that version was as well as moving to the next version.

I think that would be good, yes. Just pick some iterations
and get agreement that enough people will implement and do
enough testing to be useful and take enough results into
account in the next iteration. Lotsa judgement needed but not
a showstopper. Way better than the current situation IMO so
yes please try direct us in that direction if you can.


PS: I got another 8 mails wrt the esni draft since I sent
the earlier numbers. One of those had some human readable
content maybe, though it was context-free in that context;-)

> spt
> [0]
>> On Oct 27, 2020, at 16:31, 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