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

Hi,

I think the concern might center around previous standards.

thanks,
Rob

On Tue, Oct 27, 2020 at 5:34 PM Sean Turner <sean@sn3rd.com> 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?
>
> We can certainly get a summary together - granted there have been interim
> meetings with published minutes [0][1].
>
> 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.
>
> spt
>
> [0]
> https://datatracker.ietf.org/doc/minutes-interim-2020-tls-02-202009031000/
> [1]
> https://datatracker.ietf.org/doc/minutes-interim-2020-tls-03-202009210800/
>
> > On Oct 27, 2020, at 16:31, Stephen Farrell <stephen.farrell@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
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>