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 // tsh...@akamai.com<mailto:tsh...@akamai.com> // "One if by land, two if by sea, three if by the Internet." On Oct 21, 2015, at 12:13 PM, Benjamin Kaduk <bka...@akamai.com<mailto:bka...@akamai.com>> wrote: 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. 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. 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 _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
