Hi Joel, Thanks. So should this work be done in capport? Best Regards, Cathy
> -----Original Message----- > From: joel jaeggli [mailto:[email protected]] > Sent: Wednesday, October 21, 2015 10:13 AM > To: Zhouqian (Cathy); [email protected] > Subject: 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 > > > _______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
