[kitten] Roman Danyliw's Discuss on draft-ietf-kitten-tls-channel-bindings-for-tls13-14: (with DISCUSS and COMMENT)
Roman Danyliw via Datatracker <noreply@ietf.org> Mon, 28 February 2022 21:43 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: kitten@ietf.org
Delivered-To: kitten@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3053A157F; Mon, 28 Feb 2022 13:43:53 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-kitten-tls-channel-bindings-for-tls13@ietf.org, kitten-chairs@ietf.org, kitten@ietf.org, alexey.melnikov@isode.com, alexey.melnikov@isode.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <164608463345.19675.8608334448565188645@ietfa.amsl.com>
Date: Mon, 28 Feb 2022 13:43:53 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/eSSF7uyA9tATO0BMY_9c1vtz0iA>
Subject: [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
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: Mon, 28 Feb 2022 21:43:54 -0000
Roman Danyliw has entered the following ballot position for draft-ietf-kitten-tls-channel-bindings-for-tls13-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-bindings-for-tls13/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- ** On the issue of what behavior is MTI, Section 5.2 of Section RFC5801 and Section of RFC5802 say: (a) 'tls-unique' is the default channel binding type for any application that doesn't specify one. (b) Servers MUST implement the "tls-unique" [RFC5929] channel binding type, if they implement any channel binding. Section 3 of this document says: (c) As "tls-unique" is not defined for TLS 1.3 (and greater), this document updates [RFC5801], [RFC5802], and [RFC7677] to use "tls- exporter" as the default channel binding over TLS 1.3 (and greater). Note that this document does not change the default channel binding for SCRAM mechanisms over TLS 1.2 [RFC5246], which is still "tls- unique". No problem with the guidance in (c). Without specific citations being made, I’m inferring that (c) is intended to “update”/clarify (a) in a TLS 1.3 context. To the issue of MTI, (c) is silent on the guidance in (b). Since “tls-unique” is not defined for TLS 1.3, how would an implementer comply in the case of a server that is TLS 1.3 only? Should this document make a statement to the effect of “tls-exporter” is MTI for any servers implementing TLS 1.3? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this document to ensure TLS 1.3 support in SCRAM and GSS-API. Per how this document is updating other documents: ** The “updates” header doesn’t note RFC8446 but the abstract and Section 1 suggest that this document does update it. Per Martin Duke’s DISCUSS point (which I support), please clarify. ** Per Section 3 … this document updates [RFC5801], [RFC5802], and [RFC7677] to use "tls- exporter" as the default channel binding over TLS 1.3 (and greater). In what way is RFC7677 being updated? If RFC5802 is already updated to required tls-exporter for TLS 1.3 what additional guidance is needed for RFC7677?
- [kitten] Roman Danyliw's Discuss on draft-ietf-ki… Roman Danyliw via Datatracker
- Re: [kitten] Roman Danyliw's Discuss on draft-iet… Sam Whited
- Re: [kitten] Roman Danyliw's Discuss on draft-iet… Benjamin Kaduk
- Re: [kitten] Roman Danyliw's Discuss on draft-iet… Sam Whited
- Re: [kitten] Roman Danyliw's Discuss on draft-iet… Alexey Melnikov
- Re: [kitten] Roman Danyliw's Discuss on draft-iet… Sam Whited