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

Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com> Mon, 18 May 2020 21:08 UTC

Return-Path: <rifaat.s.ietf@gmail.com>
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 D08AE3A0D3D; Mon, 18 May 2020 14:08:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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=gmail.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 BC4dBomdFHo7; Mon, 18 May 2020 14:08:53 -0700 (PDT)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F01ED3A0D19; Mon, 18 May 2020 14:08:52 -0700 (PDT)
Received: by mail-wr1-x42c.google.com with SMTP id l17so13485559wrr.4; Mon, 18 May 2020 14:08:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rqXFRgtK92DuLMVpS3lEJZDKdJZZLLxGy+Rd3p8Tt5A=; b=b2XjohYf73s5el9qX8QQ7LsuXQZDen+GVeDATLwZPWMP6S2Jq4AWRFHNVxKF19huzM nDoAinVmc8s/Fkg69RhS2425rQIhlWSJpzLzg8cZsZLVheJn3rxbIPbAMWv0NEx0Nbk1 hoN7dS7EqK8fUGGeOmq+POSliHWOAnkVrNr4LMWynLspW4TVJAFteorjIKk+ULE5ZcG4 DC6RAy53v/lVj6rW+hEyKXUfN70o40SP6rBHW/QXB/WdxfTM6okbyf1zxJNMy6cpDzss BSZbCLhYQ0F1d7Y6unUlccKU+oPovZ5rnPKu2hZFX54OVS//1d3VwOys0DpqkXeaQie7 wfcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rqXFRgtK92DuLMVpS3lEJZDKdJZZLLxGy+Rd3p8Tt5A=; b=jiSblWIlexTRF3TQA3usnMQnGpIHbclO4RhPMwM7qb6XZivnw60gQvYUmTfheeLa0E 1+XDtuXFrnEuYKsDNaxZHYyZ7kxeNTLghxKHbR4/d5qvSbK0aF3X7uTG/d1ad3yOlMAn uFVBtxoicxGTc1dBEyzIjxEFnLbT0SsxmFk7PWUbxbVshWkeih7D9A2FNMLjNxtJ9Mfq cjpvpTRM6fQqpf1D3fRilQ/4xa2z4iJvMMlZCKFcAARGVVZCeXN1DRIL7S81rF9i7j4o S+sKLZ4W+Z1YLGngeUhgBtJdmBFj1tYgqQFQMHSREGKI3vK2d8dbGJGZ6uLR2n2mMk92 aTmw==
X-Gm-Message-State: AOAM5314bioUB2Pys5MhUE/FfbFN8hlo4jwbRhUtozFAhkKcElc9qW4d J8tMD2FaeYNQoxX9O5c9qb4cuHDUw5Yk4CScTM8=
X-Google-Smtp-Source: ABdhPJymVlOqOB2tD7wZZ3MEOhLWZbf6v6Tkbu+Zp5k7klcDX/oWRXSWL2Fgjo2nw9haJr7mrZcZudRkv9hqypLHqOs=
X-Received: by 2002:a5d:6401:: with SMTP id z1mr23179347wru.226.1589836131368; Mon, 18 May 2020 14:08:51 -0700 (PDT)
MIME-Version: 1.0
References: <CADNypP8o+d4ivAacHQiXUk96F0gDqFe2Qa6rPQsCBgDr_=wHrQ@mail.gmail.com> <CADNypP9hk+gpGuch0mxnePTVRMnn+GmCbpFpKYkVRV4C_FRUgA@mail.gmail.com> <cf39782e-3d76-4104-9430-164f8b1a9846@www.fastmail.com>
In-Reply-To: <cf39782e-3d76-4104-9430-164f8b1a9846@www.fastmail.com>
From: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>
Date: Mon, 18 May 2020 17:08:40 -0400
Message-ID: <CADNypP_iar9CQaP8jqLHyXLCh2+Y7OOhdx3W3Qd93PFj2Fbd3w@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>, kaduk@mit.edu
Cc: secdir@ietf.org, captive-portals@ietf.org
Content-Type: multipart/alternative; boundary="000000000000dc81fe05a5f29172"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/Ie00G9mCRB6m47pe9Gg4b9DQlEI>
Subject: Re: [Captive-portals] Secdir last call review of draft-ietf-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: Mon, 18 May 2020 21:08:55 -0000

Adding Ben.


On Sun, May 17, 2020 at 9:26 PM Martin Thomson <mt@lowentropy.net> wrote:

> Adding more lists.
>
> On Sun, May 17, 2020, at 02:50, Rifaat Shekh-Yusef wrote:
> > > Here is a quote form the API document:
> > > "The hostname of the API SHOULD be displayed to the user in order to
> indicate the entity which is providing the API service."
> > >
> > > This seems to suggest that the user is expected to inspect the
> displayed name and make sure it is make sense in the context of whoever is
> providing that service.
>
> I don't think that is the case.  If this were a security mechanism, then
> it would use "MUST".  This is likely for the purpose of enabling some sort
> of accountability.  In other words, this is to offer maximal information
> about what is going on.
>
> Here is the sentence just before the above quote from the API document:

   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*





> > > Since this would be an easier attack compared to the interception
> attack, and IP address is still permitted, then an attacker might force the
> use of IP address to make it harder for the user to make sense of the
> displayed name.
>
> I don't think that is materially different than getting a name with
> confusable characters (or using the prefix hack, example.com.<some-guid>.example,
> in an attempt to confuse).
>

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.

Regards,
 Rifaat