Subject: Re: [Captive-portals] Ben Campbell's Yes on charter-ietf-capport-00-01: (with COMMENT)

From: Warren Kumari <[email-masked]>
Date: Thu, 15 Oct 2015 10:45:03 -0400

On Wed, Oct 14, 2015 at 6:37 PM, Ben Campbell <[email-masked]> wrote:
> Ben Campbell has entered the following ballot position for
> charter-ietf-capport-00-01: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-capport/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I agree with Spencer's comment about MiTM attacks.

Weirdly I don't see Spencer's comments in my mail, but I do see them
in the datatracker...
Anyway, sure, I'm happy to change this to "these interceptions are
indistinguishable from man-in-the-middle attacks"... The original
(clumsy) wording was an attempt to not annoy the CP vendors -- one
that that I think it very important to this work is to get
participation from CP vendors / implementors and operators -- I didn't
want the charter to say that what they do is a MitM, because that's
pejorative, but Spencer's "indistinguishable from" works nicely.

Responding to Spencer (I've missing his mail) -- "As endpoints become
inherently more secure" means a bunch of things, including: HSTS /
refusal to downgrade TLS, refusal (or inability) to click through
self-signed certs, client side DNSSEC, DPRIVE (ha!), VPNs, statically
configured web proxies, etc. I had a number of them listed in an
earlier version, but that turned into a: a fight about which are
better, and b: "you forgot $pet_security_mechanism".

Agree that "These might or might not be published as RFCs, and might
or might not be combined in some way." is cleaner.

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

---

From: Warren Kumari <[email-masked]>
Date: Thu, 15 Oct 2015 10:58:04 -0400

On Thu, Oct 15, 2015 at 10:51 AM, Ben Campbell <[email-masked]> wrote:
> On 15 Oct 2015, at 9:45, Warren Kumari wrote:
>
> Not speaking for Spencer, but if there's a good reason for the existing
> text, I can live with it. (But I'm also okay with "Indistinguishable
> from..."
>

The "indistinguishable from" works nicely -- it doesn't say that CP
interception *is* a MitM attack, and so should not offend.
I did not want to / was not able to edit the charter text directly, so
here is a version that folk can look at that has received comments
integrated:  https://gist.github.com/wkumari/3754605d53fc050591d1

W
> Thanks!
> Ben.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 15 Oct 2015 13:10:12 -0400

> integrated:  https://gist.github.com/wkumari/3754605d53fc050591d1

OK, I've put the version I just picked up from the git into the
datatracker (after checking it and doing some reformatting).

I think we're ready to go on this, and if we have other edits we can
do them during the external review period.

Barry

---

From: Hirotaka Nakajima <[email-masked]>
Date: Fri, 16 Oct 2015 08:42:26 +0900

Hi

Sorry just a typo correction and maybe too late for the comments but
eduroam should not be eduRoam but eduroam.

It would be great if this typo could be fixed.

Hiro

Sent from my iPhone

On Oct 16, 2015, at 2:10 AM, Barry Leiba <[email-masked]> wrote:

> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals

---

From: Barry Leiba <[email-masked]>
Date: Thu, 15 Oct 2015 22:04:07 -0400

> It would be great if this typo could be fixed.

And so it is.
Thanks for pointing it out.

Barry

---

From: John Mann <[email-masked]>
Date: Fri, 16 Oct 2015 14:20:21 +1100

Hi,

On a slight tangent, I would like to mention that most client computers are
now capable of using IPv6,
with many preferring it because e.g. Facebook reportedly loads 15% faster.

Hopefully, sometime, some networks managed by Captive Portals will become
dual-stack.

Lets not set the standard for all future captive portal networks to be
IPv4-only forever.
Hopefully, it may even be possible for clients to operate IPv6-only if they
choose.

Suggested text:
insert after "- allow endpoints to learn about the parameters of their
confinement,"
---
- allow endpoints to learn about and interact with the Captive Portal over
IPv6,
  and allow endpoints to access the IPv6 Internet,
---

Thanks,
    John