From nobody Tue Apr 20 18:31:08 2021 Return-Path: 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 ; 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 ; 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 ; 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 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 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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: >=20 > 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=20= >> whether or not this is a use case we actually want to solve.=20 >=20 > 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. >=20 > 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. >=20 > So I don't think we should support different anything other than a = domain name for ECH fallback. >=20 > 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. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls