Hiya,
On 27/10/2020 23:06, Eric Rescorla wrote:
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'srelevant (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 withopen 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, laterversions. 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_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tlsCheers,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 trivialreasons).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/
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
