W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2015

Re: TLS 1.3 and Captive Portals

From: Hodges, Jeff <jeff.hodges@paypal.com>
Date: Thu, 3 Dec 2015 16:40:46 +0000
To: Craig Francis <craig@craigfrancis.co.uk>
CC: "public-webappsec@w3.org" <public-webappsec@w3.org>, security-dev <security-dev@chromium.org>
Message-ID: <D285AC98.492F0%jehodges@paypalcorp.com>
On 12/3/15, 8:19 AM, "Craig Francis" <craig@craigfrancis.co.uk> wrote:


>Not sure where the discussion is happening with TLS 1.3

<tls@ietf.org>

https://www.ietf.org/mailman/listinfo/tls



>When someone first connects to a captive portal

there is a nascent IETF captive portal WG (capport)..


capport: Captive Portals WG
*  capport wg is close to being chartered, ought to be accomplished before
IETF-95:

https://datatracker.ietf.org/wg/capport/charter/


*  this relevant non-WG foundational I-D is already near-RFC..

Captive-Portal Identification in DHCP / RA
https://datatracker.ietf.org/doc/draft-wkumari-dhc-capport/

The authors note that this draft is "not a complete solution..", thus
implying the need for chartering the capport WG in order to further
specify whatever it is that is missing.


hth,


=JeffH



>(e.g. hotel WiFi), they typically redirect any requests to a
>login/terms/payment page.
>
>If that redirect is done for a HTTPS connection, then the browser
>will/should complain (bad certificate).
>
>Would it be possible for the TLS 1.3 handshake to support this situation?
>
>So maybe the browser gets a response which does not attempt to give a
>certificate, but is simply a URL to redirect the user to.
>
>Then the browser can show a nice and friendly error message, and a link
>for the user to load (if they want to).
Received on Thursday, 3 December 2015 16:41:19 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:16 UTC