Re: TLS 1.3 and Captive Portals

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