On 10/20/15 8:19 PM, Zhouqian (Cathy) wrote: > Hi Joel, > Thanks. So should this work be done in capport? If the question is, "Is a proposal to facilitate the interception of ssl connection attempts (enabling a man in the middle attack) by intermediate parties appropriate work for captive portals to undertake?" My personal opinion is no. > 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 >>> >> > >
Attachment:
signature.asc
Description: OpenPGP digital signature