Subject: [Captive-portals] WGLC on draft-ietf-capport-rfc7710bis-01

From: "Martin Thomson" <[email-masked]>
Date: Mon, 02 Mar 2020 09:49:09 +1100

Hi everyone,

The editors of draft-ietf-capport-rfc7710bis-01 believe it to be ready for publication.

Please send comments on this before 2020-03-16.

Comments supporting publication as-is are valued as much as comments highlighting issues.

Note that Erik is an editor of this document, so he won't be assessing consensus.

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 02 Mar 2020 10:07:00 +1100

I have two minor comments of my own to add:

The prioritization section (S3) suggests that conflicting sources of URIs be prioritized.  However, this specifically avoids stating any preferred order.  Rather than saying we don't specify it, how about explicitly letting implementations decide?

OLD:
   URI precedence in this situation is not
   specified by this document.
OLD:
   Implementations can select their own precedence order.

The security considerations (S5) includes this text:

   Operating systems should conduct all interactions with the API in a
   sand-boxed environment and with a configuration that minimizes
   tracking risks.

I would suggest that this is a bad idea.  I personally would recommend against it.  It might have been wise in the past when HTTPS rates were lower, but 2020 is not 2014.  Captive portals occasionally do things like access SSO services (Facebook being one) and a sandbox often doesn't have access to the same persistent storage as a genuine browser.  Asking people to enter passwords in a sandbox can have the effect of building insensitivity to phishing attempts; especially when that sandbox could have limited anti-phishing capabilities compared to a full-fat browser.

I realize that this is in tension with the desire to minimize tracking of people across points of physical connectivity.  I think that the best we can do is recognize that tension and let people reach their own conclusions.

On Mon, Mar 2, 2020, at 09:49, Martin Thomson wrote:
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>

---

From: Kyle Larose <[email-masked]>
Date: Sat, 7 Mar 2020 08:06:22 -0500

Hello,

I support publication.

I do have a couple of minor comments. Section 1 mentions a future protocol
to be worked on by the IETF:

"
   It is anticipated that the IETF will work on a more fully featured
protocol
   at some point, to ease interaction with Captive Portals.
"

Section 2 mentions the draft API document (draft-ietf-capport-api). Is this
somewhat inconsistent with the statement rom section 1? That said, we
haven't really started on a signalling protocol, or there may be other
things we want to do, so this could be leaving the door open to future
extensions, but it seems a little odd to me.

I have a minor editorial comment about section 5:

"
   By handing out a URI using which is protected with
   TLS, the captive portal operator can attempt to reassure the user
   that the captive portal is not malicious.
"

s/using which is/using
or
s/using which is/which is

---

From: Warren Kumari <[email-masked]>
Date: Sat, 7 Mar 2020 19:54:58 -0500

On Sat, Mar 7, 2020 at 8:06 AM Kyle Larose
<kyle=[email-masked]> wrote:
>
> Hello,
>
> I support publication.
>
> I do have a couple of minor comments. Section 1 mentions a future protocol to be worked on by the IETF:
>
> "
>    It is anticipated that the IETF will work on a more fully featured protocol

Thank you -- I removed that text, and then reworded the reset of the
paragraph to flow better.

>
> Section 2 mentions the draft API document (draft-ietf-capport-api). Is this somewhat inconsistent with the statement rom section 1? That said, we haven't really started on a signalling protocol, or there may be other things we want to do, so this could be leaving the door open to future extensions, but it seems a little odd to me.
>

Yup, it did indeed -- fixed!

> s/using which is/which is

Thank you, I took this option, and have just published a new version.

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf