Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt
Alex C <immibis@gmail.com> Tue, 07 November 2017 20:53 UTC
Return-Path: <immibis@gmail.com>
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 6E29B12751F for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 12:53:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 PvClObE1Mp9c for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 12:53:15 -0800 (PST)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 0EC3C126D85 for <tls@ietf.org>; Tue, 7 Nov 2017 12:53:15 -0800 (PST)
Received: by mail-vk0-x229.google.com with SMTP id h142so374199vkf.7 for <tls@ietf.org>; Tue, 07 Nov 2017 12:53:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PPmdYl6x4XyZcPjiDeN3CaEvZ5nDG4Kqyty7BqU7hpo=; b=dSFzAp4klF0GF8UDOK/Z70g/f6OuRWVW0tCF0oippe1Hp8GO706zH6Ptc4/oHu+x9A GHRzL9J+MgiCGTxyzwAmeX4AY52IjdDA2VoBNKtmv296V4gHLZ/QkB/lTmFQPGgm3F/3 olwZe6VP7cs6oaVmIy+tdDFaf7RPoHAio2m0x2eEqXeUTG3TBZ/M0taTQv1/W4bqo/HU AU/v19PUPyCUvF2nlQvtpmHhUi0EPalX13RwU3QLMuHnWvwMaz9n5ffVlc+bu1qnts2a k/sT4D7IP/z6NE3ji9qcwcYBep3d9MURuRqGzYzisgQcIjsWiBKDHBoI7Iqmk24mMEHi n23Q==
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=PPmdYl6x4XyZcPjiDeN3CaEvZ5nDG4Kqyty7BqU7hpo=; b=bD8CYZY0+eGqhWvsu/1XtcUFD8z63DXq4Jj86GdKnsaDnI+vX26gG7dVHcFC1t2b1y 18QgrmbmoPTZ+QaaAnSH6VjxUBSHLHEyMwkrC/jFfqOzGn0yoknrtexO9A+w7oIvRH+d R4itI0XoRnYW0Ea7kUStP2UoRcuogNoBXd/E/Dy/2DFHRSEqu8LO3XOO11sDFHFfgk4G erlwU5cJXqkGjvWySJETYzl9586o4c+cbxtvDKRM8kdnGQmWBL0ejK9zE6S2BvO6JgMB xlZBh6cDYr1W4E8/aFKHw61ik73CtHRQ/n+bZhE4z2G7+2bwe/NQ1MoLXySEW7NoDkdx qjLQ==
X-Gm-Message-State: AJaThX7awaRQ1eZIjIOR1sKjOOL5RKFT6YHYTk6PXizULBKgN33N1RvG KPIFJQXk/lEExw+UIP/6+arFQmMnjMCkGOJe8UA=
X-Google-Smtp-Source: ABhQp+QIEpqRJp3exNiFqR4rplHSVLf9m55CNvQFssSJFUHidOnH+6eqaMtUHrNEK/ODzKN+swhSkt4YkCR2/JZtbro=
X-Received: by 10.31.188.71 with SMTP id m68mr33240vkf.180.1510087994013; Tue, 07 Nov 2017 12:53:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.34.67 with HTTP; Tue, 7 Nov 2017 12:53:13 -0800 (PST)
In-Reply-To: <da4504a1-f868-bf66-1f28-2b7716207d07@gmx.net>
References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> <CAL02cgRS715Vc+4_QNDSNBW8LP1f-Rmp0FW9W_pyHHpAnkX7Sg@mail.gmail.com> <CAMqknA6-+=W8j77xZ80M8Y+bz3V+VLUDOYjgK2vA0=HLHk7k2w@mail.gmail.com> <da4504a1-f868-bf66-1f28-2b7716207d07@gmx.net>
From: Alex C <immibis@gmail.com>
Date: Wed, 08 Nov 2017 09:53:13 +1300
Message-ID: <CAMqknA7Zvj4JrZnucHy1kjLjSoJVddYHLVp5tC5eyLaYhOXQ+w@mail.gmail.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Cc: Richard Barnes <rlb@ipv.sx>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a1143aa4a767e32055d6ac20d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/81K2NmAoUDPGVhCj_TLI7lTm578>
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: Tue, 07 Nov 2017 20:53:17 -0000
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 <hannes.tschofenig@gmx.net > wrote: > 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 > > > 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 <rlb@ipv.sx > > <mailto: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 > > <mailto: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 > > <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: > > 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 > > TLS@ietf.org <mailto:TLS@ietf.org> > > https://www.ietf.org/mailman/listinfo/tls > > <https://www.ietf.org/mailman/listinfo/tls> > > > > > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > >
- Re: [TLS] New Version Notification for draft-frie… Richard Barnes
- Re: [TLS] New Version Notification for draft-frie… Ben Schwartz
- Re: [TLS] New Version Notification for draft-frie… Richard Barnes
- Re: [TLS] New Version Notification for draft-frie… Richard Barnes
- Re: [TLS] New Version Notification for draft-frie… Ben Schwartz
- Re: [TLS] New Version Notification for draft-frie… Stephen Farrell
- Re: [TLS] New Version Notification for draft-frie… Richard Barnes
- Re: [TLS] New Version Notification for draft-frie… Mark Nottingham
- Re: [TLS] New Version Notification for draft-frie… Ben Schwartz
- Re: [TLS] New Version Notification for draft-frie… Owen Friel (ofriel)
- Re: [TLS] New Version Notification for draft-frie… Owen Friel (ofriel)
- Re: [TLS] New Version Notification for draft-frie… Ben Schwartz
- Re: [TLS] New Version Notification for draft-frie… Stephen Farrell
- Re: [TLS] New Version Notification for draft-frie… Patrick McManus
- Re: [TLS] New Version Notification for draft-frie… Owen Friel (ofriel)
- Re: [TLS] New Version Notification for draft-frie… Alex C
- [TLS] Layered TLS ... was Re: New Version Notific… Hannes Tschofenig
- Re: [TLS] Layered TLS ... was Re: New Version Not… Salz, Rich
- Re: [TLS] Layered TLS ... was Re: New Version Not… Hannes Tschofenig
- Re: [TLS] New Version Notification for draft-frie… Hannes Tschofenig
- Re: [TLS] New Version Notification for draft-frie… Yoav Nir
- Re: [TLS] New Version Notification for draft-frie… Peter Saint-Andre
- Re: [TLS] New Version Notification for draft-frie… Alex C
- Re: [TLS] New Version Notification for draft-frie… Hannes Tschofenig