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

From: Richard Barnes <[email-masked]>
Date: Mon, 30 Oct 2017 18:17:44 -0400

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, <[email-masked]> 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
>
>

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 30 Oct 2017 18:26:07 -0400

Why not use HTTP CONNECT?  Or rather, it would be helpful to have a section
on when/why one would do this vs. CONNECT.

On Mon, Oct 30, 2017 at 6:17 PM, Richard Barnes <[email-masked]> 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.
>
> 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
>
>
>> URL:            https://www.ietf.org/internet-
>> drafts/draft-friel-tls-over-http-00.txt
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 30 Oct 2017 18:37:39 -0400

HTTP CONNECT is not great for some use cases because it requires the app to
be aware that it's dealing with a proxy.  It's simpler if you can just have
one code path that works whether your TLS is intermediated or not.  With
the solution outlined in the draft, you can just always ignore the
certificate the server sends in the first TLS connection (because it might
be from a MitM), and then do all your cert validation, pin checks, etc. at
the application layer.

On Mon, Oct 30, 2017 at 6:26 PM, Ben Schwartz <[email-masked]> wrote:

> Why not use HTTP CONNECT?  Or rather, it would be helpful to have a
> section on when/why one would do this vs. CONNECT.
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 30 Oct 2017 18:38:08 -0400

But I agree, it would be good to have some more clarity around use cases
and why not other solutions.

On Mon, Oct 30, 2017 at 6:37 PM, Richard Barnes <[email-masked]> wrote:

> HTTP CONNECT is not great for some use cases because it requires the app
> to be aware that it's dealing with a proxy.  It's simpler if you can just
> have one code path that works whether your TLS is intermediated or not.
> With the solution outlined in the draft, you can just always ignore the

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 30 Oct 2017 18:43:30 -0400

I don't understand why ATLS allows the app to be less "aware" than HTTP
CONNECT.  I also don't understand how an ATLS client is closer to "one code
path" than HTTP CONNECT.  It seems to me that your description of client
behavior applies equally to ATLS and HTTP CONNECT.

On Mon, Oct 30, 2017 at 6:38 PM, Richard Barnes <[email-masked]> wrote:

>>>> 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
>>>>
>>>>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 30 Oct 2017 22:56:01 +0000

> connections in environments where HTTPS is subject to MitM / proxying.

Interesting. One bit puzzles me: wouldn't the new content-type
give the game away and cause middleboxes to block this?

S.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 30 Oct 2017 19:02:17 -0400

It requires awareness in the following sense: If by chance the client is in
a nice, open network and the base TLS connection goes directly to the
server, CONNECT is kind of unnatural; you would want the client to do
something different in that case.  You're correct that you *could*
configure the server to handle connect properly, but all of the options for
doing this are kind of cumbersome -- either you have to stick a
possibly-unnecessary proxy in front of the server, or handle CONNECT on the
server, which is not really well-supported by web application frameworks.
By contrast, running data over POST is ubiquitous.

It was also pointed to me off-list that you can generate POST requests from
Javascript in XHR, but not CONNECT requests.  So doing this over POSTs also
makes it accessible to web apps.  (`emscripten libssl.a` left as an
exercise to the reader.)

--Richard

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 31 Oct 2017 10:26:11 +1100

Please consult with the HTTP WG *before* you start work in this area.

Thanks,

> On 31 Oct 2017, at 9:17 am, Richard Barnes <[email-masked]> 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
> 
> 
> 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://datatracker.ietf.org/doc/html/draft-friel-tls-over-http-00
> 
> 
> Abstract:
> Please note that it may take a couple of minutes from the time of submission

--
Mark Nottingham   https://www.mnot.net/

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 30 Oct 2017 21:35:16 -0400

On Mon, Oct 30, 2017 at 7:02 PM, Richard Barnes <[email-masked]> wrote:

> It requires awareness in the following sense: If by chance the client is
> in a nice, open network and the base TLS connection goes directly to the
> something different in that case.
>

Surely this is equally true/untrue of ATLS.  Why do double-TLS if it can be
avoided?  But then, how does the application know whether to do ATLS
encapsulation?  It's the same question in both cases.

>   You're correct that you *could* configure the server to handle connect
> properly, but all of the options for doing this are kind of cumbersome --
> either you have to stick a possibly-unnecessary proxy in front of the
> server, or handle CONNECT on the server, which is not really well-supported
> by web application frameworks.  By contrast, running data over POST is
> ubiquitous.
>

This makes a certain amount of sense to me.  If it were up to me, rather
than design a TLS-specific transport, I'd be more inclined to propose a
standardized version of something like Crowbar
<https://github.com/q3k/crowbar>.  (Or just document that reverse proxies
and frameworks ought to do something reasonable with CONNECT.)  Otherwise
this seems to be ossifying the proxy, privileging TLS and preventing
deployment of Noise protocol <http://noiseprotocol.org/> or whatever the
future may hold.

> makes it accessible to web apps.  (`emscripten libssl.a` left as an

It seems your threat model assumes an adversary who is an active
intermediary in your HTTP session.  If so, then this wouldn't seem to
protect the user against the threat.

>>>> HTTP CONNECT is not great for some use cases because it requires the
>>>> app to be aware that it's dealing with a proxy.  It's simpler if you can
>>>> just have one code path that works whether your TLS is intermediated or
>>>> not.  With the solution outlined in the draft, you can just always ignore
>>>> the certificate the server sends in the first TLS connection (because it
>>>> might be from a MitM), and then do all your cert validation, pin checks,
>>>> etc. at the application layer.
>>>>

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Tue, 31 Oct 2017 21:03:34 +0000

> -----Original Message-----
> From: TLS [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: 30 October 2017 22:56
> To: Richard Barnes <[email-masked]>; <[email-masked]> <[email-masked]>
> Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt
> 
> 
> 
> Interesting. One bit puzzles me: wouldn't the new content-type give the game
> away and cause middleboxes to block this?
> 
> S.
> 

[ofriel] The intention isn’t to try and obscure the fact that there is an ATLS session. Even if that new content-type was not defined, it would be easy to write a simple pattern match script on the middlebox to identity the JSON body and leading base64 bytes of the TLS records in the body.

> > creating a channel you could use when you really need things to be
> > private, even from the local MitM.
> >
> > this is a useful area in which to develop an RFC, and any thoughts on
> > how to do this better.
> >
> > Thanks,
> > --Richard
> >
> >
> >> 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.
> >>
> >> submission until the htmlized version and diff are available at
> >> tools.ietf.org.
> >>
> >> The IETF Secretariat
> >>
> >>
> >
> >
> >

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Tue, 31 Oct 2017 21:03:38 +0000

From: TLS [mailto:[email-masked]] On Behalf Of Ben Schwartz
Sent: 31 October 2017 01:35
To: Richard Barnes <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt

On Mon, Oct 30, 2017 at 7:02 PM, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:
It requires awareness in the following sense: If by chance the client is in a nice, open network and the base TLS connection goes directly to the server, CONNECT is kind of unnatural; you would want the client to do something different in that case.

Surely this is equally true/untrue of ATLS.  Why do double-TLS if it can be avoided?  But then, how does the application know whether to do ATLS encapsulation?  It's the same question in both cases.

[ofriel] The draft does state “As an optimisation, clients may choose to only use ATLS as a fallback
   mechanism if certificate validation fails on the transport layer TLS
   connection to the service
”
It should be easy for a device to detect the presence of a middlebox if the network layer TLS connection presents a service certificate that has the expected SAN/CN, but is signed by an unexpected/untrusted CA (i.e. one not baked into/explicitly configured on the device).

  You're correct that you *could* configure the server to handle connect properly, but all of the options for doing this are kind of cumbersome -- either you have to stick a possibly-unnecessary proxy in front of the server, or handle CONNECT on the server, which is not really well-supported by web application frameworks.  By contrast, running data over POST is ubiquitous.

This makes a certain amount of sense to me.  If it were up to me, rather than design a TLS-specific transport, I'd be more inclined to propose a standardized version of something like Crowbar<https://github.com/q3k/crowbar>.
[ofriel] /me reads. ‘like’ appears to be the operative word here based on author comments on https://github.com/q3k/crowbar: “Crowbar DOES NOT PROVIDE ANY DATA CONFIDENTIALITY”

(Or just document that reverse proxies and frameworks ought to do something reasonable with CONNECT.
[ofriel] CONNECT would just open a tunnel to get packets through the proxy to the service, but would require the proxy to *not* attempt to do TLS interception, which is exactly what we are trying to allow. If policy dictates that everything must be intercepted, this mechanism enables that.

)  Otherwise this seems to be ossifying the proxy, privileging TLS and preventing deployment of Noise protocol<http://noiseprotocol.org/> or whatever the future may hold.
[ofriel] One of the reason for blindly transporting TLS and not in any way restricting or customising the TLS records transferred was to be future compatible with all future versions of TLS; and also to allow an application to leverage a single software library for both network transport and application crypto exchanges.

It was also pointed to me off-list that you can generate POST requests from Javascript in XHR, but not CONNECT requests.  So doing this over POSTs also makes it accessible to web apps.  (`emscripten libssl.a` left as an exercise to the reader.)

It seems your threat model assumes an adversary who is an active intermediary in your HTTP session.  If so, then this wouldn't seem to protect the user against the threat.
[ofriel] Can you clarify why this doesn’t protect against an active intermediary in the HTTP session? Transferring the TLS records payloads in HTTP bodies is directly analogous to  transferring TLS records over untrusted TCP network transport.

--Richard

On Mon, Oct 30, 2017 at 6:43 PM, Ben Schwartz <[email-masked]<mailto:[email-masked]>> wrote:
I don't understand why ATLS allows the app to be less "aware" than HTTP CONNECT.  I also don't understand how an ATLS client is closer to "one code path" than HTTP CONNECT.  It seems to me that your description of client behavior applies equally to ATLS and HTTP CONNECT.

On Mon, Oct 30, 2017 at 6:38 PM, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:
But I agree, it would be good to have some more clarity around use cases and why not other solutions.

On Mon, Oct 30, 2017 at 6:37 PM, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:
HTTP CONNECT is not great for some use cases because it requires the app to be aware that it's dealing with a proxy.  It's simpler if you can just have one code path that works whether your TLS is intermediated or not.  With the solution outlined in the draft, you can just always ignore the certificate the server sends in the first TLS connection (because it might be from a MitM), and then do all your cert validation, pin checks, etc. at the application layer.

On Mon, Oct 30, 2017 at 6:26 PM, Ben Schwartz <[email-masked]<mailto:[email-masked]>> wrote:
Why not use HTTP CONNECT?  Or rather, it would be helpful to have a section on when/why one would do this vs. CONNECT.

On Mon, Oct 30, 2017 at 6:17 PM, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:
Hey TLS folks,

Thanks,
--Richard

On Mon, Oct 30, 2017 at 3:47 PM, <[email-masked]<mailto:[email-masked]>> wrote:

Abstract:

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<http://tools.ietf.org>.

The IETF Secretariat

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

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 31 Oct 2017 17:16:51 -0400

On Tue, Oct 31, 2017 at 5:03 PM, Owen Friel (ofriel) <[email-masked]>
wrote:

>
>
>
>
> *From:* TLS [mailto:[email-masked]] *On Behalf Of *Ben Schwartz
> *Sent:* 31 October 2017 01:35
> *To:* Richard Barnes <[email-masked]>
> *Cc:* <[email-masked]> <[email-masked]>
> *Subject:* Re: [TLS] New Version Notification for
> draft-friel-tls-over-http-00.txt
>
>
>
> Surely this is equally true/untrue of ATLS.  Why do double-TLS if it can
> be avoided?  But then, how does the application know whether to do ATLS
> *[ofriel] The draft does state “*As an optimisation, clients may choose to only use ATLS as a fallback
>
> *”*
> *It should be easy for a device to detect the presence of a middlebox if
> the network layer TLS connection presents a service certificate that has
> the expected SAN/CN, but is signed by an unexpected/untrusted CA (i.e. one
> not baked into/explicitly configured on the device).*
>

Yes, but the client could equally well fall back to HTTP CONNECT in this
case.  My comments are all directed to the question of why to use ATLS
instead of an existing solution, such as "TLS over HTTP CONNECT".

> <https://github.com/q3k/crowbar>.
>
> *[ofriel] /me reads. ‘like’ appears to be the operative word here based on
> author comments on https://github.com/q3k/crowbar
> <https://github.com/q3k/crowbar>: “*Crowbar *DOES NOT PROVIDE ANY DATA
> CONFIDENTIALITY**”*
>

Yes, but "TLS over Crowbar" does provide confidentiality, and that is the
alternative to ATLS that I am proposing in this sentence.

(Or just document that reverse proxies and frameworks ought to do something
> reasonable with CONNECT.
>
> *[ofriel] CONNECT would just open a tunnel to get packets through the
> proxy to the service, but would require the proxy to *not* attempt to do
> TLS interception, which is exactly what we are trying to allow. If policy
> dictates that everything must be intercepted, this mechanism enables that.*
>

I don't understand which proxy you're referring to, or how this
distinguishes ATLS from "TLS over HTTP CONNECT".

)  Otherwise this seems to be ossifying the proxy, privileging TLS and
> preventing deployment of Noise protocol <http://noiseprotocol.org/> or
> whatever the future may hold.
>
> *[ofriel] One of the reason for blindly transporting TLS and not in any
> way restricting or customising the TLS records transferred was to be future
> compatible with all future versions of TLS; and also to allow an
> application to leverage a single software library for both network
> transport and application crypto exchanges.*
>

OK, but you can be even more abstracted by simply transporting a
byte-stream, and letting the application developer choose what protocol to
speak in that stream.  This shares even more code between the "network" and
"application" usage of TLS, since they both flow over bytestream
abstractions (no need to expose the TLS record layer).

> It was also pointed to me off-list that you can generate POST requests
> from Javascript in XHR, but not CONNECT requests.  So doing this over POSTs
> also makes it accessible to web apps.  (`emscripten libssl.a` left as an
> exercise to the reader.)
>
>
>
> *[ofriel] Can you clarify why this doesn’t protect against an active
> intermediary in the HTTP session? Transferring the TLS records payloads in
> HTTP bodies is directly analogous to  transferring TLS records over
> untrusted TCP network transport.*
>

In a "web app", the emscripten-compiled copy of libssl would necessarily be
transmitted over the insecure HTTP connection that also contains ATLS.  An
active intermediary therefore could, for example, replace the library with
a modified version that uses a broken PRNG.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 31 Oct 2017 21:26:27 +0000

Hi Owen,

On 31/10/17 21:03, Owen Friel (ofriel) wrote:
> [ofriel] The intention isn’t to try and obscure the fact that there 
> is an ATLS session. Even if that new content-type was not defined,
> it would be easy to write a simple pattern match script on the
> middlebox to identity the JSON body and leading base64 bytes of the
> TLS records in the body.

So that leaves me puzzled still, sorry.

I can't think of a situation with a middlebox that isn't ok
with the client doing proper TLS but is ok with ATLS.

Can you give an example of such a situation?

In case it helps, I can imagine that some middleboxes won't
(yet) know about this and will let it through for a while,
but that seems fairly brittle. So, I'd have thought it may
be worthwhile trying to hide what's what here if you want
it to be robust against an antagonistic middlebox or censor.
But maybe you guys analysed that already and figured it'd
not work. (Which brings me back to "puzzled":-)

Cheers,
S.