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

From: "Zhouqian (Cathy)" <[email-masked]>
Date: Tue, 20 Oct 2015 06:38:48 +0000

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.

Best Regards,
Cathy Zhou

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, October 19, 2015 5:25 PM
> To: Gaohongliang; Gaohongliang; Zhouqian (Cathy); Zhouqian (Cathy)
> Subject: New Version Notification for draft-zhou-tls-server-redirect-00.txt
> 
> 
> A new version of I-D, draft-zhou-tls-server-redirect-00.txt
> has been successfully submitted by Cathy Zhou and posted to the IETF
> repository.
> 
> Name:		draft-zhou-tls-server-redirect
> Revision:	00
> Title:		The Transport Layer Security (TLS) Extension to Support Server
> Redirect
> Document date:	2015-10-19
> Group:		Individual Submission
> Pages:		6
> URL:
> https://www.ietf.org/internet-drafts/draft-zhou-tls-server-redirect-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-zhou-tls-server-redirect/
> Htmlized:       https://tools.ietf.org/html/draft-zhou-tls-server-redirect-00
> 
> 
> Abstract:
>    In some applications, e.g., Hypertext Transfer Protocol Secure
>    (HTTPS) visit, a client request needs to be redireted to the
>    operator's web server for authentication or overdue processing.  This
>    specification defines a new extension of TLS handshake protocol
>    [RFC5246] to transmit the redirect Uniform/Universal Resource Locator
>    (URL) for HTTPS applications.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 20 Oct 2015 10:34:14 -0500

> 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

---

From: "Zhouqian (Cathy)" <[email-masked]>
Date: Wed, 21 Oct 2015 03:02:49 +0000

Hi Benjamin,
Thank you for your comments. Please see inline.

Best Regards,
Cathy

> From: Benjamin Kaduk [mailto:[email-masked]]
> Sent: Tuesday, October 20, 2015 11:34 PM
> To: Zhouqian (Cathy); [email-masked]
> Subject: Re: [TLS] FW: New Version Notification for
> draft-zhou-tls-server-redirect-00.txt
> 
> > 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.
> 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.
[Cathy]Yes, both web authentication and overdue use cases could be considered as captive portals. 
And I have already sent an email to the capport mailing list for their comments.

> 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.
[Cathy] As defined in [RFC 5246], "application protocol
      An application protocol is a protocol that normally layers
      directly on top of the transport layer (e.g., TCP/IP).  Examples
      include HTTP, TELNET, FTP, and SMTP.",
the TLS protocol could be used for HTTP applications.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 21 Oct 2015 11:13:09 -0500

On 10/20/2015 10:02 PM, Zhouqian (Cathy) wrote:
> [Cathy]Yes, both web authentication and overdue use cases could be
> considered as captive portals. And I have already sent an email to the
> capport mailing list for their comments. 

I mentioned capport because it sounds like they are trying to solve the
same sort of problem that your solution is trying to solve, not because
I think your proposal will be well-received there.  I agree with Warren
and Joel that directly intercepting TLS connections is not something I
want to support.

> the TLS protocol could be used for HTTP applications.

I don't think that's quite the point I was trying to make.  HTTPS is
HTTP layered on top of TLS, yes, but in order for there to be a
separation of layers, TLS should not include any data structures that
are only useful for the HTTPS case.  This document seems to add a field
to TLS that is only used in the HTTPS use case, which seems like a
layering violation to me.

-Ben

---

From: Melinda Shore <[email-masked]>
Date: Wed, 21 Oct 2015 09:06:16 -0800

> layering violation to me.

In fairness you can express all sorts of endpoint addresses
as URLs, not just http.  That said I agree that this is not
an attractive proposal - the performance improvement over
existing redirect models is marginal, there may be some
unpleasant middlebox interactions, and it would require
API changes.  The cost/benefit tradeoff isn't favorable,
on balance.

Melinda

-- 
Melinda Shore
No Mountain Software
[email-masked]

"Software longa, hardware brevis."

---

From: "Short, Todd" <[email-masked]>
Date: Wed, 21 Oct 2015 18:03:18 +0000

I agree with Ben here. This is very much application-layer (HTTPS) functionality being pushed down into the security (TLS) layer. HTTP(S) already has a fully functional redirect mechanism, why does this functionality need to be pushed to a lower layer? All the cases described in the Introduction can be handled at layers independent of TLS

In section 4: “...and after receiving the Get packet, the client responds with the…” I believe that “client” should be replaced with “server”.

Section “5. Security Considerations” is completely blank.

From the description it is not clear how much of the handshake completes before handling the Redirect. It implies that the Redirect may be acted upon (“fault warning page") before the handshake completes, and thus it is not secure. A MITM could easily inject the Redirect packet that impacts the client, preventing access.

But that is “sorta” the point, a captive portal, acting as a MITM, needs to authenticate the user, potentially at any time. This may be going off on a tangent, but if the captive portal accepted an HTTPS connection destined for anywhere, and if it could announce back to the client that I am your captive portal, and the client could verify that, then there would be no need for a TLS-level redirect. A browser should be able to handle this by querying for the router (i.e. captive portal) IP address/DNS name, and comparing that to the received TLS  server credentials. If they match, the client program knows it’s talking to a captive portal. I could go into more detail, but it outside the scope of this draft.

--
-Todd Short
// [email-masked]<mailto:[email-masked]>
// "One if by land, two if by sea, three if by the Internet."

On Oct 21, 2015, at 12:13 PM, Benjamin Kaduk <[email-masked]<mailto:[email-masked]>> wrote:

-Ben

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: Hanno Böck <[email-masked]>
Date: Wed, 21 Oct 2015 20:22:59 +0200

Not sure if I'm getting anything wrong, but doesn't this open a huge
security hole?

Scenario right now is that if I want to be secure on a webpage I type
in its HTTPS URL (either directly or through a bookmark) and can be
pretty much sure that as long as I don't click on external links that
I'll stay on that webpage.

Basically this proposal would allow a man-in-the-middle to send
me to another webpage each time I click on a (supposedly https
protected) link. Given that there are many browsers these days
(mobile) that hide the URL bar thats even more severe.

This severely changes the security expectations one can have from a
browser.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: [email-masked]
GPG: BBB51E42

---

From: Yoav Nir <[email-masked]>
Date: Wed, 21 Oct 2015 22:03:47 +0300

> On 21 Oct 2015, at 9:03 PM, Short, Todd <[email-masked]> wrote:
> 
> I agree with Ben here. This is very much application-layer (HTTPS) functionality being pushed down into the security (TLS) layer.

In fairness, if the TLS layer is blocking you, you don’t get to talk to the HTTP layer. So the captive portal intercept case has to be solved at the TLS layer or lower still.

Yoav

---

From: Roland Zink <[email-masked]>
Date: Thu, 22 Oct 2015 10:20:10 +0200

> Not sure if I'm getting anything wrong, but doesn't this open a huge
Yes I think so. Mitm may redirect you.
> I'll stay on that webpage.
No the server may redirect you and even worse the parts may be retrieved 
from dozens of places and you have no clue from where. Common practice 
is that your privacy is sold to third parties through ads, analytics, 
like or pin buttons. This is not what I would expect from a secure site.
> This severely changes the security expectations one can have from a
Regards,
Roland
> [email-masked]