Re: [TLS] Layered TLS ... was Re: New Version Notification for draft-friel-tls-over-http-00.txt

[Hannes Tschofenig]

On 11/07/2017 01:20 PM, Salz, Rich wrote:
> 
> ➢ Our work was motivated by the discussions in the IoT groups about
> re-inventing the TLS handshake at the application layer.
> 
>  Isn’t that what QUIC does (to a good enough approximation)?
> 

I see QUIC more as a new transport layer.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Layered TLS ... was Re: New Version Notification for draft-friel-tls-over-http-00.txt

[Salz, Rich]

➢ Our work was motivated by the discussions in the IoT groups about
re-inventing the TLS handshake at the application layer.

 Isn’t that what QUIC does (to a good enough approximation)?

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Layered TLS ... was Re: New Version Notification for draft-friel-tls-over-http-00.txt

[Hannes Tschofenig]

This is interesting since Mark Baugher and myself have also been working
on the use of TLS at the application layer and we did some
implementation work with mbed TLS (with TLS 1.3) and OpenSSL.

Our work was motivated by the discussions in the IoT groups about
re-inventing the TLS handshake at the application layer.

Our document can be found here:
https://tools.ietf.org/html/draft-tschofenig-layered-tls-00

Ciao
Hannes

On 11/07/2017 10:21 AM, Alex C wrote:
> What exactly is the threat model here?
> 
> Are you trying to hide a connection from a reverse proxy at the server
> end? If so, the server operator should not have deployed a reverse proxy
> in the first place.
> 
> Are you trying to hide from a MITM proxy that supplies its own
> certificate? If so, then what prevents the proxy from doing the same to
> the tunnelled session?
> When MITM proxies learn to do that, will we create another tunnelling
> protocol inside this one?
> 
> This is a cat-and-mouse game with middleboxes (much like the version
> negotiation problem, but in a different way). Keep playing and everyone
> loses.
> 
> On Tue, Oct 31, 2017 at 11:17 AM, Richard Barnes  > wrote:
> 
> Hey TLS folks,
> 
> Owen, Max, and I have been kicking around some ideas for how to make
> secure connections in environments where HTTPS is subject to MitM /
> proxying.
> 
> The below draft lays out a way to tunnel TLS over HTTPS, in hopes of
> creating a channel you could use when you really need things to be
> private, even from the local MitM. 
> 
> Feedback obviously very welcome.  Interested in whether folks think
> this is a useful area in which to develop an RFC, and any thoughts
> on how to do this better.
> 
> Thanks,
> --Richard
> 
> 
> On Mon, Oct 30, 2017 at 3:47 PM,  > wrote:
> 
> 
> A new version of I-D, draft-friel-tls-over-http-00.txt
> has been successfully submitted by Owen Friel and posted to the
> IETF repository.
> 
> Name:           draft-friel-tls-over-http
> Revision:       00
> Title:          Application-Layer TLS
> Document date:  2017-10-30
> Group:          Individual Submission
> Pages:          20
> URL:           
> https://www.ietf.org/internet-drafts/draft-friel-tls-over-http-00.txt
> 
> 
> Status:       
>  https://datatracker.ietf.org/doc/draft-friel-tls-over-http/
> 
> Htmlized:     
>  https://tools.ietf.org/html/draft-friel-tls-over-http-00
> 
> Htmlized:     
>  https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http-00
> 
> 
> 
> Abstract:
>    Many clients need to establish secure connections to application
>    services but face challenges establishing these connections
> due to
>    the presence of middleboxes that terminate TLS connections
> from the
>    client and restablish new TLS connections to the service.  This
>    document defines a mechanism for transporting TLS records in HTTP
>    message bodies between clients and services.  This enables
> clients
>    and services to establish secure connections using TLS at the
>    application layer, and treat any middleboxes that are
> intercepting
>    traffic at the network layer as untrusted transport.  In
> short, this
>    mechanism moves the TLS handshake up the OSI stack to the
> application
>    layer.
> 
> 
> 
> 
> 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
> 
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org 
> https://www.ietf.org/mailman/listinfo/tls
> 
> 
> 
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls