Re: [TLS] ECH & HPKE versions as an example of too much githubbery
Sean Turner <sean@sn3rd.com> Wed, 28 October 2020 00:32 UTC
Return-Path: <sean@sn3rd.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289513A0B1A for <tls@ietfa.amsl.com>; Tue, 27 Oct 2020 17:32:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdBG6cMzyyXQ for <tls@ietfa.amsl.com>; Tue, 27 Oct 2020 17:32:42 -0700 (PDT)
Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DACB3A0AF9 for <tls@ietf.org>; Tue, 27 Oct 2020 17:32:35 -0700 (PDT)
Received: by mail-qv1-xf29.google.com with SMTP id ev17so1636062qvb.3 for <tls@ietf.org>; Tue, 27 Oct 2020 17:32:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AQxjGO0+bfN/U/LIuUFZsOOmmYoFyH2N0NgYXxH4eLE=; b=ji96JGs3nrHYtjkAara0U6w+kJHrUV18epTWUkXURs9z6yuIt4Nm/Gd8Xh0Bhil2Qr Wl0p2LJa1wacsrl89jgiXvZKHixHX3wOLhMyKtcH2F3sHI6dRnG5uOXPWoGGgwAh3H/K aAUOsw/cjDl7R92Ndw07WplxQq7hf9vxmcwgA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AQxjGO0+bfN/U/LIuUFZsOOmmYoFyH2N0NgYXxH4eLE=; b=bX+9TbrAEidqqdSa8ZOUzBJL3ACAJSNBS79YkiUJVuf2obUKWjnInyYsE8fEN8xy9l OddN/B5qQaTQV92qqmc16quLUvdUyU6S5IpCOdUCKch4l9kTsRAB994TTwQkoHH0/22X n5y+R9xPokVH3QJF2dfuyVL1t6yTJWLFbcWtZ0/BS3CEUl9JcsQe2azeJoYI9zqLDRWT ib90S4cCZ9c8pMSOjOv0ix8UXdWSVOpX2tyxIDY3bkiXSW1HeTmnGNDi4K62Byr5NFw8 4ngVJParO1IzOQEJl6eJTSjV4Qey2B1zYF96AZcxz2pDdo9DZ1FUAB/n/do4keT864YT UAFA==
X-Gm-Message-State: AOAM532W5gtOTRPdFJjxQdW/BPZt5MDOIDhemjcQecnSK+P4czNHUtVj I62w7TVpgt1UamfZw83A06aBoPdgLaoW+g==
X-Google-Smtp-Source: ABdhPJzKZp7nAwoiuAvs2674E/ZWU1hkfjrtwA3GuWqpgPds5Soq8EoFtmDjrVVKvpOJaRyiMDXQSQ==
X-Received: by 2002:a0c:e308:: with SMTP id s8mr5456472qvl.10.1603845154477; Tue, 27 Oct 2020 17:32:34 -0700 (PDT)
Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id t70sm2017499qke.119.2020.10.27.17.32.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Oct 2020 17:32:33 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Sean Turner <sean@sn3rd.com>
In-Reply-To: <06eebcd3-1532-1df4-cd4b-c92110bbf010@cs.tcd.ie>
Date: Tue, 27 Oct 2020 20:32:33 -0400
Cc: TLS List <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7E38C991-654D-4F79-AD26-D3C9B33FF8B8@sn3rd.com>
References: <06eebcd3-1532-1df4-cd4b-c92110bbf010@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/kh3GXJYZruBD88xn_JH5b9_CGGM>
Subject: Re: [TLS] ECH & HPKE versions as an example of too much githubbery
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Oct 2020 00:32:50 -0000
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] ECH & HPKE versions as an example of too mu… Stephen Farrell
- Re: [TLS] ECH & HPKE versions as an example of to… Mark Nottingham
- Re: [TLS] ECH & HPKE versions as an example of to… Stephen Farrell
- Re: [TLS] ECH & HPKE versions as an example of to… Eric Rescorla
- Re: [TLS] ECH & HPKE versions as an example of to… Stephen Farrell
- Re: [TLS] ECH & HPKE versions as an example of to… Eric Rescorla
- Re: [TLS] ECH & HPKE versions as an example of to… Salz, Rich
- Re: [TLS] ECH & HPKE versions as an example of to… Stephen Farrell
- Re: [TLS] ECH & HPKE versions as an example of to… Sean Turner
- Re: [TLS] ECH & HPKE versions as an example of to… Stephen Farrell
- Re: [TLS] ECH & HPKE versions as an example of to… Rob Sayre