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

Erik Kline <ek.ietf@gmail.com> Sun, 31 May 2020 06:07 UTC

Return-Path: <ek.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 CEC173A1262; Sat, 30 May 2020 23:07:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_FROM=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 S88E2PbEsuzU; Sat, 30 May 2020 23:07:17 -0700 (PDT)
Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 350503A125F; Sat, 30 May 2020 23:07:17 -0700 (PDT)
Received: by mail-ot1-x329.google.com with SMTP id h7so5392198otr.3; Sat, 30 May 2020 23:07:17 -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=VBAWVSGSvV+d96OvlnCx/6y0MFAKzcN9bR0fVDs1iMM=; b=Vu2yBE6ubZswJVxHIgwJT5rbVJhClrv2yosiK6yJdjZOgufFSOY63E4Y9yC7hgHcTu 7V2LAunpM/Y1iey1fQXbXbyQ5aky+EMRQlwnYOkmkO1zhUD7yq2V8dCKXA5LqIF8ht4m AsrzVIcDm7QYN5AOC2+CUjtBvghOJJEu/iVM2qpTknr803u6IENSFj8kgUw9ps2OuT56 GbefVM0xXi2SiemHN/xzBjAny31WWHc4pCTS1FARu4MEN0C1HtRNrKklpl+KzqHXcfoq xKYJudhuDTg7hifDyAm/Jk0AJQvfAbdr7fLK4hKaE41BPfIXYuVPpjvNC6At0xvt9BzV j+mQ==
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=VBAWVSGSvV+d96OvlnCx/6y0MFAKzcN9bR0fVDs1iMM=; b=hohztl/GPGRg/nNj6xoKI9IZdE6VgRQ9tpoMGmMzWJgHtAzXgGkmVbbkBKiVA8ed0C h5DtWw9HeBy+axOgHLPmBLXuLzUOizViwUQ7Yrsbce372hz43zaRAXErffbXEBhf1msZ KyjSVRF8jsBtpQYDiLRF290jFZuggjN/Af18J9y6tzu0UC4saxupTJOmYmEbPOdiGXWN 4wfR9ebfqAgnuc2o8UXAPi9Lp2jnTL4v+ix8RBCf97MhTv7NWaeViRi5PMMsixYO7xKu x+rb7INyWiXg/G/zWX7slPlw42tT/rp8fqdXfaEBe9+HaMlEj4y8U92xjhe+BIebFbaD JCEA==
X-Gm-Message-State: AOAM532jwvOfyUZ5P/7m0gTC2lSvrnNK1T8Oj02eGl8AP0Y4rWpMGxey msRr62CnbENYlZNmuuxb/ARTAVRGXkLNG61SJk8=
X-Google-Smtp-Source: ABdhPJyzSVurICrus49JgIMZ+NlkltoxhIiAucbN4+u9bH3Ze7ViWDVi/W12maGrHGxl5Ubp3VlcTzkonCfUyZf6WvQ=
X-Received: by 2002:a05:6830:1af4:: with SMTP id c20mr5651003otd.191.1590905236505; Sat, 30 May 2020 23:07:16 -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> <CADNypP_iar9CQaP8jqLHyXLCh2+Y7OOhdx3W3Qd93PFj2Fbd3w@mail.gmail.com> <CADNypP-_Bw6nw=5EgncBstYPbYTV1xiZ7fYUtS-Cr42_O=s+eA@mail.gmail.com>
In-Reply-To: <CADNypP-_Bw6nw=5EgncBstYPbYTV1xiZ7fYUtS-Cr42_O=s+eA@mail.gmail.com>
From: Erik Kline <ek.ietf@gmail.com>
Date: Sat, 30 May 2020 23:07:05 -0700
Message-ID: <CAMGpriWUMnmSGmNUX2sJQFzewkgXBK8=WvsJZJOLbFbJ=htRhw@mail.gmail.com>
To: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>
Cc: Martin Thomson <mt@lowentropy.net>, Benjamin Kaduk <kaduk@mit.edu>, Barry Leiba <barryleiba@computer.org>, captive-portals <captive-portals@ietf.org>, IETF SecDir <secdir@ietf.org>, Tommy Pauly <tpauly@apple.com>, d.thakore@cablelabs.com
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/GAce10hOW0rf6VSc9ElFtwxgnh0>
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: Sun, 31 May 2020 06:07:19 -0000

On Wed, May 20, 2020 at 4:37 AM Rifaat Shekh-Yusef
<rifaat.s.ietf@gmail.com> wrote:
>
> Adding SecDir back to this thread.
>
>
> >Martin Thomson <mt@lowentropy.net> Tue, 19 May 2020 01:02 UTCShow header
> >
> >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.
> >
>
> This is not the way I read these statements from section 4.1 titled Server Authentication.
>
> Here is the use case I have in mind when I read this section:
> If I walk into an airport and I see an ad for a paid Internet service from example.com, then as an
> end user it is reasonable to expect that I would have some ability to make sense of the name
> presented to me and make sure it is from example.com if I choose to get such a service.
>
> If this is not the case, then yo might want to make it clear that this is not about Server Authentication
> as the title of the section and the text inside that section is suggesting.

If we changed the API document's section 4.1 title from "Server
Authentication" to "API Server Authentication", would that be more
clear?

I reality, users should never see the API URL.  They'll just be
connecting to "Cool Cafe" or "Awesome Bookshop" ESSIDs.  If anything
will only be one or both of the "user-portal-url" or "venue-info-url"
URLs that might be visible in the browser that's opened for the user's
interaction.

-ek

> Regards,
>  Rifaat
>
>
>
> >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.
>
> On Mon, May 18, 2020 at 5:08 PM Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com> wrote:
>>
>> 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
>>
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals