I think there are two separate things here.
[1] The use of HTTPS allows the client to authenticate the API and
interactive URLs the same way a browser would be confident it's
talking to amazon.com, for example.
I think in this sense, the text is correct.
[2] There is, however, no way to know whether
bobshouseofportals.example.com is the authoritative captive portal
service for the MyCoffeeShop ESSID.
We should have this explicitly stated somewhere. I couldn't quickly
find such a section, but perhaps I should add some text about this to
the 7710bis Security Considerations or thereabouts.
On Sat, Jun 6, 2020 at 1:02 PM Rifaat Shekh-Yusef
wrote:
>
> Hi Tommy,
>
> You will probably need to do more than just dropping this specific sentence,
> because the text just before this sentence talks about the client
> authenticating the server and allowing the user to be confident of the server
> and its identity.
>
> Regards,
> Rifaat
>
>
> On Tue, Jun 2, 2020 at 1:33 AM Tommy Pauly wrote:
>>
>> Hi Rifaat,
>>
>> Your comments make it clear that the recommendation to make the API server
>> name visible isn’t necessarily clear. I think it’s not a harmful thing to
>> show, as a way to give troubleshooting information and transparency to the
>> user, but it is not a security-critical point.
>>
>> It seems appropriate to either explain the rationale more in depth, or
>> remove that sentence entirely to avoid the misinterpretation.
>>
>> Do others in the CAPPORT group have thoughts on this sentence, and any
>> background on why we decided to go that way? Would there be any objections
>> to removing the sentence?
>>
>> Thanks,
>> Tommy
>>
>> On Jun 1, 2020, at 6:05 PM, Rifaat Shekh-Yusef
>> wrote:
>>
>>
>>
>>
>> On Sun, May 31, 2020 at 2:07 AM Erik Kline wrote:
>>>
>>> On Wed, May 20, 2020 at 4:37 AM Rifaat Shekh-Yusef
>>> wrote:
>>> >
>>> > Adding SecDir back to this thread.
>>> >
>>> >
>>> > >Martin Thomson 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 exp
