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

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Oct 2020 20:31:16 +0000

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.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 28 Oct 2020 09:28:12 +1100

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

Cheers,

> On 28 Oct 2020, at 7:31 am, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

--
Mark Nottingham   https://www.mnot.net/

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Oct 2020 22:59:34 +0000

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.

>> The latest ECH draft from Oct 16 says "ECH uses draft-05 of HPKE
>> for public key encryption."
>> 
>> 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 
>> [email-masked] https://www.ietf.org/mailman/listinfo/tls
> 
> -- Mark Nottingham   https://www.mnot.net/
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 27 Oct 2020 16:06:18 -0700

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

> 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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Oct 2020 23:20:22 +0000

Hiya,

On 27/10/2020 23:06, Eric Rescorla wrote:
> On Tue, Oct 27, 2020 at 4:00 PM Stephen Farrell
> <[email-masked]> wrote:
> 
>> 
>> Hiya,
>> 
>>> 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.

>>>> 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 [email-masked] https://www.ietf.org/mailman/listinfo/tls
>>>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 27 Oct 2020 16:27:46 -0700

On Tue, Oct 27, 2020 at 4:20 PM Stephen Farrell <[email-masked]>
wrote:

> That is not the IETF process (yet).

In fact, it *is* the IETF process, or rather one permitted IETF process,
since RFC 8874. If you think the chairs are not following the IETF process,
I would encourage you to contact the AD rather than arguing with me.

> the continually moving target that is my problem, not a

And what I'm saying here is that specifications go through stages where
they are stable enough to implement and other stages where they are in flux
and people should hold off on implementing, or at least trying to get
interop. Currently, we are in the latter period.

> versions. It's been two years since -02 was published.

Yes. We've been waiting for the spec to stabilize to the point where it was
worth cutting a new version. We are now working on that.

> I don't think

Yes, I appreciate that that's your opinion. It's not mine.

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 27 Oct 2020 23:29:59 +0000

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

Frictionless and increased speed can be its own drawback.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Oct 2020 23:33:02 +0000

On 27/10/2020 23:27, Eric Rescorla wrote:
> 
> In fact, it*is*  the IETF process, or rather one permitted IETF process,
> since RFC 8874. 

I don't believe the current case matches my recollection of
that, but I've not checked in detail. The lack of list
discussion certainly smells wrong to me.

> If you think the chairs are not following the IETF process,

I am not arguing with you. I am discussing an avoidable spec
bug, and how that might've happened, on the TLS WG list.

S.

---

From: Sean Turner <[email-masked]>
Date: Tue, 27 Oct 2020 20:32:33 -0400

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 <[email-masked]> wrote:
> 
> 
> Hiya,
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 28 Oct 2020 00:51:46 +0000

Hiya,

On 28/10/2020 00:32, Sean Turner 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?

My bet is that yes the WG will land on that bad answer.
I contend that it is highly unlikely useful summaries of
the barrage of githubbery can be regularly generated,
unless some of those messaging there decide to send mail
to the list as needed and allow time for responses from
those with other things to do that hour. (That's not a
thing within WG chairs' power to grant of course but it
would be nice.)

I'd be much happier about all that if someone would go
back and do that summarising for e.g. the last month's
traffic. I suspect that poor person would find the task
hard or maybe give up. I encourage anyone to take a look
and see how easy/hard they think that might be.

(Just to be clear: I don't think anyone here is trying to
be a bad actor - I figure it's more a case of understandably
not taking into account that there are more people involved
in the WG's work than are active in a particular way on
github. Still, there is "not taking into account" going
on, so not all's well.)

> We can certainly get a summary together - granted there have been
> interim meetings with published minutes [0][1].

Those are fine. No complaint from me there. (Albeit that
I had to miss some, but that was my problem.)

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

I think that would be good, yes. Just pick some iterations
and get agreement that enough people will implement and do
enough testing to be useful and take enough results into
account in the next iteration. Lotsa judgement needed but not
a showstopper. Way better than the current situation IMO so
yes please try direct us in that direction if you can.

Cheers,
S.

PS: I got another 8 mails wrt the esni draft since I sent
the earlier numbers. One of those had some human readable
content maybe, though it was context-free in that context;-)

> 
> 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/

---

From: Rob Sayre <[email-masked]>
Date: Fri, 30 Oct 2020 00:31:09 -0700

Hi,

I think the concern might center around previous standards.

thanks,
Rob

On Tue, Oct 27, 2020 at 5:34 PM Sean Turner <[email-masked]> wrote:

> discussion mode with email summaries sounds" presented in Chris' email from
> just last week can we let that settle?
>
> 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]