On Tue, Oct 27, 2020 at 4:00 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> 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. > 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. Trying to do interop now is at your own risk. -Ekr > > > > > Cheers, > > > > > >> On 28 Oct 2020, at 7:31 am, Stephen Farrell > >> <stephen.farr...@cs.tcd.ie> 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 > >> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls > > > > -- Mark Nottingham https://www.mnot.net/ > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
