Subject: [secdir] Secdir last call review of draft-ietf-capport-rfc7710bis-04

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 15 May 2020 08:47:37 -0400

Hi  Martin,

Sorry, I missed this message as I changed email address because some
spammers have been sending spams with my email address as a sender, and as
a result I would get angry emails from the spam targets.

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.

Here is a quote from this document:
"An attacker with the ability to inject DHCP messages or RAs could

   include an option from this document to force users to contact an
   address of his choosing.  As an attacker with this capability could
   simply list himself as the default gateway (and so intercept all the
   victim's traffic); this does not provide them with significantly more
   capabilities, *but because this document removes the need for
   interception, the attacker may have an easier time performing the
   attack*."

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.

Regards,
 Rifaat

[adding back some lists]

-Ben

On Wed, May 06, 2020 at 02:37:39PM +1000, Martin Thomson wrote:
> What does "extra cautious" mean?  I assume that this is intended to apply to what a human might do, further implying that there is a role for a human decision.
>
> None of this architecture requires the involvement of a human in this way. Nor do I think that there is any meaningful distinction between an opaque string of characters (that might include confusables) and an opaque string of digits.
>
> I appreciate the sentiment here, but the fundamental problem is that once you decide that this information is not from the network, it is useless. If it is from the network, it is only of limited use. That use cannot depend on the identity of the server, so there is no value in any sort of caution.
>
> On Wed, May 6, 2020, at 13:36, Benjamin Kaduk wrote:
> > [My unicast reminder got a unicast reply; forwarding to someplace at least
> > vaguely useful.]
> >
> > -Ben
> >
> > On Tue, May 05, 2020 at 07:57:14PM -0400, Rifaat Shekh-Yusef wrote:
> > > Thanks for the reminder Ben.
> > >
> > > Erik,
> > >
> > > Since this document allows the use of IP address to represent the portal
> > > URI, I think it would important to add some text that explicitly states
> > > that the user might be presented with an IP address instead of the hostname
> > > of the API, and in that case the user should be extra cautious when this
> > > happens.
> > >
> > > Regards,
> > >  Rifaat

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 16 May 2020 12:50:28 -0400

Adding Martin.

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 18 May 2020 11:26:29 +1000

Adding more lists.

On Sun, May 17, 2020, at 02:50, Rifaat Shekh-Yusef wrote:
> > "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.

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

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 18 May 2020 17:08:40 -0400

Adding Ben.

On Sun, May 17, 2020 at 9:26 PM Martin Thomson <[email-masked]> wrote:

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

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 20 May 2020 07:37:14 -0400

Adding SecDir back to this thread.

>Martin Thomson <[email-masked]> Tue, 19 May 2020 01:02 UTCShow header
>
>On Tue, May 19, 2020, at 07:08, Rifaat Shekh-Yusef wrote:
>[...]
>> 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 <[email-masked]>
wrote:

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

---

From: Erik Kline <[email-masked]>
Date: Sat, 30 May 2020 23:07:05 -0700

On Wed, May 20, 2020 at 4:37 AM Rifaat Shekh-Yusef
<[email-masked]> wrote:
> >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
> This is not the way I read these statements from section 4.1 titled Server Authentication.
>
> 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

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
> >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
> On Mon, May 18, 2020 at 5:08 PM Rifaat Shekh-Yusef <[email-masked]> wrote:
>>
>> Adding Ben.
>>
>>
>>> Adding more lists..
>>    This authentication is aimed at allowing a user to be reasonably
>>    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.
>>
>> Regards,
>>  Rifaat
>>
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals