[Dance] Re: WG Last Call: draft-ietf-dance-client-auth-13 (Ends 2026-08-11)

[Shumon Huque <[e-mail]>]

Hi Kaveh,

Thank you for your comments and apologies for my belated response ...

On Fri, Jul 31, 2026 at 12:57 PM Kaveh Ranjbar <kaveh=
[e-mail]> wrote:

> I support publishing this, and with the two TLS drafts now folded together
> I don't see anything the combine broke, so from me it's a ship it.
>
> Two small things for the editors, neither a reason to hold the document.
>
> Privacy would sit better as its own short section with an applicability
> line than as a paragraph inside Security. The text already concedes that
> client names corresponding to people carry a graver risk than machine
> identities; saying plainly where this fits, machine, device and service
> identities under an operator-controlled zone, and where publishing client
> names in public DNS needs real care, natural-person identities, where
> enumeration and correlation are the exposure, is also the cleanest way to
> answer the privacy concern raised on the architecture side as that context
> moves in. Happy to contribute that text.
>

To my knowledge, it's still not common practice for RFCs to have a separate
privacy considerations section. RFC 6973 suggests that many docs should
have one, but also states "For certain specifications, privacy
considerations are a subset of security considerations and can be discussed
explicitly in the security considerations section.", and that's where we
landed with this doc.


>
> The other is the server's handling of a validated denial of existence.
> Section 8.2 covers validation failure, but an authenticated NODATA or
> NXDOMAIN, an insecure or unsigned delegation, and a bogus answer are three
> different states, and a validated proof that no TLSA exists is not the same
> as a lookup failure. A defined branch for each would help implementers.
>

That's a good point. Let me add some text to explicitly cover those
additional states (unauthenticated response because of an unsigned zone or
insecure delegation along the path, NODATA, or NXDOMAIN) - they should all
be treated the same as the validation failure case: the TLS server should
abort or, if server policy allows, treat the client as unauthenticated.
(DANE client authentication should only proceed if the server gets an
authenticated TLSA RRset response for the client).

Shumon.