[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Captive-portals] FW: [TLS] FW: New Version Notification for draft-zhou-tls-server-redirect-00.txt



On 10/20/15 6:14 PM, Zhouqian (Cathy) wrote:
> Dear all, I submitted a new document on https applications to TLS
> working group. And Benjamin Kaduk from the TLS wg thinks the work may
> be in the scope of capport. What do you think?

In general I would view a signal from a middle box that it is attempting
hijack an outstanding but unfulfilled tls connection attempt as a direct
attack on my attempt a secure communication.

I think the observation by Ben is correct, in the sense that the purpose
of capport as proposed is to render such attempts unnecessary, at least
in the cast of signalling the existence  of captive portals that need to
be addressed before communication should continue.

thanks
joel

> Best Regards, Cathy
> 
> 
>> -----Original Message----- From: Benjamin Kaduk
>> [mailto:[email protected]] Sent: Tuesday, October 20, 2015 11:34
>> PM To: Zhouqian (Cathy); [email protected] Subject: Re: [TLS] FW: New
>> Version Notification for draft-zhou-tls-server-redirect-00.txt
>> 
>> On 10/20/2015 01:38 AM, Zhouqian (Cathy) wrote:
>>> Dear all, This is a new document we have submitted on the TLS
>>> extension for server
>> redirect. It aims to solve the problems in some applications, e.g.,
>> HTTPS redirect.
>>> The "Hello Extensions" message is extended and a new TLS
>>> handshake packet
>> is defined to support this kind of applications.
>>> Your comments are welcome.
>>> 
>> 
>> I am not sure I understand the "overdue" use case, but the "web 
>> authentication" use case sounds like an ordinary captive portal;
>> there's a proposed "capport" working group exclusively for handling
>> captive portals (https://datatracker.ietf.org/wg/capport/) which
>> might be worth visiting.  The "overdue" use case might also be
>> considered a captive portal, but I can't quite tell given the
>> current description.
>> 
>> In any case, it is far from clear that HTTP-specific issues should
>> be handled at the TLS layer -- TLS is a generic secure channel
>> protocol used in many applications other than HTTPS.
>> 
>> -Ben Kaduk
> 
> _______________________________________________ Captive-portals
> mailing list [email protected] 
> https://www.ietf.org/mailman/listinfo/captive-portals
> 


Attachment: signature.asc
Description: OpenPGP digital signature