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

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
>