IETF Logo Mail Archive

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

Carrick Bartle <cbartle891@icloud.com> Wed, 21 April 2021 01:31 UTC

Return-Path: <cbartle891@icloud.com>
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 94E4A3A1136 for <tls@ietfa.amsl.com>; Tue, 20 Apr 2021 18:31:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level:
X-Spam-Status: No, score=-2.549 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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=icloud.com
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 3aRCOeJkay9Y for <tls@ietfa.amsl.com>; Tue, 20 Apr 2021 18:31:02 -0700 (PDT)
Received: from mr85p00im-ztdg06021701.me.com (mr85p00im-ztdg06021701.me.com [17.58.23.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1531C3A1133 for <tls@ietf.org>; Tue, 20 Apr 2021 18:31:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1618968661; bh=Lp2dXery0ugbzHwlE55ea3AMMBSuRufiG/VUcLrl6pY=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=u5kvdRWXh6n3QbtrYTfBVeaZOhe4zOtsnrHUpgmqyewczH5s1giTrCuThJLPXuc4I A9ZlF6u/q+ctvYEjaJXIxxvfbzVUFdAcKHMmF6RCyCZ5HfrTk/S1Y+smceJCwX3Pm/ Im7ouIJY42XoK3BF1PHts9OryaVPgcbTu123fKLV473vptT+XmCJAq7m7mEMDS9hoz QAEePjgITFAxf739OFPCDpYlwFfW842Q0/Bxd4LZZTtRLPGsy5S3s/wWJagafrwOK+ 8I3AibOsbXyYwzAn/NHk324rlO2g7rdozH5oS9bYPXn83iuZuEsE58nYYnsvfrHSz+ OPDt2FLvV1OPw==
Received: from smtpclient.apple (unknown [17.11.113.204]) by mr85p00im-ztdg06021701.me.com (Postfix) with ESMTPSA id 60BA9A00888; Wed, 21 Apr 2021 01:31:01 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\))
From: Carrick Bartle <cbartle891@icloud.com>
In-Reply-To: <37c84b96-324b-46a6-a3c0-57eb275f439b@www.fastmail.com>
Date: Tue, 20 Apr 2021 18:30:47 -0700
Cc: tls@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <674A5578-85C8-4134-B9AA-E9D287131701@icloud.com>
References: <38f4c969-90d8-478e-9c3d-0bdf538dabed@www.fastmail.com> <37c84b96-324b-46a6-a3c0-57eb275f439b@www.fastmail.com>
To: Martin Thomson <mt@lowentropy.net>
X-Mailer: Apple Mail (2.3654.80.0.2.43)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-20_11:2021-04-20, 2021-04-20 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=988 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2009150000 definitions=main-2104210011
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/RvrLUzIrrn-aSJAZpAXQXpB0nM0>
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:31:07 -0000

> 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.

This does sound unusual. That said, if this sort of set-up is possible (which presumably it is), it seems unfortunate to make ECH impossible in that scenario.



> On Apr 20, 2021, at 6:00 PM, Martin Thomson <mt@lowentropy.net> wrote:
> 
> 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.
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email