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

From: Patrick McManus <[email-masked]>
Date: Wed, 1 Nov 2017 18:17:11 +0100

Some feedback, in no particular order:

* have a hard think about handshake/termination loads. istm this scheme
devolves pretty quickly to a termination per object HTTP/1.0 style so
you'll be fairly quickly looking to do some kind of multiplexing and reuse
on top of it for the same reasons HTTP evolved that way. as an alternative
- HTTP/2 inside of a CONNECT tunnel (e.g. HTTP/2 on one stream of an HTTP/2
session) is something browsers already do and may be a carrot worth chasing
if you want to give up on the dream of just deploying js into the current
environment.

* read the current websockets over http/2 thread on httpbis with an eye to
the discussion about CONNECT vs (a hypothetical) TUNNEL. There are some
similarities to the discussion here.

* also take a look at https://tools.ietf.org/html/dr
aft-nottingham-bcp56bis-00 (to be adopted imminently by httpbis) - for
general foo over http guidance. In particular note that requiring
particular behavior from http response codes beyond what is already defined
(adding semantics) is called out as a practice to be avoided.

* I don't really understand how s->c data flows other than as a reply to
client data. hanging get? polling? push?

* istm you are using http as a reliable messaging layer. That 'reliable'
part might get you into trouble.. various events can cause an http
transaction to fail and I'm not sure how you recover that state without
record number etc.. Is there room for a off path malicious actor to disrupt
your stream state (e.g. send a get with your session ID to get a few bytes
of ciphertext - which means you never get them?)? Perhaps this works better
as a more generic "datagram over http" framework which you can obviously
run some form of reliable stream and tls (and http) on top of. why is a tls
record the best scope here?

On Tue, Oct 31, 2017 at 10:26 PM, Stephen Farrell <[email-masked]
> wrote:

>
> Hi Owen,
>
> On 31/10/17 21:03, Owen Friel (ofriel) wrote:
> >> 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.
>
> 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.
>
>
> >
> >
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Tue, 7 Nov 2017 01:15:23 +0000

From: Ben Schwartz [mailto:[email-masked]]
Sent: Tuesday 31 October 2017 21:17
To: Owen Friel (ofriel) <[email-masked]>
Cc: Richard Barnes <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt

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

From: TLS [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ben Schwartz
Sent: 31 October 2017 01:35
To: Richard Barnes <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[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).

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

[ofriel] I fully agree that if a TLS tunnel opened via HTTP CONNECT is possible, then ATLS is not needed as the TLS connection is e2e between C->S and the middlebox is not inspecting traffic. However, if the middlebox proxy enforces TLS inspection and does not allow opening a TLS tunnel via HTTP CONNECT, then the dumb IoT device will fail cert validate on the TLS connection terminated on the middlebox.

  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”

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

[ofriel] On browsing what crowbar code actually does, this makes sense. The crowbar solution includes a crowbar-forward agent that client apps talk to, and this sends the packets received over TCP from the client app inside HTTP bodies to a crowbard server, which in turn forwards them to the target server host:port. It also includes some funky URI and message body prefixes in https://github.com/q3k/crowbar/blob/master/proto.go and some rudimentary HMAC(pwd) based authentication.

While crowbar does support listening for any TCP packet stream (which could be a TLS stream) and forwarding them inside HTTP bodies (via crowbar-forward and crowbard server) to a target host:port; we are getting into the realms of requirements here. What we had set out to achieve was e2e encryption between a client and a service across a TLS intercepting middlebox, by simple reuse of the standard TLS stack, without requiring any extra services. More on this below..

(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".

[ofriel] I hope I clarified this above. TLS over HTTP CONNECT is e2e network layer TLS from C->S, the middlebox is not inspecting content, and ATLS isn’t needed if the middlebox allows this.

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

[ofriel] Another packaging of content we had considered, and which is equally valid, is to just send the raw TLS Records in the body and specify Content-Type as something like application/atls+octet-stream, not explicitly include the TLS “session” identifier in the message body and have it set by the service in a suitable Set-Cookie.

Note that the TLS record layer isn’t really exposed per-se to the application in either case. The TLS stacks (OpenSSL and JSSE at least) produce raw byte streams that happen to be TLS records, but the application has no idea that they actually are TLS records. In fact, the stacks don’t even expose APIs directly to consumers for parsing the byte streams produced even if the app wanted to grok the TLS records.

One option for making the transport more generic is to simply include raw bytestreams (SSH, TLS, whatever) in HTTP bodies and define suitable application/xxxx+octet-stream.
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.

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.

[ofriel] Ok. That’s true for webapps downloading JavaScript over the HTTP connection. But not true for devices that would be using the TLS stack baked into their firmware. An active intermediary couldn’t mess with the ATLS stack in that instance.

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

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

The IETF Secretariat

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

---

From: Alex C <[email-masked]>
Date: Tue, 7 Nov 2017 22:21:37 +1300

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 <[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
>
>
> On Mon, Oct 30, 2017 at 3:47 PM, <[email-masked]> wrote:
>
>>
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 7 Nov 2017 11:23:55 +0100

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:
> 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?
> On Tue, Oct 31, 2017 at 11:17 AM, Richard Barnes <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Hey TLS folks,
> 
>     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]
>     <mailto:[email-masked]>> wrote:
> 
> 
>         URL:           
>         https://www.ietf.org/internet-drafts/draft-friel-tls-over-http-00.txt
>         <https://www.ietf.org/internet-drafts/draft-friel-tls-over-http-00.txt>
>         Status:       
>          https://datatracker.ietf.org/doc/draft-friel-tls-over-http/
>         <https://datatracker.ietf.org/doc/draft-friel-tls-over-http/>
>         Htmlized:     
>          https://tools.ietf.org/html/draft-friel-tls-over-http-00
>         <https://tools.ietf.org/html/draft-friel-tls-over-http-00>
>         Htmlized:     
>          https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http-00
>         <https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http-00>
> 
> 
>         Abstract:
>         until the htmlized version and diff are available at
>         tools.ietf.org <http://tools.ietf.org>.
> 
>         The IETF Secretariat
> 
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/tls>
> 
> 
> 
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 7 Nov 2017 12:20:56 +0000

➢     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)?

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 7 Nov 2017 14:01:15 +0100

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

I see QUIC more as a new transport layer.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 7 Nov 2017 16:15:02 +0100

FWIW: I can tell you what the threat model was with the layered TLS work.

Let me give you a very specific example. Imagine a Bluetooth Low Energy
device that communicates via a phone to a cloud-based service. The
communication from the phone to the cloud uses HTTPS. The communication
from the BLE device to the phone uses ordinary BLE
services/characteristics.

The Layered TLS/application layer TLS would in this case run from the
BLE device all the way to the cloud-based service at the application layer.

This allows us to provide end-to-end security across a proxy (in this
case the phone) and independent of the underlying protocols.

Does this make sense?

Ciao
Hannes

---

From: Yoav Nir <[email-masked]>
Date: Tue, 7 Nov 2017 17:36:21 +0200

Hi, Hannes.

I think it makes sense if the middlebox (whether a TLS proxy or a phone) cannot perform a MitM attack against the internal TLS. This can be achieved by having separate trust anchors for the application vs the ones used for HTTPS, specifically not including any “proxy CA certificate”.

Yoav

> On 7 Nov 2017, at 17:15, Hannes Tschofenig <[email-masked]> wrote:
> 
>> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>> 
>>    Hey TLS folks,
>> 
>>    On Mon, Oct 30, 2017 at 3:47 PM, <[email-masked] <mailto:[email-masked]>
>>    <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>> 
>> 
>>        https://www.ietf.org/internet-drafts/draft-friel-tls-over-http-00.txt <https://www.ietf.org/internet-drafts/draft-friel-tls-over-http-00.txt>
>>        <https://www.ietf.org/internet-drafts/draft-friel-tls-over-http-00.txt <https://www.ietf.org/internet-drafts/draft-friel-tls-over-http-00.txt>>
>>        Status:
>>         https://datatracker.ietf.org/doc/draft-friel-tls-over-http/ <https://datatracker.ietf.org/doc/draft-friel-tls-over-http/>
>>        <https://datatracker.ietf.org/doc/draft-friel-tls-over-http/ <https://datatracker.ietf.org/doc/draft-friel-tls-over-http/>>
>>        Htmlized:
>>         https://tools.ietf.org/html/draft-friel-tls-over-http-00 <https://tools.ietf.org/html/draft-friel-tls-over-http-00>
>>        <https://tools.ietf.org/html/draft-friel-tls-over-http-00 <https://tools.ietf.org/html/draft-friel-tls-over-http-00>>
>>        Htmlized:
>>         https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http-00 <https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http-00>
>>        <https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http-00 <https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http-00>>
>> 
>> 
>>        Abstract:
>>        tools.ietf.org <http://tools.ietf.org/> <http://tools.ietf.org <http://tools.ietf.org/>>.
>> 
>>        The IETF Secretariat
>> 
>> 
>> 
>>    [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>    https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
>>    <https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>>
>> 
>> 
>> 
>> 
>> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
>> 
> 
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 7 Nov 2017 09:21:45 -0700

> case the phone) and independent of the underlying protocols.

Given your assumptions, yes. Although IMHO there's got to be a better
way to accomplish the goal of end-to-end security here. If I were going
to IETF 100, I'd propose getting together for a beer to discuss...

Peter

---

From: Alex C <[email-masked]>
Date: Wed, 8 Nov 2017 09:53:13 +1300

If the embedded device is capable of running TLS anyway (e.g. fast enough
to do RSA) why not have the phone act as a dumb proxy?

However I see the draft has some additional scenarios where it makes sense,
such as where the device must work with an off-the-shelf proxy that only
speaks HTTP.

On Wed, Nov 8, 2017 at 4:15 AM, Hannes Tschofenig <[email-masked]

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 8 Nov 2017 18:55:43 +0100

Hi Peter,

too bad that you are not attending the upcoming IETF meeting in person.
I am sure that others would like to hear your thoughts about an
end-to-end security solution that is even better than the TLS 1.3
protocol. At least I am interested.

Maybe you can share something on the list.

Ciao
Hannes