IETF Logo Mail Archive

[TLS] Re: Last Call: <draft-ietf-dance-client-auth-09.txt> (TLS Client Authentication via DANE TLSA records) to Proposed Standard

Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de> Mon, 26 January 2026 19:56 UTC

Return-Path: <muhammad_usama.sardar@tu-dresden.de>
X-Original-To: tls@mail2.ietf.org
Delivered-To: tls@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 6C273AD5B082; Mon, 26 Jan 2026 11:56:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.397
X-Spam-Level:
X-Spam-Status: No, score=-4.397 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_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, 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=tu-dresden.de
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 yx1PZDK1x9wm; Mon, 26 Jan 2026 11:55:59 -0800 (PST)
Received: from mailout3.zih.tu-dresden.de (mailout3.zih.tu-dresden.de [141.30.67.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id F163FAD5B078; Mon, 26 Jan 2026 11:55:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tu-dresden.de; s=dkim2022; h=Content-Type:In-Reply-To:From:References:CC:To :Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=roJ8OkuZ/SBGIOx9qf05RLwQdmCMdT3BnKN2FKI1vbE=; b=UloTOnHfQlVeArr1mKdSZtDZKR snSNx/jAyIWdkNH68cVFf25CdhzRTjGHvWfoW97a+33KnimxNkraCyUSL5/PaF1MyJ8nXne085fhH 8YtLfQIv6f/NbSiw1GD4aYVHWdLeV1SDIkgEqgJImeNuHFJ8ooEHObT5JKTZhT5k8YKb+4NPII55I TDPgqufp8ZxuO5sDYazmr4cq9Cf/ntZQFnP424jWC5IciRSAT11f62/LqdBhLsPahq52B+DfPVPiM P893AkBlyAqWAM/e1YqP6A3tqvbiUY3/H8gJcoDycK1J/RgRKIjepJrJqkr6WI4M4YW9bhQqt8vYt +CsWp8Pg==;
Received: from msx-t422.msx.ad.zih.tu-dresden.de ([172.26.35.139] helo=msx.tu-dresden.de) by mailout3.zih.tu-dresden.de with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <muhammad_usama.sardar@tu-dresden.de>) id 1vkSgn-009vSG-J4; Mon, 26 Jan 2026 20:55:57 +0100
Received: from [10.12.5.228] (141.76.13.165) by msx-t422.msx.ad.zih.tu-dresden.de (172.26.35.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.35; Mon, 26 Jan 2026 20:55:42 +0100
Message-ID: <ec558fe6-1002-4ae1-8dec-b40c01da90e4@tu-dresden.de>
Date: Mon, 26 Jan 2026 20:55:40 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Eric Rescorla <ekr@rtfm.com>
References: <176529902699.1146491.1360588667931244217@dt-datatracker-5bd94c585b-wk4l4> <CABcZeBOCNZf-mYJ2DM1YTnUAYpvtyc5Ba2qQ6aOmsYhS1y5fvA@mail.gmail.com> <CAHPuVdV4TvP4kHsEC=7K5QNFZUktYCRU44LqJr33fzB5Md+Q1Q@mail.gmail.com> <MN2PR17MB4031E3807DE7137A169C2E24CD93A@MN2PR17MB4031.namprd17.prod.outlook.com> <CAHPuVdWssWuFsZNjKHOXc=sRyEDwAzpbtaUkZuTMvZW0=BXGJA@mail.gmail.com> <CABcZeBMcShiaC-Rrd8zdH=xa4OU2dtKtAVVfZF496t=2qJS-fw@mail.gmail.com> <CAGL5yWY3xqxaxgkNg6sYH_GSSha9tVCbcam59OiEnm=7JAyTMw@mail.gmail.com> <CABcZeBPjGrhE_QD2z7=aEMhE=yZbM_uh1aLpV8g2cg_TxbEoBg@mail.gmail.com> <CAGL5yWZ1uCtkQfSpa4O=fiy70XaVdNgQPCPx1Dr4hatC8cc1hw@mail.gmail.com> <CABcZeBO3NOWrSauv06f1vFU7wa_iLNEZXWnF_6F0aVzf_8rrng@mail.gmail.com>
Content-Language: en-US
From: Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de>
In-Reply-To: <CABcZeBO3NOWrSauv06f1vFU7wa_iLNEZXWnF_6F0aVzf_8rrng@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms060404040004050202000503"
X-ClientProxiedBy: MSX-T414.msx.ad.zih.tu-dresden.de (172.26.35.134) To msx-t422.msx.ad.zih.tu-dresden.de (172.26.35.139)
X-TUD-Virus-Scanned: mailout3.zih.tu-dresden.de
Message-ID-Hash: FZQ5OMNNVZNEUW2W2Z7GWQLN3SIXRNW6
X-Message-ID-Hash: FZQ5OMNNVZNEUW2W2Z7GWQLN3SIXRNW6
X-MailFrom: muhammad_usama.sardar@tu-dresden.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "last-call@ietf.org" <last-call@ietf.org>, "dance-chairs@ietf.org" <dance-chairs@ietf.org>, "dance@ietf.org" <dance@ietf.org>, "draft-ietf-dance-client-auth@ietf.org" <draft-ietf-dance-client-auth@ietf.org>, "mcr+ietf@sandelman.ca" <mcr+ietf@sandelman.ca>, TLS WG <tls@ietf.org>, Paul Wouters <paul.wouters@aiven.io>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: Last Call: <draft-ietf-dance-client-auth-09.txt> (TLS Client Authentication via DANE TLSA records) to Proposed Standard
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/zbrpY8PJQtqtFnQ6cTfI174IW9g>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>

Maybe I am missing some discussions that happened outside of TLS. So 
apologies if this is the case.

On 26.01.26 19:36, Eric Rescorla wrote:
>
>     Regardless, the argument cannot be "use the webpki because it
>     offers better privacy features" because for
>     players in this space, non-webpki authentication and authorization
>     is more important than a privacy feature
>     that defends only against passive attacks.
>
>
> I think you are perhaps misunderstanding my comment, because I'm
> not talking about the WebPKI at all in this discussion. I'm instead saying
> that the client should send the DNSSEC chain in a TLS extension
> rather than having the server query for it, thus avoiding revealing
> its identity on the wire. This is entirely isomorphic to the current
> identity structure.

Do I understand correctly that you are proposing the DNSSEC chain to be 
put as an extension of client's Certificate message of TLS 1.3?

-Usama

v2.37.1 | Report a Bug | By Email | System Status