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

[Stephen Farrell <[e-mail]>]

Hiya,

On 27/10/2020 23:06, Eric Rescorla wrote:
> On Tue, Oct 27, 2020 at 4:00 PM Stephen Farrell
> <[e-mail]> wrote:
> 
>> 
>> 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.
>> 
> 
> This seems to me like it makes the argument for the tooling. Namely
> that it enables low friction participation on details.

It enables that for *some* whose workflow that matches.
That is not the IETF process (yet). (And "low friction"
is just as much verbiage as it would be had I described
the situation using a term like "verbal diarrhoea":-)

>> 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.
>> 
> 
> I think this is the key point. ECH is under active development with
> open issues. 

No. The key point is esni-08 unnecessarily and uselessly
depends on -05 which has a known bug. That should have
been avoided. That it was not is a fail. And I think one
party due to the preferred tooling of the set of people
who are extremely active on github wrt these drafts. (It's
not an end of the world thing, but denying it seems a
bit odd to me.)

> Trying to do interop now is at your own risk.

That's a non-answer. I didn't claim any loss so risk isn't
relevant. It's being denied the opportunity to implement by
the continually moving target that is my problem, not a
risk nor financial loss.

Mozilla implemented -02, but not, so far as I recall, later
versions. It's been two years since -02 was published. I don't think 
we've come that far at all since (there are
modest improvements but not two years worth) and I do
think the tooling is responsible for some of those delays,
certainly this year.

ISTM that a spec that always changes too fast to be
implemented by many will often be inferior to one that is
dealt with in a manner that has more eyeballs looking at
it in considered detail. So by all means use github, but
at least make sure the text has enough stability to be
coded up.

Cheers,
S.

> 
> -Ekr
> 
> 
>> 
>>> 
>>> 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/
>>> 
>> _______________________________________________ TLS mailing list 
>> [e-mail] https://www.ietf.org/mailman/listinfo/tls
>> 
>