[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,
- [dane] Questions about rfc7673 as it pertains to … Stephen Paul Weber