Subject: Gen-ART and OPS-Dir review of draft-wkumari-dhc-capport-13

From: "Black, David" <[email-masked]>
Date: Sun, 5 Jul 2015 14:36:35 +0000

This is a combined Gen-ART and OPS-Dir review.  Boilerplate for both follows ...

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at:

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These comments
were written primarily for the benefit of the operational area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.

Document: draft-wkumari-dhc-capport-13
Reviewer: David Black
Review Date: July 5, 2015
IETF LC End Date: July 7, 2015

Summary:  This draft is on the right track, but has open issues
 		described in the review.

This draft specifies DHCP (v4 and v6) and IPv6 RA options to provide the
contact URI of a captive portal (e.g., for a WiFi hotspot).  It's a
short draft that gets the job done - I found a few minor issues, and
have an additional security consideration to suggest.

Major issues: None

Minor issues:

[1] Section 2:

   captive portals will still need to implement the
   interception techniques to serve legacy clients, and clients will
   need to perform probing to detect captive portals.

Please explain what "the interception techniques" and "probing" are.
I think this material was in -12 and removed for -13 - it does not need
to be restored in its entirety, but those two terms deserve some
explanation.  This should also explain "DNS interception" in the last
paragraph in the section.

[2] Section 2.1 - DHCPv4 has the shortest URI length limit, 255 bytes.
That should be noted either here or in Section 2 in discussion of serving
multiple classes of clients.  This should not be a problem in practice.

[3] Sections 2.1, 2.2, 3: The term "URI of the authentication page" should
be changed to something like "contact URI for the captive portal" because
authentication is not always required by a captive portal.

[4] Section 4: The IANA Considerations section is incomplete - see IANA's
review.

[5] Section 5:

   Fake
   DHCP servers / fake RAs are currently a security concern - this
   doesn't make them any better or worse.

Please cite a reference for this, preferably with operational recommendations
on limiting these problems (e.g., ensure that DHCP and RA traffic cannot be
injected from outside/beyond the network that is relevant to the portal).

   Redirection to a portal where TLS can be used
   without hijacking can ameliorate some of the implications of
   connecting to a potentially malicious captive portal.

Please explain who or what does the redirection and what is redirected
(browser, VPN client?).  Is this a suggestion to use http:// URLs? (if
so, that should be said explicitly).

Nits/editorial comments:

p.3, first sentence:

   This document describe a DHCP ([RFC2131]) option (Captive Portal) and

s/describe/describes

I would add a sentence to section 2 to say that URI strings are not
null-terminated.

Section 3 - this should be renumbered to 2.3, as the overview text in
Section 2 applies to the RA option.

Possible additional security consideration:

Captive portals are increasingly hijacking TLS connections to force
browsers to talk to the portal.  Providing the portal's URI via a DHCP
or RA option is a cleaner technique, and reduces user expectations of
being hijacked - this may improve security by making users more reluctant
to accept TLS hijacking, which can be performed from beyond the network
associated with the captive portal.

--- Selected RFC 5706 Appendix A Q&A for OPS-Dir review ---

Most of these questions reduce to the corresponding questions for DHCP
or IPv6 RAs.  Once the portal is contacted, there are significant
operational considerations that are well outside the scope of this
draft.

A.1.3  Has the migration path been discussed?

	Yes, briefly.  Minor issue [1] requests more information on
	existing techniques, with which coexistence is anticipated.

A.3.  Documentation

	An operational considerations or manageability section isn't
	called for.  I do not expect the options in this draft to
	have significant operational impact.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: joel jaeggli <[email-masked]>
Date: Sat, 11 Jul 2015 08:50:08 -0700

Thank you David.

---

From: Christian Huitema <[email-masked]>
Date: Sat, 11 Jul 2015 21:28:31 +0000

On Saturday, July 11, 2015 1:13 PM, Warren Kumari [mailto:[email-masked]] wrote
> On Saturday, July 11, 2015, Christian Huitema <[email-masked]> wrote:
>
>> There is definitely an attack vector there. Suppose an attacker can monitor the traffic, say on an 
>> unencrypted Wi-Fi hot spot. The attacker can see a DHCP request or INFORM, and race in a fake 
>> response with an >> URL of their own choosing. The mark's computer automatically connects 
>> there, and download some zero-day attack. Bingo!
>
> An attacker with this level of access can already do this. They fake a DHCP response with themselves 
> as the gateway and insert a 302 into any http connection. Or, more likely they simply inject 
> malicious code into some connection. 
>
> Connecting to unknown/ unencrypted networks is inherently dangerous...

OK, you are probably correct that this is just one of the many attacks possible when connecting to insecure networks. Then, of course, there is the whole idea of letting an untrusted DHCP server direct one's browser to an arbitrary web page. Looks like an ideal setup for zero days and phishing tools. Ideally, we should only process the redirected page into a fairly tight sandbox...

-- Christian Huitema

---

From: Randy Bush <[email-masked]>
Date: Sat, 11 Jul 2015 15:55:40 -0700

> OK, you are probably correct that this is just one of the many attacks
> possible when connecting to insecure networks. Then, of course, there
> is the whole idea of letting an untrusted DHCP server direct one's
> browser to an arbitrary web page. Looks like an ideal setup for zero
> days and phishing tools. Ideally, we should only process the
> redirected page into a fairly tight sandbox...

user walks into a coffee-shop and asks for a DHCP-request.  gets hit by
Mallet.  ietf puts head in sand.

randy

---

From: Ted Lemon <[email-masked]>
Date: Sun, 12 Jul 2015 14:37:34 -0400

> OK, you are probably correct that this is just one of the many attacks possible when connecting to insecure networks. Then, of course, there is the whole idea of letting an untrusted DHCP server di…

This is just one example of the "everything is broken" problem.   In 
point of fact, if you can inject packets on the local wire and sniff 
packets off of the local wire, you can easily send malware to the host 
simply by providing it with mostly correct information, and then once 
the hotspot detector has been bypassed, hack the next http query that 
goes by, stuffing your malware, or instructions to fetch your malware, 
into the HTML.

---

From: Christian Huitema <[email-masked]>
Date: Sun, 12 Jul 2015 18:59:55 +0000

On Sunday, July 12, 2015 11:38 AM, Ted Lemon wrote:
>> OK, you are probably correct that this is just one of the many attacks possible when 
>> connecting to insecure networks. Then, of course, there is the whole idea of letting an untrusted 
>> DHCP server direct one's browser to an arbitrary web page. Looks like an ideal setup for zero 
>> days and phishing tools. Ideally, we should only process the redirected page into a fairly tight sandbox...
>
> point of fact, if you can inject packets on the local wire and sniff packets off of the local wire, you can easily 
> send malware to the host simply by providing it with mostly correct information, and then once the hotspot 
> detector has been bypassed, hack the next http query that goes by, stuffing your malware, or instructions 
> to fetch your malware, into the HTML.

Except that local attackers cannot do that if the host is programmed to only query using HTTPS, or if the host sends all its traffic through a VPN. The "web capture" hack is special, because it forces the host to read a web page programmed by the untrusted local admin. As such, it opens a vulnerability window. My point is that the draft should recognize that window, and the three attack vectors: malicious hot spot admin, DHCP response spoofing, and in the case of clear text network packet injection in the capture portal web page.

My advice to implementers would be to consider the capture portal web page as fundamentally untrusted, and for example not allow it to run scripts. Then system administrators could consider "white listing" some of these pages, provided of course that the connection could be authenticated and protected through HTTPS.

-- Christian Huitema

---

From: Ted Lemon <[email-masked]>
Date: Sun, 12 Jul 2015 15:59:12 -0500

> My advice to implementers would be to consider the capture portal web page as fundamentally untrusted, and for example not allow it to run scripts. Then system administrators could consider "white…
This is good advice.   If it's not specifically stated, I suspect it's 
because the authors thought it was obvious (I haven't read the draft in 
about two months, so I don't remember what it says about this).

That said, the reality is that most hosts are not configured as you 
suggest, and configuring them that way would substantially reduce their 
usability.   To expand this document to the point where it covers all 
the advice that should be given to implementers of such systems would be 
challenging, to say the least.

E.g., you suggest using https, but that's not really adequate: https is 
safer than it otherwise would be because e.g. Google and other browser 
vendors have blacklists that prevent you from going to known bad web 
sites.  These blacklists are (I assume, I haven't checked) updated by 
the browser.   So should the host software vendor fail if the blacklist 
can't be updated?

Should the captive portal allow downloading of such updates?   I would 
say yes to both questions, but we have no control at all over either 
captive portal vendors or host vendors, and in the case of captive 
portal vendors, the state of the art is atrocious: a typical captive 
portal that I've had to interact with a lot recently uses https, but 
uses an invalid cert!

Not running scripts is a great suggestion, but we know that many hosts 
are vulnerable to SSL hacks.   So there's always going to be some 
exposure here.   A lot of what host software vendors ought to be doing 
to protect hosts from problems of this sort are so far out of scope of 
this document that it seems pointless to discuss them. If in fact we 
want to offer advice of this sort, I think it ought to be in a separate 
document, done by a working group with participants who are qualified to 
give such advice, if such a working group exists.

---

From: Christian Huitema <[email-masked]>
Date: Sat, 11 Jul 2015 18:28:33 +0000

On Saturday, July 11, 2015 8:50 AM, joel jaeggli wrote

> ...
> Please cite a reference for this, preferably with operational 
> recommendations on limiting these problems (e.g., ensure that DHCP and 
> RA traffic cannot be injected from outside/beyond the network that is relevant to the portal).

There is definitely an attack vector there. Suppose an attacker can monitor the traffic, say on an unencrypted Wi-Fi hot spot. The attacker can see a DHCP request or INFORM, and race in a fake response with an URL of their own choosing. The mark's computer automatically connects there, and download some zero-day attack. Bingo!
 
 -- Christian Huitema

---

From: Warren Kumari <[email-masked]>
Date: Sat, 11 Jul 2015 16:13:28 -0400

On Saturday, July 11, 2015, Christian Huitema <[email-masked]> wrote:

> There is definitely an attack vector there. Suppose an attacker can
> monitor the traffic, say on an unencrypted Wi-Fi hot spot. The attacker can
> see a DHCP request or INFORM, and race in a fake response with an URL of
> their own choosing. The mark's computer automatically connects there, and
> download some zero-day attack. Bingo!
>
>
An attacker with this level of access can already do this. They fake a DHCP
response with themselves as the gateway and insert a 302 into any http
connection. Or, more likely they simply inject malicious code into some
connection.

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

---

From: Sam Hartman <[email-masked]>
Date: Mon, 13 Jul 2015 13:08:13 -0400

>>>>> "Ted" == Ted Lemon <[email-masked]> writes:

    Ted> On 07/12/2015 01:59 PM, Christian Huitema wrote:
    >> My advice to implementers would be to consider the capture portal
    >> web page as fundamentally untrusted, and for example not allow it
    >> to run scripts. Then system administrators could consider "white
    >> listing" some of these pages, provided of course that the
    >> connection could be authenticated and protected through HTTPS.
    Ted> This is good advice.  If it's not specifically stated, I
    Ted> suspect it's because the authors thought it was obvious (I
    Ted> haven't read the draft in about two months, so I don't remember
    Ted> what it says about this).

My concern about this advice is that no one will implement it because it
will break portals.  Modern web pages use scripts for a lot of things.
If I were writing such a portal, I'd almost certainly use scripts for
some things and probably if I were writing it as a new app use a
client-side framework like angular where the entire thing was one
script.
So, it's great security advice, but entirely impractical.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Jul 2015 10:17:37 -0700

> So, it's great security advice, but entirely impractical.
I don't think it's that impractical to write your web page so that it 
works with or without javascript, and this is a clear case where it 
makes a lot of sense to do so.   So giving the advice makes sense.   
Whether anybody will follow it I don know.   One of these days I'm sure 
we'll start to see web browser vendors disabling Flash by default...

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Jul 2015 10:25:47 -0700

Thinking about this a bit more, it seems to me that the advice that 
should be followed in the case of a captive portal is this:

- You must make it possible to resolve any names required to register 
using DNSSEC, whether you support DNSSEC or not.
- You should support DNSSEC
- You must make it possible to do all appropriate validation for any SSL 
certs that are required to validate the connection to the portal.
- You must use SSL for the portal, and you must use validate-able certs.

My concern is that while this is really good advice, there's no real 
incentive in place to get the captive portal vendors to implement this 
nor to get the captive portal providers to require it or set it up 
correctly.   There is some small cost to supporting broken portals, but 
by and large laying this cost off on the end user works.

Similarly, as you say, the host software provider has no incentive to 
require this functionality: for the most part, it simply makes life 
difficult for the end user.   At present, Google is actually pretty good 
about this; the result is that it's hard to use Google devices on 
networks with broken captive portals, which are of course endemic.   
Google seems not to have paid a price for this thus far, but I don't see 
other vendors doing what Google is doing.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 13 Jul 2015 17:34:59 +0000

> Similarly, as you say, the host software provider has no incentive to require this
> functionality: for the most part, it simply makes life
> Google seems not to have paid a price for this thus far, but I don't see other
> vendors doing what Google is doing.

It may well be one of these cases where we should disregard Jon Postel's advice and NOT be tolerant with what we receive. Not being tolerant is a known way to force change. Suppose that a critical fraction of devices refuses to use broken portals, fail, call the help desk, etc. That will certainly create pressure on portal vendors to fix the broken pages. And having the advice in the RFC will provide cover to device vendors.

-- Christian Huitema

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Jul 2015 10:39:30 -0700

> It may well be one of these cases where we should disregard Jon Postel's advice and NOT be tolerant with what we receive. Not being tolerant is a known way to force change. Suppose that a critical…
Absolutely.   This would be a very nice feature to see in Windows 10.  ;)

---

From: Sam Hartman <[email-masked]>
Date: Mon, 13 Jul 2015 13:58:15 -0400

Ted> On 07/13/2015 10:08 AM, Sam Hartman wrote:
    >> My concern about this advice is that no one will implement it
    >> because it will break portals.  Modern web pages use scripts for
    >> a lot of things.  If I were writing such a portal, I'd almost
    >> certainly use scripts for some things and probably if I were
    >> writing it as a new app use a client-side framework like angular
    >> where the entire thing was one script.  So, it's great security
    >> advice, but entirely impractical.
    Ted> I don't think it's that impractical to write your web page so
    Ted> that it works with or without javascript, and this is a clear
    Ted> case where it makes a lot of sense to do so.  

Speaking as someone who manages web development projects and web
authentication software projects.  Increasingly, writing an application
to work without javascript doubles the software development costs and
reduces the quality of the user experience.
(You choosing to use the term web page begins to chart the boundaries of
the chasm across which we're failing to speak.)

In addition, if you want any sort of security beyond usernames and
passwords, you're probably going to want to use javascript.  That's
right; there is a tradeoff between better authentication technology and
dependence of your sandboxing technology.

I agree with your advice about certs and cert validation.
I think it would be desirable in addition to suggest that servers for
these portals staple OCSP responses to their certs.  That's something
people actually could implement and that software would sometimes take
advantage of if they did.

Since no browsers support DANE, I don't think it's fair to give an
operational recommendation in favor of DNSsec.  I don't think it buys
you anything with today's software.
We could say something like the combination of DANEsupport in the
browsers   and DNssec/TLSA records would provide a good way to establish
trust in websites in this situation.  It's true at least.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Jul 2015 11:26:45 -0700

> you anything with today's software.
What I had in mind with this is not so much DANE but rather just being 
able to make the claim that the answer  (e.g., AAAA record) being 
returned to the host is actually a name owned by the company claiming to 
operate the captive portal.   I will admit that I haven't really thought 
this through, and you are right that one of the more obvious use cases 
for this would be validating the cert using TLSA.   Of course if the 
portal doesn't support the TLSA queries, that means that the host can't 
require that they work, which seems like a bad outcome, so recommending 
support for DNSSEC is a win even if the hosts don't initially use it.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 13 Jul 2015 14:36:18 -0400

Ted> On 07/13/2015 10:58 AM, Sam Hartman wrote:
    >> Since no browsers support DANE, I don't think it's fair to give
    >> an operational recommendation in favor of DNSsec.  I don't think
    >> it buys you anything with today's software.
    Ted> What I had in mind with this is not so much DANE but rather
    Ted> just being able to make the claim that the answer (e.g., AAAA
    Ted> record) being returned to the host is actually a name owned by
    Ted> the company claiming to operate the captive portal.  I will
    Ted> admit that I haven't really thought this through, and you are
    Ted> right that one of the more obvious use cases for this would be
    Ted> validating the cert using TLSA.  Of course if the portal
    Ted> doesn't support the TLSA queries, that means that the host
    Ted> can't require that they work, which seems like a bad outcome,
    Ted> so recommending support for DNSSEC is a win even if the hosts
    Ted> don't initially use it.

I have never been convinced that DNSsec validation of A or AAAA records
has value.
I understand I am a heretic in the security community for saying that,
but there it is.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Jul 2015 11:38:30 -0700

> I understand I am a heretic in the security community for saying that,
It's one more hurdle an attacker has to leap.   You are right that it's 
not a huge win, but it seems to do more to reduce than increase the 
attack surface.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 13 Jul 2015 18:46:54 +0000

On Mon, Jul 13, 2015 at 02:36:18PM -0400, Sam Hartman wrote:

> has value.  I understand I am a heretic in the security community for
> saying that, but there it is.

I'm inclined to agree that the value is marginal.

In the DANE SMTP draft, validation of A/AAAA records is used only
as a "probe" to detect unsigned zones, so that one can avoid sending
TLSA queries to such zones (where misconfigured firewalls or buggy
nameservers are prone to mishandle all but the most common DNS
RRtypes).  The validation status of address records is otherwise
ignored.

Forging IP address records in DNS is rather tamper-evident.  It is
far more attractive to attack BGP, and MiTM or just monitor the
traffic transparently.

-- 
	Viktor.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 13 Jul 2015 19:11:30 +0000

On  Monday, July 13, 2015 11:47 AM, Viktor Dukhovni wrote 
> > I have never been convinced that DNSsec validation of A or AAAA
> > records has value.  I understand I am a heretic in the security
> > community for saying that, but there it is.
> 
> Forging IP address records in DNS is rather tamper-evident.  It is far more
> attractive to attack BGP, and MiTM or just monitor the traffic transparently.

Consider the use case. The hot spot controls the default router, and often implements a NAT. They can decide to terminate the A or AAAA address wherever they please. The value of ensuring proper name to address resolution is indeed marginal.

-- Christian Huitema

---

From: David Farmer <[email-masked]>
Date: Tue, 14 Jul 2015 14:24:04 -0500

> - You must use SSL for the portal, and you must use validate-able certs.

In many cases I'm fine with these requirements, especially in the case 
where the purpose of the portal is authentication or some other user 
registration information is exchanged like an email address or a phone 
number.  Obviously, that kind of personal information must be protected.

However, what if the only purpose of the portal is to display marketing 
and/or acceptance of Term & Conditions?  Is DNSSEC and SSL still 
required in this case?  I tend to think not, but I'm happy to hear why 
I'm wrong.

Frequently that is all the captive portal is, a little marketing and 
maybe T's & C's to keep the lawyers happy.  For most coffee shops or 
restaurants and a lot of other public places this all the portal does.

> by and large laying this cost off on the end user works.

If we start by acknowledging the existence of business reasons for 
captive portals then maybe people will listen, but if all we tell them 
is that is a stupid idea, I'm sorry but why would/should they listen to 
us.

> other vendors doing what Google is doing.

Google in particular is on all sides of this problem, they make a 
browser, they make an Client OS, and they are becoming a provider and/or 
sponsor of connectivity is places.  I have some hope we can make things 
better in this realm.

Thanks.

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Jul 2015 13:00:32 -0700

On 07/14/2015 12:24 PM, David Farmer wrote:
> However, what if the only purpose of the portal is to display 
> marketing and/or acceptance of Term & Conditions?  Is DNSSEC and SSL 
> still required in this case?  I tend to think not, but I'm happy to 
> hear why I'm wrong.
>

The issue is that we want to avoid being infected by malware, and if the 
captive portal controls all of our access to the information we'd use to 
avoid connecting to an untrustworthy source, we are in trouble.   
Chances are that your marketing splash is some kind of flash or 
javascript thing, and we'd like to be able to know that we are really 
talking to you and that you aren't on a malware blacklist.   DNSSEC and 
TLS (not SSL, all versions of SSL are known to be vulnerable to hacks of 
various kinds) are required to make this work.
> is that is a stupid idea, I'm sorry but why would/should they listen 
> to us. 
I think by writing this draft, Warren is acknowledging that there is a 
business case for captive portals, and by not rejecting the advancement 
of the document, the IETF would be agreeing.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 14 Jul 2015 16:18:29 -0400

Ted> On 07/14/2015 12:24 PM, David Farmer wrote:
    >> marketing and/or acceptance of Term & Conditions?  Is DNSSEC and
    >> SSL still required in this case?  I tend to think not, but I'm
    >> happy to hear why I'm wrong.
    >> 
    >> Frequently that is all the captive portal is, a little marketing
    >> and maybe T's & C's to keep the lawyers happy.  For most coffee
    >> shops or restaurants and a lot of other public places this all
    >> the portal does.

    Ted> The issue is that we want to avoid being infected by malware,
    Ted> and if the captive portal controls all of our access to the
    Ted> information we'd use to avoid connecting to an untrustworthy
    Ted> source, we are in trouble.  Chances are that your marketing
    Ted> splash is some kind of flash or javascript thing, and we'd like
    Ted> to be able to know that we are really talking to you and that
    Ted> you aren't on a malware blacklist.  DNSSEC and TLS (not SSL,
    Ted> all versions of SSL are known to be vulnerable to hacks of
    Ted> various kinds) are required to make this work.
    >>> My concern is that while this is really good advice, there's no

Just to make sure we're evaluating the tradeoffs here.  We're assuming
that the attacker doesn't choose to pay for a plausible domain and a
cert for that domain.  I think cheap certs are in the $10 range unless
they've gotten down to free, and domains are under $20.
I'd been thinking TLS was valuable if you were exchanging sensitive
information.
Is the economic disadvantage to the mallware attacker greater than I'm
implying above?

---

From: David Farmer <[email-masked]>
Date: Wed, 15 Jul 2015 00:43:39 -0500

On 7/14/15 15:00 , Ted Lemon wrote:
> avoid connecting to an untrustworthy source, we are in trouble. Chances
> are that your marketing splash is some kind of flash or javascript
> thing, and we'd like to be able to know that we are really talking to
> you and that you aren't on a malware blacklist.   DNSSEC and TLS (not
> SSL, all versions of SSL are known to be vulnerable to hacks of various
> kinds) are required to make this work.

OK fine TLS, but don't pick on me, Ted you said SSL in your list, I was 
just going off of that.

So to be clear your saying all captive portals even if they don't 
exchange information with users need to be TLS and DNSSEC verifiable? 
Correct me if I'm wrong, but I think that also means they need to be 
using public address too, not RFC 1918 or ULA.

Personally, happy to do that, especially with a DHCP or RA option like 
proposed.  Because of the stupid way many apps deal with the 
redirection, you need to redirect to a plain HTTP page first.  Otherwise 
TLS resources needed can be very massive in some situations, 100s or 
1000s of redirects per second aren't unheard of.  And, 100s or 1000s TLS 
session per second is not something your going to do on a typical 
wireless controller.

However, I'm not sure it really makes that much difference, it isn't 
what our captive portal does that will be your issue it's what be bad 
guy's captive portal does and there ain't much we can to about that. 
And I'm not sure how much TLS will really help there, as SAM points out 
domain names and certificates are that hard to come by, not really an 
excuse for the good guys to not do it, but its not going to fix the 
problem either.

The only thing we can really do is NOT have you use insecure open 
wireless by providing secure wireless options.  But, I'm some what 
depressed by the number of people who WANT to use insecure open wireless 
for many reasons, ease of use, anonymity, etc...

We provide secure options and are working on proving easy ways to have 
even visitors/guest use secure wireless.  But honestly, most people 
don't want to be bothered, I'm the bad guy tying to make their life 
harder, or I want to monitor their usage or something.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Jul 2015 10:00:21 -0700

On 07/14/2015 10:43 PM, David Farmer wrote:
> OK fine TLS, but don't pick on me, Ted you said SSL in your list, I 
> was just going off of that. 
Sorry, that was as much for my benefit as yours.   You are right that I 
tend to use the terms interchangeably, but the time has definitively 
arrived at which we need to stop doing that.

> And I'm not sure how much TLS will really help there, as SAM points 
> out domain names and certificates are that hard to come by, not really 
> an excuse for the good guys to not do it, but its not going to fix the 
> problem either.

The point of saying that captive portals have to support TLS and 
DNSSEC+DANE is to arrange it to be the case that only bad guys have 
unsecured portals.

> depressed by the number of people who WANT to use insecure open 
> wireless for many reasons, ease of use, anonymity, etc... 

The main reason they want to use them is because they work. Remember, 
secure != non-private.   The captive portal can collect information 
about the user, but it doesn't have to.   The main reason people use 
broken or non-secure captive portals is because it's so hard to make 
captive portals that are secure, so by and large captive portals simply 
are not secure.

For instance, suppose I want to sell a router that has a captive portal 
mode that can be enabled by the end user.   How do I make that work 
without requiring the end-user to buy a cert?   Right now the answer is 
that I don't, because no browser supports DANE certs.   How do I do 
secure password-less logins?   I don't, because there isn't a good and 
well-supported standard for doing that, even though we know how.

So part of what we should be doing to make Christian happy is to finish 
the specifications for these security technologies and see them deployed 
in browsers and servers.   There is no reason other than our failure to 
do this that it should be the case that I have to log in to my Wifi 
router using an unencrypted connection that reveals the username and 
password I use to authenticate, much less that captive portals should 
have to either not be secure, be secured with an expensive SSL 
certificate infrastructure, or be "secured" with a key that can't be 
validated.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 13 Jul 2015 11:44:42 -0400

>>>>> "Warren" == Warren Kumari <[email-masked]> writes:

    Warren>    On Saturday, July 11, 2015, Christian Huitema
    Warren> <[email-masked]>
    Warren>    wrote:

    Warren>      On Saturday, July 11, 2015 8:50 AM, joel jaeggli wrote
    >> ...  [5] Section 5:
    >> 
    >> Fake DHCP servers / fake RAs are currently a security concern -
    >> this doesn't make them any better or worse.
    >> 
    >> recommendations on limiting these problems (e.g., ensure that
    >> DHCP
    Warren>      and
    >> RA traffic cannot be injected from outside/beyond the network
    >> that
    Warren>      is relevant to the portal).  

>      There is definitely an
> attack vector there. Suppose an attacker can monitor the
> traffic, say on an unencrypted Wi-Fi hot spot. The attacker
> can see a DHCP request or INFORM, and race in a fake
> response with an URL of their own choosing. The mark's
> computer automatically connects there, and download some
> zero-day attack.  Bingo!

    Warren>    An attacker with this level of access can already do
    Warren> this. They fake a DHCP response with themselves as the
    Warren> gateway and insert a 302 into any http connection. Or, more
    Warren> likely they simply inject malicious code into some
    Warren> connection.

I'm with Christian.  The attack he describes--injecting a URI--is less
likely in my mind to be noticed than setting up a gateway.  So, I do
consider this a new vector.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 13 Jul 2015 17:59:02 +0200

Okey dokey, I'm happy to add something.

Does anyone have any suggested text?

W

On Monday, July 13, 2015, Sam Hartman <[email-masked]> wrote:

> >>>>> "Warren" == Warren Kumari <[email-masked] <javascript:;>> writes:
>
>     Warren> <[email-masked] <javascript:;>>
>     Warren>    wrote:
>