Re: Proposed Statement on "HTTPS everywhere for the IETF"

Niels Dettenbach <> Tue, 02 June 2015 08:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 21E831A898C for <>; Tue, 2 Jun 2015 01:40:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.711
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BfNeyvndjuwI for <>; Tue, 2 Jun 2015 01:40:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 14A9B1A8980 for <>; Tue, 2 Jun 2015 01:40:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; 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 ([] helo=localhost) by with esmtp ( PostHamster 4.84) (envelope-from <>) id 1Yzhk0-00012s-DU for; Tue, 02 Jun 2015 10:40:08 +0200
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iPNULjED88yy for <>; Tue, 2 Jun 2015 10:40:08 +0200 (CEST)
Received: from ([] helo=gongo.localnet) by with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) ( PostHamster 4.84) (envelope-from <>) id 1Yzhk0-0007VZ-4X for; Tue, 02 Jun 2015 10:40:08 +0200
From: Niels Dettenbach <>
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: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1528580.j5br1VJKTt"; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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):

> 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 Dettenbach
 Syndicat IT & Internet