IETF Logo Mail Archive

Re: [TLS] Authenticating the client-facing server with an IP-based certificate

Martin Thomson <mt@lowentropy.net> Wed, 21 April 2021 01:01 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12DCA3A0E28 for <tls@ietfa.amsl.com>; Tue, 20 Apr 2021 18:01:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 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_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=0AJ5xyHm; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MuBUVuJw
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uq3GKoZUe9nf for <tls@ietfa.amsl.com>; Tue, 20 Apr 2021 18:00:55 -0700 (PDT)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E00FF3A0E39 for <tls@ietf.org>; Tue, 20 Apr 2021 18:00:55 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 039064207 for <tls@ietf.org>; Tue, 20 Apr 2021 21:00:52 -0400 (EDT)
Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Tue, 20 Apr 2021 21:00:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=/JzkteXFk97GOmHU4dYaxYy2fvL10un ATSlTiinsAlA=; b=0AJ5xyHm98pjs2hLo0Z15G58b5xTyodLcm7GFVZgAHtMhR9 xGO+d+I8ytm+wsGKf7vW9MRc0b9ZfkUesmAmiuCvF3bMy4Ac3dS5vHfL1n0QNKgh Hb/oH4jDMEkUS3pyZTxf6Ufc71E4khrbN3+qp178V/B6rENVwJDptGrvEv8KYFI5 DJSR4036xYNSm2m5lZF7dBZ7rka3qX1NMNVWfQ3gzivDu7FWn7vrt8GNdx0f5aQX dSUjD2BMTU/5ogQ8HJUMIIs5JL7GD6oh5IJrmVAWhvmNfL2QnuYdvw0fDIOemoa/ N7cXy+e/gBdfgpqiLPsQoCRQnkr92soI9SzfIJg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=/Jzkte XFk97GOmHU4dYaxYy2fvL10unATSlTiinsAlA=; b=MuBUVuJwXqwsRSFB10hX63 up/Ii4hhrC0oAGFUp80D6sCBJiXILPobwyy6F+ry+Y48GPBNzQKKSZUjA7MQsSid noHi+dG9To/YId9kRZKNcjzrmxiAdp71IYGCS1PMBEzU56eYkYsu/ORShpx6KAI9 ypsAG9WHNm/9VlGHDH5JQhqMmglxss/VGJuailLMD1RPUlF8RwXVuVV0SbAgrqR3 iPy4t78/8Ep5Myce57lY0AgVBSuOhONUsrogBqYtcwfF3QsRypVxWzJrGU7CVQT+ MovllzuTo7VqGMX0c2ikKhTuJKSEJaxFAHCh0Ye1yEuXgnwZYBCJjeA8NyEyAfWg ==
X-ME-Sender: <xms:Q3l_YAgivtd577MNPQuMg6EFubMHcSvDe1ICBr2_Aip9XNJ3tvoKTg> <xme:Q3l_YJDJ3UWocT3O1-wpTfahfbnn9UQdCfJ9YLyG8KUJTiKTYBWlEZHgRrLRmK2RS 1f2O2cbc2JlygL73Bo>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvddtjedggedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeehfeetudduudehtdekhf dvhfetleffudejgeejffehffevkeduiefgueevkeefleenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht
X-ME-Proxy: <xmx:Q3l_YIGKpqptYF992uJwvd0ZqywMm8BdDxnJfJCU3jCE8JgmFQeZqA> <xmx:Q3l_YBRLKBsuGJ6oGdS3SqB_awmJRsEZt92LPRXg2SiqScBL3H8iuQ> <xmx:Q3l_YNyzT479UkmBtMUK0LcaU6j60lZFCYJCqMNQoU7fPZqm02v80A> <xmx:RHl_YM_FHVZrwroH4Xn1o5h6KAXWttokA9-MH4t2Vzx_gLBt2-vZOw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 97F434E04D1; Tue, 20 Apr 2021 21:00:51 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-380-gda4c716772-fm-20210419.004-gda4c7167
Mime-Version: 1.0
Message-Id: <37c84b96-324b-46a6-a3c0-57eb275f439b@www.fastmail.com>
In-Reply-To: <38f4c969-90d8-478e-9c3d-0bdf538dabed@www.fastmail.com>
References: <38f4c969-90d8-478e-9c3d-0bdf538dabed@www.fastmail.com>
Date: Wed, 21 Apr 2021 11:00:31 +1000
From: Martin Thomson <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/gVCnfcVG9Rf2su5c56NCTj95Pec>
Subject: Re: [TLS] Authenticating the client-facing server with an IP-based certificate
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Apr 2021 01:01:01 -0000

On Wed, Apr 21, 2021, at 10:33, Christopher Wood wrote:
> Taking a step back, it would be great if we could reach consensus on 
> whether or not this is a use case we actually want to solve. 

The Web currently recognizes IP certificates.  The specs, thanks RFC 6125, largely missed this, but we're fixing that.  ACME has RFC 8738 and the latest HTTP(S) spec finally defines validation for an IP-based reference identity.

All that said, IP certificates are naturally a feature with narrow applicability.  For something like ECH fallback, which should be rare, we benefit more from reduced options and simplicity than we do by enabling niche features.  Adding a dependency on a rarely used feature, optional or not, only increases the risk profile.  And complexity.

So I don't think we should support different anything other than a domain name for ECH fallback.

If someone could demonstrate that it would be an undue imposition to require a client-facing server to use a domain name, then I would happily concede the point.  As it is, we're talking about a host that fronts for multiple different names, so I'm finding it hard to imagine how finding a name usable for this purpose would be challenging.

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