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

[Ben Schwartz <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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, <[e-mail]> 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/d
>>>>> raft-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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>
>>>>
>>>
>>
>