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

["Black, David" <[e-mail]>]

The -16 version looks good, Thanks, --David

> -----Original Message-----
> From: Warren Kumari [mailto:[e-mail]]
> Sent: Monday, August 31, 2015 12:07 PM
> To: Black, David
> Cc: [e-mail]; [e-mail]; [e-mail];
> General Area Review Team ([e-mail]); [e-mail]; [e-mail];
> [e-mail]
> 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 <[e-mail]> 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; [e-mail]; [e-mail];
> >> [e-mail]; General Area Review Team ([e-mail]); ops-
> >> [e-mail]
> >> Cc: [e-mail]; [e-mail]; 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
> >> [phone]             FAX: [phone]
> >> [e-mail]        Mobile: [phone]
> >> ----------------------------------------------------
> >
> 
> 
> 
> --
> 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