ietf
[Top] [All Lists]

Re: Gen-ART and OPS-Dir review of draft-wkumari-dhc-capport-15

2015-09-01 14:25:29
On Tue, Sep 1, 2015 at 2:22 PM, Black, David 
<david(_dot_)black(_at_)emc(_dot_)com> wrote:
The -16 version looks good, Thanks, --David


Thank you, and apologies again for missing them the first time.

W


-----Original Message-----
From: Warren Kumari [mailto:warren(_at_)kumari(_dot_)net]
Sent: Monday, August 31, 2015 12:07 PM
To: Black, David
Cc: olafur(_at_)cloudflare(_dot_)com; ebersman-ietf(_at_)dragon(_dot_)net; 
steve(_dot_)sheng(_at_)icann(_dot_)org;
General Area Review Team (gen-art(_at_)ietf(_dot_)org); 
ops-dir(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org;
dhcwg(_at_)ietf(_dot_)org
Subject: Re: Gen-ART and OPS-Dir review of draft-wkumari-dhc-capport-15

On Fri, Aug 28, 2015 at 6:05 PM, Black, David 
<david(_dot_)black(_at_)emc(_dot_)com> wrote:
The Gen-ART and OPS-Dir review of the -13 version of this draft does not
appear to have been directly addressed in the -15 version.

Of the 5 minor issues, other changes have addressed issue [4] and the
first part of issue [5] (first chunk of quoted text).  In addition, it's
ok to treat issue [1] as editorial.

That leaves minor issues [2], [3] and the second part of [5] (second chunk
of quoted text) as topics that still merit attention, and I would like the
authors to consider adding the suggested additional security consideration.


Apologies, David, no sure how we missed those. I think I got
sidetracked while trying to address the first part of [5] and never
came back to [2], [3].

[2]: I added (new text in '***' :
The captive portal operator should ensure that the URIs handed out are
equivalent to reduce the chance of operational problems. ***The
maximum length of the URI that can be carried in IPv4 DHCP is 255
byte, and so URIs longer than 255 bytes should not be used in IPv6
DHCP or IPv6 RA.***

I'm not in love with this text, but not sure how to make it better.
Implementers don't *have* to use the same URI in all protocols, and so
I guess they could decide to use longer than 255 octets in DHCPv6 if
they were sufficiently pathological.

[3]: Done. Thanks for providing text.


[5]:

"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."
This was a cut and paste from an email.
I'm rewording it to:
"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."


The original text was provided by Joel -- I'm assuming that the
rewording capture what he was attempting to say. David, does this
address your comment? And Joel, does it (still) convey what you were
saying?




Additional:

Thank you for the text - I added (to security considerations):
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.

Nits:
s/describe/describes/ - done (in earlier rev).

Mentioned that the URI is not null terminated.



Thanks,
--David

-----Original Message-----
From: Black, David
Sent: Sunday, July 05, 2015 10:37 AM
To: Warren Kumari; olafur(_at_)cloudflare(_dot_)com; 
ebersman-ietf(_at_)dragon(_dot_)net;
steve(_dot_)sheng(_at_)icann(_dot_)org; General Area Review Team 
(gen-art(_at_)ietf(_dot_)org); ops-
dir(_at_)ietf(_dot_)org
Cc: ietf(_at_)ietf(_dot_)org; dhcwg(_at_)ietf(_dot_)org; Black, David
Subject: Gen-ART and OPS-Dir review of draft-wkumari-dhc-capport-13

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
david(_dot_)black(_at_)emc(_dot_)com        Mobile: +1 (978) 394-7754
----------------------------------------------------




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



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

<Prev in Thread] Current Thread [Next in Thread>