Re: Proposed Statement on "HTTPS everywhere for the IETF"
Niels Dettenbach <nd@syndicat.com> Fri, 05 June 2015 08:54 UTC
Return-Path: <nd@syndicat.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E6D1B2DF0 for <ietf@ietfa.amsl.com>; Fri, 5 Jun 2015 01:54:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.611
X-Spam-Level:
X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 mZcJUkXB0cNB for <ietf@ietfa.amsl.com>; Fri, 5 Jun 2015 01:54:21 -0700 (PDT)
Received: from mail.syndicat.com (mail.syndicat.com [62.146.89.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C581B2DFC for <ietf@ietf.org>; Fri, 5 Jun 2015 01:54:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=syndicat.com; s=x; h=Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:To:From; bh=tpHaQvs3WfaOt0fYkIQdqGAmv2xBGQJj3iCTZylOpj0=; b=WUcYH0eqi3wbAATBgP5B6jJh5iyASe2+3gbnjBVyCEwRy0p0Czfe1uJ8+8knI08iDvGUOx9yFA5GEmTylK24wyqED4oSxubScrxLe51UjeMmzLrnrNUi1++nqAWgcJKNZluom3YPYnBZIdSr6XdWHiOChtwtjANX+9ol91LokpY=;
Received: from localhost.syndicat.com ([127.0.0.1] helo=localhost) by mail.syndicat.com with esmtp (Syndicat.com PostHamster 4.84) (envelope-from <nd@syndicat.com>) id 1Z0nON-00018n-22 for ietf@ietf.org; Fri, 05 Jun 2015 10:54:19 +0200
X-Virus-Scanned: amavisd-new at syndicat.com
Received: from mail.syndicat.com ([127.0.0.1]) by localhost (mail.syndicat.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9MC55gzuXL6 for <ietf@ietf.org>; Fri, 5 Jun 2015 10:54:18 +0200 (CEST)
Received: from p50876cb7.dip0.t-ipconnect.de ([80.135.108.183] helo=gongo.localnet) by mail.syndicat.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Syndicat.com PostHamster 4.84) (envelope-from <nd@syndicat.com>) id 1Z0nOM-0003Sr-PK for ietf@ietf.org; Fri, 05 Jun 2015 10:54:18 +0200
From: Niels Dettenbach <nd@syndicat.com>
To: ietf@ietf.org
Subject: Re: Proposed Statement on "HTTPS everywhere for the IETF"
Date: Fri, 05 Jun 2015 10:54:11 +0200
Message-ID: <4421169.2LipD28Tao@gongo>
Organization: Syndicat IT&Internet
User-Agent: KMail/4.14.6 (Linux/4.0.1-niels; KDE/4.14.7; x86_64; ; )
In-Reply-To: <1C116522-648B-4C69-91BC-C56062FFB166@gbiv.com>
References: <20150601164359.29999.35343.idtracker@ietfa.amsl.com> <DA60EE0C-BC66-44E0-A00C-C9A96BA36DC6@cursive.net> <1C116522-648B-4C69-91BC-C56062FFB166@gbiv.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3195960.ph52lKROrk"; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/WPhS-o-fQB6yoDSB7Fj8rUkavRI>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jun 2015 08:54:23 -0000
Am Donnerstag, 4. Juni 2015, 13:57:24 schrieb Roy T. Fielding: > TLS does not provide privacy. What it does is disable anonymous access to > ensure authority. It changes access patterns away from decentralized > caching to more centralized authority control. That is the opposite of > privacy. TLS is desirable for access to account-based services wherein > anonymity is not a concern (and usually not even allowed). TLS is NOT > desirable for access to public information, except in that it provides an > ephemeral form of message integrity that is a weak replacement for content > integrity. Yes, i remember and know several scenarios where providers (mainly in the middle east and africa, where bandwidth is still "expensive") still are using large scale HTTP caching (wie build a few of it in the past) - to "save bandwidth" (costs) and/or improve "surf performance" from their view. HTTPS stuff isn't "usually" cached (except they try to break it by faking all SSL by their own (MitM) "working" certificate, which is afaik less the case in provider networks). This means users have to use the outer side networks to get static HTTP docs in any case / for "each request" - these networks are still often not secured physically or logically (i.e. unencrypted satellite or microwave trunks or fiber over neighbour country territory - encryption still costs ressources/money here...) and so (at least) very easy to sniff by anyone with very small equipment - i.e. jouranlists, hobbyists and - of course - any kind of other guys within i.e. the same satellite footprint. HTTPS brings centralization which leads to the opposite of "privacy" in such cases, but even if smaller networks are running caches this could make user tracking by third parties much more difficult. To provide data integrity (by the entity [like the IETF] BYSELF and not any third party the user has to trust additionally and to read/check by hand each time using a browser session!) content signing would be much more helpful while it allows further access over HTTP caches or even mirrors. And not at least: caching and mirroring could hardly rise data availability - by redundancy and it is more difficult to block access to. See i.e. the former wikileaks mirror network working this way (and i remember how my collegue was tried pressed by german services / police to hand out access to the german wikileaks web domain some years ago...). > If the IETF wants to improve privacy, it should work on protocols that > provide anonymous access to signed artifacts (authentication of the > content, not the connection) that is independent of the user's access > mechanism. +1 I'm not a crypto geek, but for me something what allows i.e. using my own pgp public key to sign (HTTP) documents on request - integrated in browsers / web security standards or similiar, would be a helpful solution. F.i., PGP still needs improvements in the possibilities of (decentralized) trust handling and transparent, dynamic "security levels" (a user has to "decide" which entities he trust in which way on a still more transparent and easier to "manage" level) - but i think that a person or entity should be able to manage trust from his own view onto it - and not mainly/only single others (or a complete branche of as in HTTPS/x509 the case in practice). The PGP principle is the nearest to that att. many thanks, Niels. -- --- Niels Dettenbach Syndicat IT & Internet http://www.syndicat.com PGP: https://syndicat.com/pub_key.asc ---
- Re: Proposed Statement on "HTTPS everywhere for t… Richard Barnes
- Re: Proposed Statement on "HTTPS everywhere for t… Bob Hinden
- Re: Proposed Statement on "HTTPS everywhere for t… Brian E Carpenter
- Re: Proposed Statement on "HTTPS everywhere for t… Niels Dettenbach
- Re: Proposed Statement on "HTTPS everywhere for t… Harald Alvestrand
- Re: Proposed Statement on "HTTPS everywhere for t… Stephen Farrell
- Re: Proposed Statement on "HTTPS everywhere for t… Phillip Hallam-Baker
- Re: Proposed Statement on "HTTPS everywhere for t… Nico Williams
- Re: Proposed Statement on "HTTPS everywhere for t… Niels Dettenbach (Syndicat.com)
- Re: Proposed Statement on "HTTPS everywhere for t… Niels Dettenbach (Syndicat.com)
- Re: Proposed Statement on "HTTPS everywhere for t… Paul Wouters
- Re: Proposed Statement on "HTTPS everywhere for t… Roland Dobbins
- Re: Proposed Statement on "HTTPS everywhere for t… Roland Dobbins
- Re: Proposed Statement on "HTTPS everywhere for t… Stephen Farrell
- Re: Proposed Statement on "HTTPS everywhere for t… Stephen Farrell
- Re: Proposed Statement on "HTTPS everywhere for t… Roland Dobbins
- Re: Proposed Statement on "HTTPS everywhere for t… Nico Williams
- Re: Proposed Statement on "HTTPS everywhere for t… Mark Baugher (mbaugher)
- Where are the places that block encrypted traffic? Sam Hartman
- Re: Proposed Statement on "HTTPS everywhere for t… S Moonesamy
- Re: Proposed Statement on "HTTPS everywhere for t… John Levine
- Re: Proposed Statement on "HTTPS everywhere for t… Masataka Ohta
- Re: Proposed Statement on "HTTPS everywhere for t… Eliot Lear
- Re: Proposed Statement on "HTTPS everywhere for t… Xiaoyin Liu
- Re: Where are the places that block encrypted tra… Patrik Fältström
- Re: Proposed Statement on "HTTPS everywhere for t… Eliot Lear
- Re: Proposed Statement on "HTTPS everywhere for t… Harald Alvestrand
- Re: Proposed Statement on "HTTPS everywhere for t… Jari Arkko
- Re: Proposed Statement on "HTTPS everywhere for t… Roland Dobbins
- Re: Proposed Statement on "HTTPS everywhere for t… Niels Dettenbach (Syndicat.com)
- Re: Proposed Statement on "HTTPS everywhere for t… Niels Dettenbach
- Re: Where are the places that block encrypted tra… Niels Dettenbach
- Re: Proposed Statement on "HTTPS everywhere for t… Mark Nottingham
- Re: Proposed Statement on "HTTPS everywhere for t… Stewart Bryant
- Re: Proposed Statement on "HTTPS everywhere for t… Stephen Farrell
- Re: Proposed Statement on "HTTPS everywhere for t… Jari Arkko
- Re: Proposed Statement on "HTTPS everywhere for t… Stephen Farrell
- Re: Proposed Statement on "HTTPS everywhere for t… l.wood
- Re: Proposed Statement on "HTTPS everywhere for t… Ted Lemon
- Re: Proposed Statement on "HTTPS everywhere for t… Joe Touch
- Re: Proposed Statement on "HTTPS everywhere for t… Ted Lemon
- Re: Proposed Statement on "HTTPS everywhere for t… Joe Touch
- Re: Proposed Statement on "HTTPS everywhere for t… Ted Lemon
- Re: Proposed Statement on "HTTPS everywhere for t… Joe Touch
- Re: Proposed Statement on "HTTPS everywhere for t… Richard Barnes
- Re: Proposed Statement on "HTTPS everywhere for t… Joe Touch
- Re: Proposed Statement on "HTTPS everywhere for t… Brian E Carpenter
- Re: Proposed Statement on "HTTPS everywhere for t… Richard Barnes
- Re: Proposed Statement on "HTTPS everywhere for t… Joe Touch
- Re: Proposed Statement on "HTTPS everywhere for t… Richard Barnes
- Re: Proposed Statement on "HTTPS everywhere for t… Joe Touch
- Re: Where are the places that block encrypted tra… Mark Andrews
- Re: Where are the places that block encrypted tra… Sam Hartman
- Re: Proposed Statement on "HTTPS everywhere for t… Jari Arkko
- Re: Proposed Statement on "HTTPS everywhere for t… Xiaoyin Liu
- Re: Proposed Statement on "HTTPS everywhere for t… Stewart Bryant
- Re: Proposed Statement on "HTTPS everywhere for t… t.p.
- Re: Proposed Statement on "HTTPS everywhere for t… t.p.
- Re: Where are the places that block encrypted tra… Tim Bray
- Re: Proposed Statement on "HTTPS everywhere for t… Stephen Farrell
- Re: Proposed Statement on "HTTPS everywhere for t… Joe Touch
- Re: Where are the places that block encrypted tra… Warren Kumari
- Re: Proposed Statement on "HTTPS everywhere for t… Cullen Jennings (fluffy)
- Re: Proposed Statement on "HTTPS everywhere for t… Niels Dettenbach
- Re: Proposed Statement on "HTTPS everywhere for t… Stephen Farrell
- RE: Proposed Statement on "HTTPS everywhere for t… Tony Hain
- Re: Proposed Statement on "HTTPS everywhere for t… Stephen Farrell
- Re: Proposed Statement on "HTTPS everywhere for t… Cullen Jennings (fluffy)
- Re: Proposed Statement on "HTTPS everywhere for t… John C Klensin
- RE: Proposed Statement on "HTTPS everywhere for t… Tony Hain
- Re: Proposed Statement on "HTTPS everywhere for t… Stephen Farrell
- Re: Proposed Statement on "HTTPS everywhere for t… Stephen Farrell
- Re: Proposed Statement on "HTTPS everywhere for t… John C Klensin
- RE: Proposed Statement on "HTTPS everywhere for t… Tony Hain
- Re: Proposed Statement on "HTTPS everywhere for t… Brian E Carpenter
- Re: Proposed Statement on "HTTPS everywhere for t… Yoav Nir
- RE: Proposed Statement on "HTTPS everywhere for t… Tony Hain
- Re: Proposed Statement on "HTTPS everywhere for t… Nico Williams
- Re: Proposed Statement on "HTTPS everywhere for t… Joe Hildebrand
- RE: Proposed Statement on "HTTPS everywhere for t… Christian Huitema
- RE: Proposed Statement on "HTTPS everywhere for t… Tony Hain
- Re: Proposed Statement on "HTTPS everywhere for t… Ted Lemon
- Re: Proposed Statement on "HTTPS everywhere for t… Ted Lemon
- Re: Proposed Statement on "HTTPS everywhere for t… Joe Touch
- Re: Proposed Statement on "HTTPS everywhere for t… Benson Schliesser
- Re: Proposed Statement on "HTTPS everywhere for t… Nico Williams
- Re: Proposed Statement on "HTTPS everywhere for t… Roy T. Fielding
- Re: Proposed Statement on "HTTPS everywhere for t… Niels Dettenbach
- Re: Proposed Statement on "HTTPS everywhere for t… Mark Nottingham
- Re: Proposed Statement on "HTTPS everywhere for t… l.wood
- Re: Proposed Statement on "HTTPS everywhere for t… Hector Santos
- Re: Proposed Statement on "HTTPS everywhere for t… Xiaoyin Liu
- Re: Proposed Statement on "HTTPS everywhere for t… Hector Santos
- Re: Proposed Statement on "HTTPS everywhere for t… Hector Santos
- Re: Proposed Statement on "HTTPS everywhere for t… Roy T. Fielding
- Re: Proposed Statement on "HTTPS everywhere for t… Mark Nottingham
- Re: Proposed Statement on "HTTPS everywhere for t… Roy T. Fielding
- Re: Proposed Statement on "HTTPS everywhere for t… Stephen Farrell