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

"Niels Dettenbach (Syndicat.com)" <nd@syndicat.com> Mon, 01 June 2015 21:18 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 E0E341A0011 for <ietf@ietfa.amsl.com>; Mon, 1 Jun 2015 14:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 yFzv-59baloK for <ietf@ietfa.amsl.com>; Mon, 1 Jun 2015 14:18:47 -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 CE48D1A000D for <ietf@ietf.org>; Mon, 1 Jun 2015 14:18:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=syndicat.com; s=x; h=Message-ID:To:Date:From:Subject:Content-Type:Content-Transfer-Encoding:MIME-Version:References:In-Reply-To; bh=BwsIHocZo6ES/FtnKgFdEQIeE7B0cZBYQ5JE6o8hOZQ=; b=laf4zGEMdX13Bt9ZZdLaR9FpMcy1df6DcxbYqWhX+DWDwTPDj+xRy9gvGxC5rOq093ECvu5dmI+h02QeFVU4Sr0ZgcTFa4jowIoOT1pryEaVoBMWnda9kYgHZnGZ70DKmbyxt36LCVDCW/C86eT7sT4Ad8lLUEtkMakvuCrNwsI=;
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 1YzX6b-0007RS-LU; Mon, 01 Jun 2015 23:18:45 +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 6KVRp993eQ_M; Mon, 1 Jun 2015 23:18:45 +0200 (CEST)
Received: from p50876cb7.dip0.t-ipconnect.de ([80.135.108.183] helo=android-2e6ac67d1822a7c9) by mail.syndicat.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Syndicat.com PostHamster 4.84) (envelope-from <nd@syndicat.com>) id 1YzX6b-0005hk-BU; Mon, 01 Jun 2015 23:18:45 +0200
In-Reply-To: <556CBCF5.3060402@alvestrand.no>
References: <20150601164359.29999.35343.idtracker@ietfa.amsl.com> <CAL02cgRPFooA5fVFwvdprb3wPD+Y55pD+7RWjkACDv7T_TBW5Q@mail.gmail.com> <1472054.O9DP0qoCQf@gongo> <556CBCF5.3060402@alvestrand.no>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
Subject: Re: Proposed Statement on "HTTPS everywhere for the IETF"
From: "Niels Dettenbach (Syndicat.com)" <nd@syndicat.com>
Date: Mon, 01 Jun 2015 23:18:43 +0200
To: Harald Alvestrand <harald@alvestrand.no>,ietf@ietf.org
Message-ID: <1C4D741C-89EA-4973-8536-D6A02EFD7624@syndicat.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/Q7NCNfqDerbGJeEifkBVcqwVLag>
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 21:18:49 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

>Encryption everywhere is good.
You mean  Evers public information should be encrypted? I.e. Radio vor TV? Can't see the "feature", sorry...

>Once a connection is encrypted and certificate-protectedhole class
>
>of worries can be removed from the threat models; having fewer things
>to
>worry about is great when designing protocol stacks.

This is correct by theory in many, but not all cases and not in practice.

A https geht takes up to multiple times of energy and computing resources. I prefer efficiency even in protocols - resources should be user for real (not only theoretic) added value.

Browser HTTP-SSL/TLS isn't "just encrypt and forget" as long as you really unterstand the whole infrastruture and setup in practice including their implications today - and not in theory only. This is not like and comparable with the migration from telnet to SSH and even not with SMTP TLS/SSL...

And getting a faked x509 i.e. for mitm is more a question of some money and/or third party CA securitiy and not at first of secure crypto algos or similiar.

And blocking plaintext http is no feature - it is at max a lack of...

Sorry...


best regards,

Niels.
- ---
Niels Dettenbach
Syndicat IT & Internet
http://www.syndicat.com
-----BEGIN PGP SIGNATURE-----

iQJZBAEBCABDPBxOaWVscyBEZXR0ZW5iYWNoIChTeW5kaWNhdCBJVCAmIEludGVy
bmV0KSA8bmRAc3luZGljYXQuY29tPgUCVWzMLwAKCRANu1qIRZIqRBm5D/43u9NJ
Ex2CxQwIXUcuPaPEr/2geCTgGgRBnUb46fzVwf5OlPnQqA+urr1EajpY3XRdWF5r
jmqnfS/ESYL4q3DV3CC8mW1a4uZWQX85+2fvCra8/nzyKP653jAZvSuqGZAnzGuq
ZDM33932y5GKcPLl86C7WG/QqZ7Yb6SPukTUnDY5z0DcbyBIgqAwF0D3N5P7dk49
iaZY31z1F7rI1PvPS874sH4NVnSUh1N8OakRy5tCtQn4WVlaN1WBu+bzzCmsudgw
Oh7o/BWKFGzDTNGpfsyqmzcepHsmoAPcCtbrQOadX2HFxjqzB+NJwwSLSn9koQlH
xnDhDkx0avolGa3nciubPTSJkAp1wFXj9e0zeJX8dGTOjzyJTDrDxNnYkszTnSS/
X0HnoDo3Uo638Ho9sAcweZJ3XNibNNn5ekdU9kd/rBAIHaWG1m4zshMglupJPyst
u0fvqBJi8AXznQ2Qv27CwjNWQSV37NFZcrkzg22f4GB43MJ1+utgTvEX2ft7uhrz
HJug38x8BH0vrLXpcvlKA2f6SaOCfIhCoqv4+SLVHQLE7IoG2ZxdoY4795ORGHFc
NsyfMB1ah52E3/pZjS1NhFhr4ndUQg5jp0eaLF5XhteRS2Zlw8wmYlP2qicpe3T2
S4tO7+56PhnsZQhB8GnDZMnPN9HgD9KsMNEWGg==
=5dba
-----END PGP SIGNATURE-----