IETF Logo Mail Archive

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

Alexey Melnikov <alexey.melnikov@isode.com> Thu, 03 March 2022 15:34 UTC

Return-Path: <alexey.melnikov@isode.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 688F73A0D1C; Thu, 3 Mar 2022 07:34:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Level:
X-Spam-Status: No, score=-2.11 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=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 (1024-bit key) header.d=isode.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 KOF3iD517x-z; Thu, 3 Mar 2022 07:34:38 -0800 (PST)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id D893B3A0D18; Thu, 3 Mar 2022 07:34:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1646321676; d=isode.com; s=june2016; i=@isode.com; bh=VSPj/MfWCdCuT4ZuTqqovIyTYeSq1EbR5sfrT/ghZPI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=oLLHqLjSIK8ykdRY80wj+qyP49z7Xh+gwADjxYkNQvF1Zs6L9Od3hMtXALdziOKZfujzyl MIPKWPxvBSEXyh0I827JhUd6R3XTNYgnXapS0MVxzmeh3NIFci0JbrxzvR3G7p2wyNh/fd CFFOIDaCkVdoumo8ifPemUKw0daiFTQ=;
Received: from [172.27.254.209] (connect.isode.net [172.20.0.43]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <YiDgCwBN6aQB@statler.isode.com>; Thu, 3 Mar 2022 15:34:36 +0000
Message-ID: <572771c8-31df-d121-508f-af27506216b5@isode.com>
Date: Thu, 03 Mar 2022 15:34:35 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0
To: Sam Whited <sam@samwhited.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
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>
From: Alexey Melnikov <alexey.melnikov@isode.com>
In-Reply-To: <46de67e2-de0c-4ea5-9fca-c0102a7828d4@www.fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/apDtsAjLTAYWw3l-076iwBA_tFU>
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: Thu, 03 Mar 2022 15:34:43 -0000

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

v2.23.0 | Report a Bug | By Email