Re: [Captive-portals] Secdir last call review of draft-ietf-capport-rfc7710bis-04

Martin Thomson <mt@lowentropy.net> Tue, 19 May 2020 01:02 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA623A0DFE for <captive-portals@ietfa.amsl.com>; Mon, 18 May 2020 18:02:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=lowentropy.net header.b=HScWNl94; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Yhuri7M+
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 pv0zlwB1xzBk for <captive-portals@ietfa.amsl.com>; Mon, 18 May 2020 18:02:50 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26EF73A0DFC for <captive-portals@ietf.org>; Mon, 18 May 2020 18:02:50 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 6DC545C00C2 for <captive-portals@ietf.org>; Mon, 18 May 2020 21:02:48 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Mon, 18 May 2020 21:02:48 -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=7jyu8hmy/8Agutf1lKxZnxONfZR4ZXW Ate5HSiIoRdc=; b=HScWNl94xNiTRuLohmxg/VqpGpzubf/TiYEyOZTEnBr9WAu ls9PZ9O2yfniTVkgmkonvD592jZfv4V5yhEQWcAEiodpQ3K0pVoXIMDs+VzcALU4 PPCpL1gJjz0waiLLQkwmeuDlq6lRlPttpN0DW9gCqjRB0a5QCtvKpTfIYZIqnKyd md0LTJ28AmCO/4zUHp2zJf5YS9aHkuXApCvfayFFKeyVT5ojUPNExJo7cdaU4uQh Jix9NbGqdX1J+NT+eUCF1DyJg+yvZKp2EhF0DliPqz+XZSISLVsF1/cN8dm5wUmS UKlAB/n9j01QzWxcas5lY0UUeXzGVl/Jmk1GnKw==
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=7jyu8h my/8Agutf1lKxZnxONfZR4ZXWAte5HSiIoRdc=; b=Yhuri7M+1+0UpsNKAMoZw3 FjXCXpZ7DZgtQZCSshyoLTVbuG1KmYgxUkN0vtl1V14GptN1f8WpHsP99lS/C5Gn /EJsAy53h9TYdcuXLJzPT1Bvjvi/kX6qDlY+LJl8BeQK1Xf8pUnoq+/Qo7DFbRK4 GygZh+6sOS+ckTyIvPEjZkFkLba5pS0pzCSIo6fE6eemuBxyAXvm61EU70Ne80vZ xin44YZYHxY32HTDwS4JBeuDbje7Cn8JHZbeA3Vd/tiGqn5O75+i7SVC1Rmen6eq R5DMtP1ZbZO6Qhl+IzcpS95+yDynOL+Lp44S0M/uCaAoaZdGvfc07BZnsdPzUIJw ==
X-ME-Sender: <xms:NzDDXsTLasZeVvVhnXy5WjsjmgR0Nc-VXi_BJ2mL3LxvYVQ9jlNC7A>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddtiedggeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeeuieekvdetfeeludfhtd ffuedvueefjefgveeivdeviefhteekgfdvfeefieeihfenucffohhmrghinhepvgigrghm phhlvgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:NzDDXpz2MIfDoHX5c8i9kJAKt7amcEHlCiTjlQzpxapO9pVfpD_k0Q> <xmx:NzDDXp2AmSQljkxIo30B0e_6BmyO7_IWnBF84piVQ-wgxSUjYc5i4A> <xmx:NzDDXgA9iHp6qZUvoY_DrlO5eBe6GMDoXWWeHInkgu8JrHuRfV95Ug> <xmx:ODDDXsS32zjweEhk7TKku8WwKQ-CMayxxQnmucTv1cDyPFMQe6ePrg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id D0AEFE00F8; Mon, 18 May 2020 21:02:47 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-464-g810d66a-fmstable-20200518v1
Mime-Version: 1.0
Message-Id: <3d7bc69e-f548-44a4-8b5e-c927d7696467@www.fastmail.com>
In-Reply-To: <CADNypP_iar9CQaP8jqLHyXLCh2+Y7OOhdx3W3Qd93PFj2Fbd3w@mail.gmail.com>
References: <CADNypP8o+d4ivAacHQiXUk96F0gDqFe2Qa6rPQsCBgDr_=wHrQ@mail.gmail.com> <CADNypP9hk+gpGuch0mxnePTVRMnn+GmCbpFpKYkVRV4C_FRUgA@mail.gmail.com> <cf39782e-3d76-4104-9430-164f8b1a9846@www.fastmail.com> <CADNypP_iar9CQaP8jqLHyXLCh2+Y7OOhdx3W3Qd93PFj2Fbd3w@mail.gmail.com>
Date: Tue, 19 May 2020 11:02:27 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: captive-portals@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/bfyyn6nDPk10Dp-1wG0HGojeR2E>
Subject: Re: [Captive-portals] =?utf-8?q?Secdir_last_call_review_of_draft-iet?= =?utf-8?q?f-capport-rfc7710bis-04?=
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 May 2020 01:02:52 -0000

On Tue, May 19, 2020, at 07:08, Rifaat Shekh-Yusef wrote:
>    it provides the client of the API
>    an opportunity to authenticate the server that is hosting the API.
>    This authentication is aimed at *allowing a user to be reasonably
>    confident that the entity providing the Captive Portal API has a
>    valid certificate for the hostname in the URI* 
[...]
> An end user should be able to validate that the name is example.com and 
> not any other form of the URI.
> It would be much more difficult for the end user to make sense and 
> validate an IP address.

I think that you missed the point of my comments.  This validation, performed by a user, has no meaningful security value.  The text you cite says that the server has a certificate for the name it chooses, which is not the same as "has a certificate for a name the client expects".  The difference is important.

In a typical web scenario, a person types a string in and (ignore the case where there is an extra hop via a search engine) that string determines what is acceptable as a server identity.  The exposure to confusables is limited (under a set of other assumptions, HSTS, etc...).  Here, the network has free reign to do as they choose with homoglyphs and other such nonsense.  Any expectation you might have about this really being a trustworthy entity is meaningless in this context.

There are protections against this, but they all lie firmly in the anti-phishing domain.  Most of those rely on having a certificate though, so the requirement for HTTPS is in service of that, not in terms of ensuring that an untrained human can make a security critical decision based on poisoned information.