Return-Path: X-Original-To: dance@mail2.ietf.org Delivered-To: dance@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id A2A0A121B78AE for ; Fri, 31 Jul 2026 08:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1785513022; bh=Zx9KUrllRrdmAXT97Ne6V0Sh5Efe808m229VGAbaKDg=; h=References:In-Reply-To:From:Date:Subject:To; b=BK2ZVUPKkjKotisgTfj+l2lgvICduv5JyevTOiFlrk940JDCO5CSABFj3OvPUj3gh mkryjsyM4+WREgDwejwXMh1BZxVeqJV2j1XQpCtPKV5q8tW504DKMc5fnTnC052p69 FeVci+dsFEt89L1Zi7/CLD1m7hQYf7uuUSeKsKJw= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=whisper.security Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bD15gmndRKG9 for ; Fri, 31 Jul 2026 08:50:22 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 9FE9F121B789C for ; Fri, 31 Jul 2026 08:50:18 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-69c20ba892eso2969882a12.1 for ; Fri, 31 Jul 2026 08:50:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1785513017; cv=none; d=google.com; s=arc-20260327; b=Jh7keFDhKalBh9AbE3rdOLL2vHN5fVI4dDrtFZRhn+Rkwu4TmYqTc+SI5lT58ePkNQ Msj6NOZGkr/HDJ7gvrpgz032L8u7mxBVG9BrE3coxY3/P1BS3zWSSCoxFLOq6IGGKeaA NkOvt5L3KHuoLMmkLlcXZSPtoFBDV+39n0K0vZdeiCyUtOlOqSIwaw7pp3Ic2JN8hJjU HxUgvpgeJMeK9M0ZpmV0/+3sQ0BQpelhpsTlrBEuEB2zLVwhPsjEYcq7o+xffa9O0MAg zXYr3HmkxQOJ97KsvUq2nHMAvqF37IHfsJ77tVkTWJP4Aa4eIam0Bd/Ue6R6FniHW1g2 mHfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=EYBNfZEqxtdgs9X9/QXz1vD5zvIJYDvuk6DpYx7VTQM=; fh=5nESIyC1WU1PQccGEJekQPxPHcA6nBhHvu8tE65ODu8=; b=mXi8jVjUuMeSyxRUp8DLwCZn71Fw71WQvlYLI/Rrc0DMArQZ7KK9zbl7j1MZkcpSN7 utwfKa3FIrt7AsPKujbjd+DGgmnBpOpMIv7cLRQ9VB3ADxRBm2x17CD/vLQmY2RSmPcM oV8bxb6aHEg0aVgDpHuqMzhp8vLVd+APsbcL/ne/jskEr9rK8gU55RCQxjTwz0m2Zgdo r5Q67JbvKqezrG2EkX44nd/lJtFXS85Koi5AeaYjwN1+dNSFxDt84BySoQ/XLnC+oQ/a 7nuNxxKU1F4FXkXOQ+UVHQqnQA9aOXqFtaMEaH5UrP347Gx37BL8wFyUaLkfAnRr/C3E h8qA==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=whisper.security; s=whisper; t=1785513017; x=1786117817; darn=ietf.org; h=content-type:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=EYBNfZEqxtdgs9X9/QXz1vD5zvIJYDvuk6DpYx7VTQM=; b=Ft4LjOMjZyOQd8mkpgD3Xg1qpCttD3Lhp5fsNL3aChvkC+gkEU9bdTWAOyYVziD0EB wRgTLoDv8FMoj0MglX9vLamuYAr+ebrup2oZD8IkipM5ZlB5aZ5yxqHrYBj53CqzXkYV kjgZlOUe3a+CLh4K+PF4nqqX9zcj1FJ2yMiFM3oDimlshbpgb5E7mtclp2Fe4ZSHVGFr uy2FGuTDrfOVGVNzHd1+Hr49CSNrDsXeQoUg5ZvHPkqtSXbTfaU0l1uEbCvQrz12vbEt L/Npc3QIivmmkmilYamPB2MXrCvp6Aqw8xITwv9LBH+Ft8RE25Yc13ulySyk+Qr9/Qcw kjsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785513017; x=1786117817; h=content-type:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=EYBNfZEqxtdgs9X9/QXz1vD5zvIJYDvuk6DpYx7VTQM=; b=sdeJ3yu6s8wcoCUq9ajWF3vsujrCLQC3ms2IP+SVaNQDpx76HpZ1vNfaKRs2yduWce oRs1Uf+XscAGcm25W80D/iMy2kyO99WWu2N/26ycO39MA993b4yRRH43Yru+e9MxAd2k 6Y6Uo5zG4a375wmRD4eHhNH1F4/RYyzrv+nzuUAi3d92CzRvg0g4QDtWm2aao0frUZ3M Tdr9DOXOp+0JO3x/1RBQUUXRg3m+8CLOSiUyYxOXsyExBptskaPZ8AQ3uqU7n/maMtxq kmcNGSXoIH2kKAYj5IOxwWvXF0p5Ah4IJp3KnLr1iaEqZvhkX4KKxSOhAwd0vJx0qHod 9waQ== X-Gm-Message-State: AOJu0YzvFFQ8gXpGEYOsa/kqyqmitEbRSaYAqFpYKGtvs1FEj9kbtK6/ 8Kbi6Qmox/jJUR1oF6XAhp4Ylx8f1t2T48fSVBCGucbTkNDOzCZ1R/GG5kKcS/j6AgsQtYM2LSU XQ/HJuec8JJMW2tkCf5WGSGzoHKBrOc9TQa3sUnN2JCi7ejX5sj/iH7tpPjP0 X-Gm-Gg: AR+sD10jmY47RTygAIPy7XKpOMcCxic11tJOHX9J/tp1c706x55RCCCOal9cD8LGRr4 Wm/R9b867SqRAC9tIa1/d/WzNj1TIws8NT+/K0lpRW0OPaWvE53l6Fbn3IzenIfghHTYmGimioh 4dxw1EeOL/MJigq7+v3JaDKv9OxEVoHtku34COIHBjI9irxYv8poBl6K2Ywa3HYl98qG3EtozuJ tKkQ3ar9mpdwXcgIWokl/OK2zLrh7b6mihjAvz9cmPwFr6T5i2bZk6a6tkqsX3KYfiBpYrZ5o4z wzmjMImuUvTjKR442oy2LpRv0EVcEGl1kllhNGwykF9ViGAMcyMccUMnAII8JlihDhEE/wliBeP ic7EecALyS2TECP2l8M67y9/6syt8NBqBScA= X-Received: by 2002:a17:906:6a06:b0:c16:9dcf:8fcc with SMTP id a640c23a62f3a-c1fe7bdbf8bmr11724766b.20.1785513017417; Fri, 31 Jul 2026 08:50:17 -0700 (PDT) MIME-Version: 1.0 References: <3437294.1785264150@dyas> <3648997.1785419899@dyas> In-Reply-To: From: Kaveh Ranjbar Date: Fri, 31 Jul 2026 16:50:05 +0100 X-Gm-Features: AUfX_mzRXX0gv5TNZWRGBOigVIOJO7-Q-xMyshIxfyzf95VllOVg--cb5eW72wQ Message-ID: To: dance@ietf.org Content-Type: multipart/alternative; boundary="0000000000002566960657ea255d" Message-ID-Hash: TAUBITXSNQUKEQNN3DNIGAFIB77LCO5S X-Message-ID-Hash: TAUBITXSNQUKEQNN3DNIGAFIB77LCO5S X-MailFrom: kaveh@whisper.security X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BDance=5D_Re=3A_merging_architecture_document_into_client-auth?= List-Id: DANE Authentication for Network Clients Everywhere Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000002566960657ea255d Content-Type: text/plain; charset="UTF-8" I'm in favour of this. The confusion you're pointing at is real, and putting the context next to the mechanism, so a reader doesn't have to reconstruct the intent, is the right fix. Two things from the DNS-operator side, offered as help rather than objection. The part that actually answers the reviews is small: the actor definitions, the when-and-how the server ends up doing a lookup, and the device-versus-user distinction. That is the framing the ADs were missing, and it belongs right next to the extension. The wider catalogue of examples is good context, but it reads as breadth rather than as the thing that makes the privacy posture legible, so I'd weight the introduction and the forward references toward the former. I'm happy to take a pass at that introduction text you flagged, so the folded-in section reads as one argument. The other is the privacy point, since it travels into the client-auth last call with the merged text. I think it's answerable rather than fatal, but only if the document says plainly when this applies and when it does not: machine, device and service identities in an operator-controlled zone are one case; names that resolve to natural persons in public DNS are another, and the enumeration and correlation exposure there is what needs a clear applicability line and a pointer to name-scoping and minimisation. I've written that kind of language before and would gladly draft a Privacy Considerations section for the merged document along those lines. If a concrete example helps anyone follow the flow, I can pull a live DANE-EE name and we can dig the TLSA together. Kaveh On Thu, Jul 30, 2026 09:11 PM, Wes Hardaker wrote: > Michael Richardson writes: > > Greetings all, please do weigh in on this if you have an opinion: > > > I did a PR merging the bulk of the architecture use cases into the > > client-auth document, nearer the end of the document. > > There are no doubt some wording changes and forward references needed in > > client-auth's introduction text. > > > > Please see: > > https://github.com/ietf-wg-dance/draft-ietf-dance-client-auth/pull/13 > > > > this would reduce work to a single document. > > > > My observation is that we got many review comments that were confused > about > > how/when this would be used, how it violated privacy assumptions of > > end-users, etc. Because the entire context of the work was not > understood. > > > > -- > > Michael Richardson , Sandelman Software Works > > > > -= IPv6 IoT consulting =- *I*LIKE*TRAINS* > > *I*LIKE*BOATS* > > (and trains) > > -- > Wes Hardaker > Google > > -- > Dance mailing list -- dance@ietf.org > To unsubscribe send an email to dance-leave@ietf.org > --0000000000002566960657ea255d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm in favour of this. The conf= usion you're pointing at is real, and putting the context next to the m= echanism, so a reader doesn't have to reconstruct the intent, is the ri= ght fix.

Two things from the DNS-operator side, offered as help rath= er than objection.

The part that actually answers the reviews is sma= ll: the actor definitions, the when-and-how the server ends up doing a look= up, and the device-versus-user distinction. That is the framing the ADs wer= e missing, and it belongs right next to the extension. The wider catalogue = of examples is good context, but it reads as breadth rather than as the thi= ng that makes the privacy posture legible, so I'd weight the introducti= on and the forward references toward the former. I'm happy to take a pa= ss at that introduction text you flagged, so the folded-in section reads as= one argument.

The other is the privacy point, since it travels into= the client-auth last call with the merged text. I think it's answerabl= e rather than fatal, but only if the document says plainly when this applie= s and when it does not: machine, device and service identities in an operat= or-controlled zone are one case; names that resolve to natural persons in p= ublic DNS are another, and the enumeration and correlation exposure there i= s what needs a clear applicability line and a pointer to name-scoping and m= inimisation. I've written that kind of language before and would gladly= draft a Privacy Considerations section for the merged document along those= lines.

If a concrete example helps anyone follow the flow, I can pu= ll a live DANE-EE name and we can dig the TLSA together.

Kaveh
=

On Thu, Jul 30, 2026 09:11 = PM, Wes Hardaker <wjhns1@hardakers.net> wrote:
Michael Richardson <mcr+ietf@sandelman.ca> writes:

Greetings all, please do weigh in on this if you have an opinion:

> I did a PR merging the bulk of the architecture use cases into the
> client-auth document, nearer the end of the document.
> There are no doubt some wording changes and forward references needed = in
> client-auth's introduction text.
>
> Please see:
>=C2=A0 =C2=A0https://github= .com/ietf-wg-dance/draft-ietf-dance-client-auth/pull/13
>
> this would reduce work to a single document.
>
> My observation is that we got many review comments that were confused = about
> how/when this would be used, how it violated privacy assumptions of > end-users, etc.=C2=A0 =C2=A0Because the entire context of the work was= not understood.
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works


>=C2=A0 -=3D IPv6 IoT consulting =3D-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *I*LIKE*TRAINS*

*I*LIKE*BOATS*

(and trains)

--
Wes Hardaker
Google

--
Dance mailing list -- d= ance@ietf.org
To unsubscribe send an email to dance-leave@ietf.org
--0000000000002566960657ea255d--