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

Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com> Tue, 02 June 2020 01:05 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 535F23A0736; Mon, 1 Jun 2020 18:05:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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 5zCYH-rNk_DA; Mon, 1 Jun 2020 18:05:18 -0700 (PDT)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 A146A3A0658; Mon, 1 Jun 2020 18:05:17 -0700 (PDT)
Received: by mail-wr1-x434.google.com with SMTP id x6so1585688wrm.13; Mon, 01 Jun 2020 18:05: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=Emh7q+r9fhuKThk/6IyBM6MXDVr4qJmFjxu6S7Cl6Qw=; b=mAIV24PUuqaBst92sJizv+tiwVQaVnZ2xGS9qIE7xC7gGckURvY14JKSg3ETmCHHf0 FjqYVxMdgX19Jt7gwOliax40r+d1zWhay94z7Ebjs7vGteyO3Cy/8AjAClhbm6rGIjwg 29gyd0oOHvwAM7o0FTHpLsDSTLnPLLyKOpQD7deEK1g1tJUWXRuYKEKXSSCYYLLKF+UM oRNWYm+c6+wZ+id1U3hdNvkorudPpRUTPQePe6wbPQS1yFyHkBbfRUlml/YIZewmEEqz Ddst6ZpqNGD3V591iZpKhDmo65igqzCPJHCP0wEFpDuNDqdK4pjbywlWV1qlNdfcNQ4A R21Q==
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=Emh7q+r9fhuKThk/6IyBM6MXDVr4qJmFjxu6S7Cl6Qw=; b=Q5xqwk1ge9kXOU8frjMX4rEkF2RXJ6nl6mpnYWziK99hNd3Yh1fyqE1Ke9IeBethur N1mLPNF/3gltehoh9boCpehsQ1FOxqCw34qxYCdYEYYiaT8omAbzuHBcTHNCW/NMf/Oc 5vq2DeXwnyS3Pf13ZIexcLOwrnBRrRj4kT5S/H5jH3bs1OcEij0ct7BV+gXr0OV+xQNR VikLuNnPeOgF6UIrSgGnTS7GyhOCc/p7Tgfa9KLeiorYLg2Vfju9HA3e47ZUPuJUI5jK VK73lq25t81BCOa1Cqfk+cPYnJADgE1/B5jtuFKCuYyjHtDfK8n7p1IQnirBM/o050Kx Gd4w==
X-Gm-Message-State: AOAM533kwyxeJc8p6EOhckxXvdc4qhAaC/qT7P/DgM0qJbOVT2V/06n1 TtDO3j195T/c4thLwKgDJFoPaio1hTz3AgjYDas=
X-Google-Smtp-Source: ABdhPJwTlseqe//+XgIl1R0dhdiiV13maeJ7YvNvqvcRyuebCMEgITRzqtMcbqEQY3CfdI7+QW4YWfE29UZiHO0bQVA=
X-Received: by 2002:adf:82d0:: with SMTP id 74mr22676583wrc.138.1591059916125; Mon, 01 Jun 2020 18:05: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> <CAMGpriWUMnmSGmNUX2sJQFzewkgXBK8=WvsJZJOLbFbJ=htRhw@mail.gmail.com>
In-Reply-To: <CAMGpriWUMnmSGmNUX2sJQFzewkgXBK8=WvsJZJOLbFbJ=htRhw@mail.gmail.com>
From: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>
Date: Mon, 1 Jun 2020 21:05:05 -0400
Message-ID: <CADNypP-MYk31mt2v8sqzYd583cTqHbfB4r6J0V_Lq5T7KuDsxg@mail.gmail.com>
To: Erik Kline <ek.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: multipart/alternative; boundary="0000000000001dfb8d05a70f81de"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/le-TzPdf8Yx4N5ifVlCpOQhYp1o>
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: Tue, 02 Jun 2020 01:05:20 -0000

On Sun, May 31, 2020 at 2:07 AM Erik Kline <ek.ietf@gmail.com> wrote:

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


The following is a quote from section 4.1 of the API document, which
implies otherwise:
"The hostname of the API SHOULD be displayed to the user in order to
indicate the entity which is providing the API service."

Regards,
 Rifaat




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