[art] draft-ietf-dance-client-auth-09 ietf last call Artart review

Arnt Gulbrandsen via Datatracker <noreply@ietf.org> Mon, 12 January 2026 16:39 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Arnt Gulbrandsen via Datatracker <noreply@ietf.org>
To: art@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <176823599306.764059.7845639436342695371@dt-datatracker-5656579b89-r5kdq>
Date: Mon, 12 Jan 2026 08:39:53 -0800
Message-ID-Hash: TB3GTGCLLS42N5OMJHRKIKMGCEJHV2ED
CC: dance@ietf.org, draft-ietf-dance-client-auth.all@ietf.org, last-call@ietf.org
Reply-To: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
Subject: [art] draft-ietf-dance-client-auth-09 ietf last call Artart review
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/lLt1bLMTuU11UN5ImwPcRtys0MA>

Document: draft-ietf-dance-client-auth
Title: TLS Client Authentication via DANE TLSA records
Reviewer: Arnt Gulbrandsen
Review result: Ready with Nits

Hi,

I'm the designated ART reviewer for this document, and I'm a little late with
this, after spending a vacation without much mail and my first working week
with. Sorry.

The document looks very nice to me, I'd say it may be ready. I have two
questions that may be nits.

1. What happens if the TLS DANE Client Identity extension is used and there is
a dNSName in the cert, and they differ? My sense is that the dNSName and
identity have to match, and if they don't, TLS negotiation fails. But I don't
see this explicitly anywhere.

2. Section 3 starts with "The client SHOULD explicitly…" and I'm curious why
that's not a MUST. I assume a MUST would lead to fewer interoperation
combinations to test, and I don't see any reason why a client cannot support
this TLS extension. Is interop combinations a smaller concern than I imagine?

[art] draft-ietf-dance-client-auth-09 ietf last c… Arnt Gulbrandsen via Datatracker
[art] Re: draft-ietf-dance-client-auth-09 ietf la… Shumon Huque