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

[Rifaat Shekh-Yusef <[e-mail]>]

Adding SecDir back to this thread.


>Martin Thomson <[e-mail]> 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.

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 <[e-mail]>
wrote:

> Adding Ben.
>
>
> On Sun, May 17, 2020 at 9:26 PM Martin Thomson <[e-mail]> 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
>
>