IETF Last Call Review of draft-ietf-dance-client-auth-09
review-ietf-dance-client-auth-09-artart-lc-gulbrandsen-2026-01-12-00

Request Review of draft-ietf-dance-client-auth
Requested revision No specific revision (document currently at 10)
Type IETF Last Call Review
Team ART Area Review Team (artart)
Deadline 2026-01-09
Requested 2025-12-09
Authors Shumon Huque , Viktor Dukhovni
I-D last updated 2026-03-02 (Latest revision 2026-03-02)
Completed reviews Dnsdir IETF Last Call review of -09 by Matt Brown (diff)
Genart IETF Last Call review of -09 by Susan Hares (diff)
Secdir IETF Last Call review of -09 by Mike Ounsworth (diff)
Artart IETF Last Call review of -09 by Arnt Gulbrandsen (diff)
Assignment Reviewer Arnt Gulbrandsen
State Completed
Request IETF Last Call review on draft-ietf-dance-client-auth by ART Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/art/lLt1bLMTuU11UN5ImwPcRtys0MA
Reviewed revision 09 (document currently at 10)
Result Ready w/nits
Completed 2026-01-12
review-ietf-dance-client-auth-09-artart-lc-gulbrandsen-2026-01-12-00
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?