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

Richard Barnes <rlb@ipv.sx> Mon, 30 October 2017 22:38 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7210D13942C for <tls@ietfa.amsl.com>; Mon, 30 Oct 2017 15:38:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2j1ZqnIJZ5RM for <tls@ietfa.amsl.com>; Mon, 30 Oct 2017 15:38:15 -0700 (PDT)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5EBC261 for <tls@ietf.org>; Mon, 30 Oct 2017 15:38:10 -0700 (PDT)
Received: by mail-wm0-x232.google.com with SMTP id r68so19457313wmr.3 for <tls@ietf.org>; Mon, 30 Oct 2017 15:38:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aizKT+Fp6bUS68AJww0U4+Y5R3QXW/ml3Wcn9VQsnW0=; b=wKM+sjT7T6PZW0ho09RVzEv3Z1sUJY1Ii0rSvn8vSguMEodLR5PPwcpMflP8h1t77y RzSSk1VDImFsghvoKK7urgKcb1DvEnytN/RSUEUhc780z4XllKBxJVANkKrlXDYyZN/X xk4zH3I3NEIiIaQLBOdMG5mzeHgn56Vf87FGjGQm4Mjr4lyFU4P9bY1mqrU2ik0KHQef 5MhqgRt3wiQ7hJJ5+oyYE9eU3G5bWABnKGxhWUpcIlT/vdZL7cO38ti3mdwpdiP5FfRV LogclrnWv4lbG7H1u0QT7NAWi20M88Rwd6C7hH4OPmpyfS42Jqq+55LK52lxP8sLbWjS RPOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aizKT+Fp6bUS68AJww0U4+Y5R3QXW/ml3Wcn9VQsnW0=; b=IW0sIjJ9wHaVKYRzFh4Z6IoCT5YtfKySR894xsT0KETKmMRmNUSFrtMeuslavJQpTp lIBlqYr36L9suv8C4afV197dg9KgSjwFj5W0RiF8P0N/1urgvJmcRPcpzL7k7P1Hv1yz 01XOMP+Vm/AvcgVcNhCDK3CHhZblAPR/xU+6ZxPPL7qso4eTiMumanR59/0sIVNosb8u 6bJHfntQA3omu5QUyx5//22V3X40YezHUTxmRvUMV1KP0slBWwhq9iauqd8ebYdK6fiM vVfOxmD4EdYUw7BVDIWvJd7KJVq3zhr0G9acDPyvdQCwSPOy1+xK0j0OPICRQpROJBzk dQGw==
X-Gm-Message-State: AMCzsaW+aNNNqnkFbgNU+xgtYogCp7rzyXkjUtX6zSfnH/cdtGNz4jE5 PfEiXjJWYA1YXrQh5XPuMrPV/oaPDm0evpX/Vd2X0sdG
X-Google-Smtp-Source: ABhQp+T+TxR4nMTufxe0SN989m/T3qshP02gVIHgku4KH/BVYvBZkfok7uMvzMBsGoHuODbqSi9dJDJ1Y6MUO/pkORs=
X-Received: by 10.28.156.67 with SMTP id f64mr176938wme.42.1509403089099; Mon, 30 Oct 2017 15:38:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.174.81 with HTTP; Mon, 30 Oct 2017 15:38:08 -0700 (PDT)
In-Reply-To: <CAL02cgTwWB_w4+j=8RS=1ZfxNkLE0OeKivrjz33oBamJyD_tbQ@mail.gmail.com>
References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> <CAL02cgRS715Vc+4_QNDSNBW8LP1f-Rmp0FW9W_pyHHpAnkX7Sg@mail.gmail.com> <CAHbrMsDMdjkffwqE+CeVfHBcU1gnxW3rpOmiitM3fCMyrTye0g@mail.gmail.com> <CAL02cgTwWB_w4+j=8RS=1ZfxNkLE0OeKivrjz33oBamJyD_tbQ@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Mon, 30 Oct 2017 18:38:08 -0400
Message-ID: <CAL02cgSBim4HxAkA-_HP3hc_95zsyNdvezmttgkTbs850pPddg@mail.gmail.com>
To: Ben Schwartz <bemasc@google.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a114b3208f2ea76055ccb4a5d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/1MAByNjX5voVCmhEQsfT3C7FV4A>
Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Oct 2017 22:38:17 -0000

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 <rlb@ipv.sx> 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 <bemasc@google.com> 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 <rlb@ipv.sx> 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, <internet-drafts@ietf.org> 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
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>>
>>
>