Re: TLS 1.3 and Captive Portals

Great, thanks Jeff, really glad to hear that is already being considered (and embarrassing I didn't find these after a quick search).

And Richard, thanks for the quick reply as well.




> On 3 Dec 2015, at 16:40, Hodges, Jeff <jeff.hodges@paypal.com> wrote:
> 
> 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:49:58 UTC