Re: [kitten] Roman Danyliw's Discuss on draft-ietf-kitten-tls-channel-bindings-for-tls13-14: (with DISCUSS and COMMENT)

Sam Whited <sam@samwhited.com> Fri, 04 March 2022 12:31 UTC

Return-Path: <sam@samwhited.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62013A137E; Fri, 4 Mar 2022 04:31:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=samwhited.com header.b=hpfFll9m; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cMjz/tu2
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 t7UsiO41VoWR; Fri, 4 Mar 2022 04:31:40 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3BD23A137C; Fri, 4 Mar 2022 04:31:40 -0800 (PST)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id E945B5C0085; Fri, 4 Mar 2022 07:31:39 -0500 (EST)
Received: from imap42 ([10.202.2.92]) by compute5.internal (MEProxy); Fri, 04 Mar 2022 07:31:39 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; h=cc:cc:content-transfer-encoding:content-type:date:date:from :from:in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; bh=BsZH+ZDl2sYzN1 r89F+yr5WrfXImVXZkFbqmlAedlyI=; b=hpfFll9mcSKx0LMk14FdxqqH5VQrns P9kxBauHVERGB2l3PBZGLU3aDfovM3rn5OBoirztNFoH2JTR0m64pyZyNh1L5kMb B5FaCsBf8uA3hn+RMzNj6IwuHiEFj959CWnLQ8IhIwX74Flyb245gDt6sud+vX+r 7X3Ugu3Cws7TUex4gOXS19Nwc0tSUxuLOtsJnFb5M+ClTKQZNMBl+W5KsWAcWEl0 qZollDc57L1Klyu1n5uUVHCWUOW6IaI6vJ16GP0cufU7rG1j3J7IHGTV6Ry7aKlR 3sO0+hVt6CwdbuqnPXJqlFa3Ty1+IbNPrLfSPfrlAKsAO7l6ZeOk2hGg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=BsZH+ZDl2sYzN1r89F+yr5WrfXImVXZkFbqmlAedl yI=; b=cMjz/tu21bsxKmazREIFxLe8L8CYunt2lm69CMFkfPSgsl4VcKAM2WASI yjINvV5QanwxmhXEsePpY2qmOO1zOHKA3zNHI5WyiG+fIkxXt6zP1cPHaqnhI1AO rr95zXIxRuj6gDQ8kRhh/09jn850V0Q3MeIcIjd+VZtoYNfDwkErmcWRmlQh3S20 +lp7YLEb62Fh4VvZiVNbbv2n3UDu2dIJeHWiWzYxQJ1/VSjkEROAtD40rRJbRwap a3hUxXmgqRfm+vAsuJj1S6jgrRsTGl5W+/8a+96iUIPpUpQ/aKfxJ1khBzwORMm5 ohyT0RnnElWq2+b9dT15z0Vx9fmGw==
X-ME-Sender: <xms:qwYiYhAiiTy04Xdp7ckx9iOLc6AtjDpGfJj-nfrAvwg6ZJRtjJFdPQ> <xme:qwYiYvj8s4mq1xLcOTc4L7zphPueX2iqTRCOaG7opbZ-0gY2omUPZEPX4Mqe8HNHx _fEoRyeVX5smshDQg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddruddtkedggeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfufgr mhcuhghhihhtvggufdcuoehsrghmsehsrghmfihhihhtvggurdgtohhmqeenucggtffrrg htthgvrhhnpedvffeuvdduhfefvdeiheeukeffhfekjeevgffggedtlefhhffhieevkedu vefhjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hsrghmsehsrghmfihhihhtvggurdgtohhm
X-ME-Proxy: <xmx:qwYiYsnd6ZILx8NNpShAA3DD2aAsQX16yvMW_VIvDiLEzpJDCSIsLg> <xmx:qwYiYrxwBbNcQUVeOikhd0GALO_4T8-9ORmZ1MyMx0hif8YrGx8peQ> <xmx:qwYiYmSsLU5xLUT3flrbatoKrbKqao6k_s-XnWn-JYrj-MZiHckDKg> <xmx:qwYiYsMy8XbrPVI53hwAZ0FQkKuVZiAokJD3_Pb5CBu60YnTwnyXcg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4AF5D2180078; Fri, 4 Mar 2022 07:31:39 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-4778-g14fba9972e-fm-20220217.001-g14fba997
Mime-Version: 1.0
Message-Id: <c36fc1e0-e29e-46c4-a96f-02b8199b1815@www.fastmail.com>
In-Reply-To: <572771c8-31df-d121-508f-af27506216b5@isode.com>
References: <164608463345.19675.8608334448565188645@ietfa.amsl.com> <ebda7696-3163-4ed8-a309-9123a6eaac1f@www.fastmail.com> <20220228230350.GE12881@kduck.mit.edu> <46de67e2-de0c-4ea5-9fca-c0102a7828d4@www.fastmail.com> <572771c8-31df-d121-508f-af27506216b5@isode.com>
Date: Fri, 04 Mar 2022 07:31:17 -0500
From: Sam Whited <sam@samwhited.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>, Benjamin Kaduk <kaduk@mit.edu>
Cc: Roman Danyliw <rdd@cert.org>, The IESG <iesg@ietf.org>, KITTEN Working Group <kitten@ietf.org>, draft-ietf-kitten-tls-channel-bindings-for-tls13@ietf.org, kitten-chairs@ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/5atihZC-CeO8YuVM3Cbzgg7KsmE>
Subject: Re: [kitten] Roman Danyliw's Discuss on draft-ietf-kitten-tls-channel-bindings-for-tls13-14: (with DISCUSS and COMMENT)
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2022 12:31:46 -0000

I don't believe most people will look further than the document they're
implementing; it would be nice if that weren't the case, but I don't
think it is. In my experience most people don't look further than
glancing through a few sections and looking at examples (of course, TLS
is complicated enough that you likely can't come up with a working
implementation doing this, but never the less the point stands). The
point is to make it as easy as possible to find when you're implementing
related technologies; I don't think the IANA website does that (Though
it should be said that this is entirely speculation, of course).

—Sam

On Thu, Mar 3, 2022, at 10:34, Alexey Melnikov wrote:
> Hi Sam/Ben,
>
> On 01/03/2022 00:06, Sam Whited wrote:
>> On Mon, Feb 28, 2022, at 18:04, Benjamin Kaduk wrote:
>>> My willingness to advance this document for IESG consideration was
>>> predicated on this document *not* having an "Updates:" relationship
>>> with RFC 8446, based on my assessment of IETF consensus.  I
>>> understand that you feel strongly that the "Updates:" relationship
>>> should be present, but we can only add that relationship with IETF
>>> consensus, and I do not believe that such consensus is present.
>>> There is an appeals process (§6.5 of RFC 2026) that applies if you
>>> think my assessment of IETF consensus is flawed, and I'd be happy to
>>> hear about any factors that I may have missed in making that
>>> assessment.
>> I do not believe their was consensus either way; one or two people
>> voiced an opinion that it should not update it, and I don't think
>> anyone else joined the discussion. The usefulness of this document is
>> extremely diminished if new implementations of TLS 1.3 can't find it
>> and I absolutely believe the text updates the sentence saying that no
>> channel bindings are defined.
>
> If I am an implementor, I would find it through IANA website, so
> personally I don't see this as a problem.
>
> Best Regards, Alexey

-- 
Sam Whited