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 EDEFA1A0007 for <ietf@ietfa.amsl.com>; Mon, 1 Jun 2015 14:18:44 -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 Gl3t5PChgSlN for <ietf@ietfa.amsl.com>; Mon, 1 Jun 2015 14:18:43 -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 1DCA31A0004 for <ietf@ietf.org>; Mon, 1 Jun 2015 14:18:42 -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=gHyuNdCfTl7DSw7ALd5RnynZZlXwbGm2DvBmFfPTyl4=; b=w9leK9A500w5kDsMeo/ftTA9FO82dAak7tFsmQQ04FT5Ew4QC4IEc/IM9+gXFO2VcQjeNBVNfiWjoWfkIs0pz/SbQAgCkQ/zmvid8YvO4VGZsZpkbS3y83z0q3PjsLj2ZQgYf63XD00ULGlnZR6EKb8I9YOSzt3eePDQr/1DPRo=;
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 1YzX6X-0003Ub-MQ; Mon, 01 Jun 2015 23:18:41 +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 xWU3lenHb2fo; Mon, 1 Jun 2015 23:18:41 +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 1YzX6X-0005Vu-CN; Mon, 01 Jun 2015 23:18:41 +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:39 +0200
To: Harald Alvestrand <harald@alvestrand.no>, ietf@ietf.org
Message-ID: <BAB2B3C0-ABE6-43CB-8C33-1F930F94131C@syndicat.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/UC-cx8al0a87X4cPlGL2DqieTdo>
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:45 -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
bmV0KSA8bmRAc3luZGljYXQuY29tPgUCVWzMLAAKCRANu1qIRZIqRCI8EACgOBnR
b+bcXVnqjjyR9CiPdOpQTQ2/gie2p4ECdhaKcgFna1yn2HBUM6VXw9RZXqnGUtq6
4ItZiiK6xng3osO2xJEBM/316SG5RHX+g2mzmf8qqcI2tmp4okXrAqaxvPgTYuXW
dE5GTabG1np+qIXR3M6gG5xEqjxlsPLr0DPGc+N8XERzR/26vn84lYLhSMdtmm69
dK1jYxMOEEnQFTmkgSa/5AT07NCgmqu6lWGTp/pT8I9vaXnyFnYy79EAHB2rjj4w
5QeUrmxlIGuc6qE4dkE/hn30dQYX1sB7EMMc1AugEw/AFG9XOtp9PYMALXmCPODr
YysImmxmLi3bmOtPmGkJdnUZlCSPkRYAwqBU7Mj3216+y/BJTE+cjeoKGhOtAXK3
eG0m3XDNDY6RYkmg2fbAqsCyjVNIuEp13o70UZVJTbNKxX9WY26Rw/g0GY2Ek33O
OZkb2GvrX69YRsubPY6qr9GzoBEVBBSzaFhepsjpEo6DB1BJIuh/Ud6L5J2RMK6o
4yUoEB5PKH45Zjk2toF5kgFrEK2uEb9xgY/hB4MU1XyMBDNrWfqVNTsah9HIwxPP
4DrWwVWBzOeM+DayEa+cTV4q/5eZD5h61fvl5CtjOJACPTMbaO0s6eySqYpvanjp
DoozGagx1n568TDssO28RSDAL89hEElDjU7lkQ==
=fXAA
-----END PGP SIGNATURE-----