Re: Proposed Statement on "HTTPS everywhere for the IETF"
Niels Dettenbach <nd@syndicat.com> Mon, 01 June 2015 18:56 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 946921B3136 for <ietf@ietfa.amsl.com>; Mon, 1 Jun 2015 11:56:08 -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 9_HOpQV_tio1 for <ietf@ietfa.amsl.com>; Mon, 1 Jun 2015 11:56:06 -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 D08881B3135 for <ietf@ietf.org>; Mon, 1 Jun 2015 11:56:05 -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=5R33Fn0nx/IugaiteE4dKb73jswE6k5WtGk8IWMgdi4=; b=GM75poLkMw+OstM8QGXCJYaEjMCIKXr3uUIJTsHtSr+JR+JlujiLDPJO0JqL65qj8bdhDpvBXMi59JnlgwjR5qUuqDgXiTHVAenARtWzbZFkMo68WW1uiI6aNGraTeqi6eozmAQtfZClkpKIYJusa+lMj9BdTOeeJu9iz3pCyTw=;
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 1YzUsU-0004mm-TG for ietf@ietf.org; Mon, 01 Jun 2015 20:56:02 +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 nAz8_M4f4O88 for <ietf@ietf.org>; Mon, 1 Jun 2015 20:56:02 +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 1YzUsU-0005vY-KN for ietf@ietf.org; Mon, 01 Jun 2015 20:56:02 +0200
From: Niels Dettenbach <nd@syndicat.com>
To: ietf@ietf.org
Subject: Re: Proposed Statement on "HTTPS everywhere for the IETF"
Date: Mon, 01 Jun 2015 20:55:57 +0200
Message-ID: <1472054.O9DP0qoCQf@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: <CAL02cgRPFooA5fVFwvdprb3wPD+Y55pD+7RWjkACDv7T_TBW5Q@mail.gmail.com>
References: <20150601164359.29999.35343.idtracker@ietfa.amsl.com> <CAL02cgRPFooA5fVFwvdprb3wPD+Y55pD+7RWjkACDv7T_TBW5Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart16103813.fJBZQAtHQ0"; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/qAX5vNvQfLwrBB12Xv8YFAvHTU4>
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: Mon, 01 Jun 2015 18:56:08 -0000
Am Montag, 1. Juni 2015, 13:16:10 schrieb Richard Barnes: > Do it. Do it boldly and fearlessly. Make the statement and implement it. > Don't be tied to legacy. Anything that doesn't support HTTPS at this point > needs to upgrade and deserves to be broken. ...sorry guys, but please don't be so "blind" and "populistic". I have no Problem with SSL/TLS as an general option (!) to access public IETF HTTP services / documents - but not as a general "fact". Pls implement DNSSEC and such stuff as far as not done att which makes more sense. Beside the fact that the IETF has no own "accredited" SSL/x509 root in the major browsers and i assume the IETF would not use a non "certified" or "self signed" root - why should i "trust" and use any third party certification from any company i don't (want to and/or can) know? And why should (usually not thumb...) IETF readers / users are not able to decide if they want or "need" that TLS/SSL product the IETF would offer? SSL/TLS would do no more then make shure that any third party company "trust" a connection to the IETF and as long as you "trust" them, the content (most of a still very public type) of your requests should not be readable by MitM - by their own policies which may be conform to the browsers / browser alliance policies (which is primarily a policy of high fees from my view...). SSL/TLS does NOT deliver anonymity to the users - and the most parts of the IETF web content is public accessible. And people who need anonymity have other an probably even better ways to get that HTTP (i.e. cryptotunnels or TOR to anywhere who they are "safe"). Shure - TLS/SSL has their applications in different fields - but i can't follow this current "encrypt anything" attitude from different social vectors today (in germany we have the first politicans who would do that by law to any "internet communication"...). There are many scenarios where it is far from a "requirement" and even some where it is just non sense to block non encrypted / authenticated usage. Encryption costs energy (and even if you have the money - it generates at least further CO2) and other ressources - so it makes no sin to use it where it doesn't has a value at least from the users view. These effect is multiplied when even robots / agents / spiders and other automatized services where data integrity is not primarily or other reasons behind have only the option HTTPS. The major resons the most peoples fighting today for that "encryping anything" thing i heared are usually: - "The NSA could read anything otherwise. We need our privacy integrity back..." -> such services are much more interested in meta data of communication, which is even widely accessible for HTTPS / SSL / TLS "secured" connections and it IS accessible not at least because governments / democracies are giving them access top by law. Change the law if you would change that - but don't cripple the non-political net. -> And if "the NSA" (or many others "services") want to get into a software product or encryption stack, they have many options by law - even in other countries. - "The Mozilla Team" and/or "well known peoples around" that scene has announced, that Firefox will block "unencrypted", "non ssl" HTTP in "future versions" as a "Feature" for their users. -> Beside the fact that i wouldnÄ't use Firefox anymore at that time - even if Firefox is an Open Source product, but not a "pure" community project - the browser project still makes his own money - not at least by selling licenses to companies which want to print money by "certifying" for that browsers (in SSL / TLS / x509). Take a look at the (at least formerly) yearly fees ("audition fees" or such called, but much higher then a certification does take as work...) they take and you will take a new voew onto their "high skilled arguments from a pure technical view"... Ergo: The HTTP SSL and TLS technology and infrastructure is useful in much more special scenarios then most peoples think it is - because of very difficult and complex, intransparent collidation of interests of different parties in the current (trust) structure. - And: there ARE poeples and services which doen't allow encrypted access for legal or organisational reasons - it would not be nice to block interested poeples from such user "societies" which are not usually free to decide for an alternative byself. And for me personal: I use a 7 year old cell phone to read http stuff in my spare time and do not understand why i should buy a new one for the very same application. "legacy" means that there are newer standards which offer ME more value i WANT - and not others mean that i HAVE TO WANT. Buying a new phone for just using encryption i don't want is non sense. I would could afford it, but i (personally) think the ressources are better to use otherwhere (or even not used). in short: +1 for SSL as an option (ideally with IETFs own x509 root CA) -1 for blocking plain text HTTP at general just my two cents - sorry for the noise, and my (probably) bad english, 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