Re: Proposed Statement on "HTTPS everywhere for the IETF"
Niels Dettenbach <nd@syndicat.com> Tue, 02 June 2015 08:40 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 21E831A898C for <ietf@ietfa.amsl.com>; Tue, 2 Jun 2015 01:40:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.711
X-Spam-Level:
X-Spam-Status: No, score=-3.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_32=0.6, 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 BfNeyvndjuwI for <ietf@ietfa.amsl.com>; Tue, 2 Jun 2015 01:40:10 -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 14A9B1A8980 for <ietf@ietf.org>; Tue, 2 Jun 2015 01:40:10 -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=lTvZEaLIn67LKiajRB+B9sbMfS9FWgkiITHT0b/sohM=; b=h70AoxumT38+Ivdyh2h4BRLW9BMza1Gb8pMIvL6+zk6U/ClppJZYIO5axQioK3haDJf2CM10NE72J2BycRj0Mu67Pvh5w/HNjHvbqtjmpkgiJc0hVj02bm3LKcAUp1iOpdOE9X46xBv19OUFHofvcj3tZ7BUJa3ewoMgfzMNcbA=;
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 1Yzhk0-00012s-DU for ietf@ietf.org; Tue, 02 Jun 2015 10:40:08 +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 iPNULjED88yy for <ietf@ietf.org>; Tue, 2 Jun 2015 10:40:08 +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 1Yzhk0-0007VZ-4X for ietf@ietf.org; Tue, 02 Jun 2015 10:40:08 +0200
From: Niels Dettenbach <nd@syndicat.com>
To: ietf@ietf.org
Subject: Re: Proposed Statement on "HTTPS everywhere for the IETF"
Date: Tue, 02 Jun 2015 10:40:01 +0200
Message-ID: <4026551.C95htlAePj@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: <556D4C38.6060704@alvestrand.no>
References: <20150601164359.29999.35343.idtracker@ietfa.amsl.com> <1C4D741C-89EA-4973-8536-D6A02EFD7624@syndicat.com> <556D4C38.6060704@alvestrand.no>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1528580.j5br1VJKTt"; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/Wy4IgiYALvSE4xYNn7C-kXyhBuM>
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: Tue, 02 Jun 2015 08:40:13 -0000
Am Dienstag, 2. Juni 2015, 08:24:56 schrieb Harald Alvestrand: > have you looked at your cable TV lately? Or your DAB radio? Encrypting publically accessible TV vor radio content just could bring added value for the Distributor / provider - i.e. by avoiding any not paid usage by thirds or using other Hardware. There is usually no value for the recipient (possibly except Pay-TV products), but significant less freedom and for this reason i.e. basic TV encryption in cable networks was prohibited by the federal cartel office these days here in germany (german): http://www.heise.de/newsticker/meldung/TV-Grundverschluesselung-Freie-Sicht-bei-Unity-Media-1776052.html > See the Great Cannon attack. Allowing in-flight modification of > resources (which using HTTP is) is not just a theoretical danger to > yourself, it's a practical danger to anyone on the Net. HTTPS "Encryption" byself is not targeting MitM "modifications" - this is mainly a part of signatures (in HTTPS "realized" by "certificates"). Avoiding modifications MitN is (technically) possible "just" by signatures or hashes (in theory...). HTTPs rely fully on signatures from any third Party a user has to trust in full plus he has to check the FULL certification path for each website he want to use (by theory...). It is not a simple question of "is it green in the Browsers line?" as the very most of users think today in practice... The browser distributors has no interest in changing that view, because the status quo leads to more dependence from their licensing politics. This is why some browsers i.e. make it more and more diffucult to use HTTPS in private networks where they have no fitting "SSL" product for. If you just find ONE of the up to hundreds of Browser CAs (or at least some cross/sub CA contractor) today where one is providing you a certificate for and third Party you have it compromized "silently" even it it uses a "very famous and reliable and expansive CA product byself" - the browsers line "is green" while MitM - voila. Same happens with compromized CAs (remember i.e. the publically known Comodo hack some years ago...). Beside the fact that HTTPs even delivers no "privacy" for the users of public static web content (public web sites, focussed document archives and mailing list archives i.e.) - what leaves as "added value" for them if you BLOCK HTTP for such content - i mean value which makes the costs of energy and resources worth? > But since you're not convinced by the language of the IESG note, me > repeating it won't make you more convinced. Sorry 'bout that. Sorry if i really misunderstanded a part of (reacted mainly onto other posts in this topic). If HTTP will be available for any public ("static") part of the IETF HTTP this would be fully OK for me - even "preferring" HTTPS over HTTP by HTTP redirects or similiar while offering a "button"/link (SSL/TLS "on/off" or "by hand") or similiar options (i.e. while using relative URL's) Sorry for the noise, if so... It would be nice if the IETF would be one instance helping to develope new and transparent standards the "todays" x509 HTTPS for trust and encryption, i.e. where users can decide which "CA" / "trustee" they want to trust (and possibly which algorithms) etc.pp. and don't have to "trust" any single third party company, government or organisation and away from the todays still static view onto SSL/HTTPS "security" (the incorrect "is it secure or not" paradigm). I wrote (possibly a bit more then) "enough" now in this topic - will retract from now - sorry for the noise... best regards, 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