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

[Stephen Farrell <[e-mail]>]

Hiya,

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
topics.

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.

Cheers,
S.

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
>> <[e-mail]> 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 
>> [e-mail] https://www.ietf.org/mailman/listinfo/tls
> 
> -- Mark Nottingham   https://www.mnot.net/
>