[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
Thanks. So should this work be done in capport?
> -----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
> 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.
> > 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