[dane] Questions about rfc7673 as it pertains to XMPP

Stephen Paul Weber <singpolyma@singpolyma.net> Tue, 24 October 2023 19:13 UTC

Return-Path: <singpolyma@singpolyma.net>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA29C151984 for <dane@ietfa.amsl.com>; Tue, 24 Oct 2023 12:13:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.407
X-Spam-Level:
X-Spam-Status: No, score=-4.407 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=singpolyma.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPhrc2oFwPqX for <dane@ietfa.amsl.com>; Tue, 24 Oct 2023 12:13:24 -0700 (PDT)
Received: from singpolyma.net (singpolyma.net [192.99.233.116]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91DE4C15170B for <dane@ietf.org>; Tue, 24 Oct 2023 12:13:24 -0700 (PDT)
Received: by singpolyma.net (Postfix, from userid 1000) id 9356A48618BB; Tue, 24 Oct 2023 19:13:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=singpolyma.net; s=iweb; t=1698174803; bh=2pBaL8OZcPaOfpC7ZHMFw/NJ/YbOUKIgQbXFBGfppBc=; h=Date:From:To:Subject:From; b=mCHI47nmWTOPA+mwV1IVD7nZV/oRo9Ps28qOvuPKHeXdMAxfrwJdlEHtP4bOg8g7C PRcRS9beThaceJn2cnlMjhfM6wI6935dvIstuOOKBcM2p/uoQbbK712jXMWO4K5oX+ rlNTkp2Jb/UgUFVbnI1fp8bj8wnA+GaZ4Yc7Z2Ro=
Date: Tue, 24 Oct 2023 14:13:23 -0500
From: Stephen Paul Weber <singpolyma@singpolyma.net>
To: dane@ietf.org
Message-ID: <ZTgXU1AtNDUPVUjE@singpolyma-beefy.lan>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="REfOIf4RlQ0CFb0r"
Content-Disposition: inline
Jabber-ID: singpolyma@singpolyma.net
OpenPGP: id=CE519CDE; url=https://singpolyma.net/public.asc
X-URL: https://singpolyma.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/dane/EWGxfWyutmw3SQA-QTXM_yH8Mbk>
Subject: [dane] Questions about rfc7673 as it pertains to XMPP
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Oct 2023 19:13:28 -0000

Hello there, I have some questions about RFC7673 (DANE SRV) from the 
perspective of XMPP.  Especially because XMPP is used as an example in the 
document, there is an implication that *both* of TLS SNI *and* <stream 
to="..."> are meant to be the same and each set to the SRV target name 
(hostname) rather than the SRV lookup name (service name).  However, 
actually doing so would only work in one case, where the service name and 
hostname happen to be the same, such as if SRV is only being use to specify 
a port number for direct TLS.

In any other case it would be necessary (and in line with all existing 
pracise) to send SNI and <stream to="..."> for the service name and not the 
host name, so that the XMPP server can know what service is being talked 
about, what users are valid, etc.  Of course, I think since rfc7673 is 
"generic advice" we could override this specific for XMPP without too much 
trouble, but it's a bit extra awkward because the RFC uses us as an example, 
so I'm looking for clarity on what is suggests what it does.

Thank you,