IETF Logo Mail Archive

Re: [kitten] Status update on draft-ietf-kitten-tls-channel-bindings-for-tls13-15

Alexey Melnikov <alexey.melnikov@isode.com> Tue, 26 April 2022 16:35 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 3F838C1D18F5 for <kitten@ietfa.amsl.com>; Tue, 26 Apr 2022 09:35:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.955
X-Spam-Level:
X-Spam-Status: No, score=-3.955 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=-1.857, RCVD_IN_DNSWL_BLOCKED=0.001, 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=isode.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EP6hQ0qfemTt for <kitten@ietfa.amsl.com>; Tue, 26 Apr 2022 09:35:27 -0700 (PDT)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3B6C1D18F9 for <kitten@ietf.org>; Tue, 26 Apr 2022 09:35:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1650990925; d=isode.com; s=june2016; i=@isode.com; bh=DwNGFkznrI/L0veYMG1/UqrOwTbKJ6RmVqH0g8MW64g=; 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=MPhi0h/p1FaR5nGLcfz/Y6SE/QAvJsHYYF6O6dZPO0fGuNxTH3OKFMxKwTX+l5PKkDOgVn GhTO57HTw0Tvs5RKUc0V3Rp9UY/7NAjHSab64jL0G305coEBXPt40TzQOM2gpluRJeG4K2 kEuoxJest9n5ZRWmHPHlMoOgJpReZHU=;
Received: from [172.27.250.80] (connect.isode.net [172.20.0.43]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <YmgfSwBXZacQ@waldorf.isode.com>; Tue, 26 Apr 2022 17:35:25 +0100
Message-ID: <f1e8c499-49c7-c41c-c641-a51c0f2010e2@isode.com>
Date: Tue, 26 Apr 2022 17:35:23 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1
From: Alexey Melnikov <alexey.melnikov@isode.com>
To: Paul Wouters <paul.wouters@aiven.io>
Cc: kitten@ietf.org, Sam Whited <sam@samwhited.com>, Benjamin Kaduk <kaduk@mit.edu>
References: <9365ee48-162a-4b1f-20b5-4f3853e43201@isode.com> <52B1911E-5D62-49F1-91AC-D4B9476A9CA2@aiven.io>
In-Reply-To: <52B1911E-5D62-49F1-91AC-D4B9476A9CA2@aiven.io>
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/CfXZH1Bwvdvo_1ker_w67RZgFTQ>
Subject: Re: [kitten] Status update on draft-ietf-kitten-tls-channel-bindings-for-tls13-15
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.34
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: Tue, 26 Apr 2022 16:35:31 -0000

On 25/04/2022 16:34, Paul Wouters wrote:
> i am confused how an Updates: call is depending on consensus. either it updates something said in that document or it doesn't.
>
> in theory this cannot be a subjective call?

The shortish version of the argument is as follows:

1) The desire to include "Updates: RFC 8446" header in 
draft-ietf-kitten-tls-channel-bindings-for-tls13-15 is to make the new 
TLS 1.3 channel binding "tls-exporter" be discoverable by SASL/GSSAPI 
implementors.

2) "Updates" header is typically used to make implementors of the 
updated RFC be aware of important fixes (in particular changes in 
behavior) or mandatory extensions. In the past it was sometimes used by 
optional extensions, but this practice is not generally supported now.

3) TLS WG now uses higher bar for other documents to include "Updates: 
RFC 8446". Optional extensions (such as 
draft-ietf-kitten-tls-channel-bindings-for-tls13-15) don't meet this bar.

4) draft-ietf-kitten-tls-channel-bindings-for-tls13-15 doesn't define a 
mandatory-to-implement extension for TLS 1.3 implementations. Because of 
2) and 3) it must not include "Updates: RFC 8446". Additionally, 
implementors can discover this extension through a) IANA registry of 
channel bindings or b) through Updates: 5801 (SCRAM) or Updates: 5929 
(Channel Bindings for TLS). RFC 5801 is the most likely reason why 
people would implement any TLS channel binding in the first place.

Best Regards,

Alexey

> Sent from my iPhone
>> On Apr 25, 2022, at 16:11, Alexey Melnikov<alexey.melnikov@isode.com>  wrote:
>>
>> Quick status update on this.
>>
>> draft-ietf-kitten-tls-channel-bindings-for-tls13-15 includes "Updates: RFC 8446".
>>
>> After reviewing various mailing list discussions, I confirm that inclusion of this header in the draft doesn't represent IETF consensus. So the header needs to be taken out. Sam, I know that this is not what you personally prefer, but are you willing to make the change?
>>
>> The document also needs to have a "Yes" ballot from one of current IESG members. So I separately asked Paul Wouters (our new Sec AD) to do the document review.
>>
>> Best Regards,
>>
>> Alexey, as a KITTEN chair
>>
>>

v2.23.0 | Report a Bug | By Email