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

Harald Alvestrand <harald@alvestrand.no> Tue, 02 June 2015 06:25 UTC

Return-Path: <harald@alvestrand.no>
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 D2BAD1A1BE6 for <ietf@ietfa.amsl.com>; Mon, 1 Jun 2015 23:25:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 TYFS1wt7rE5b for <ietf@ietfa.amsl.com>; Mon, 1 Jun 2015 23:24:59 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 198CA1A6FF5 for <ietf@ietf.org>; Mon, 1 Jun 2015 23:24:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id E694A7C0536 for <ietf@ietf.org>; Tue, 2 Jun 2015 08:24:57 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIeALq6E1Fqp for <ietf@ietf.org>; Tue, 2 Jun 2015 08:24:56 +0200 (CEST)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:dcf4:5105:6293:2010]) by mork.alvestrand.no (Postfix) with ESMTPSA id 9B6137C0339 for <ietf@ietf.org>; Tue, 2 Jun 2015 08:24:56 +0200 (CEST)
Message-ID: <556D4C38.6060704@alvestrand.no>
Date: Tue, 02 Jun 2015 08:24:56 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: Proposed Statement on "HTTPS everywhere for the IETF"
References: <20150601164359.29999.35343.idtracker@ietfa.amsl.com> <CAL02cgRPFooA5fVFwvdprb3wPD+Y55pD+7RWjkACDv7T_TBW5Q@mail.gmail.com> <1472054.O9DP0qoCQf@gongo> <556CBCF5.3060402@alvestrand.no> <1C4D741C-89EA-4973-8536-D6A02EFD7624@syndicat.com>
In-Reply-To: <1C4D741C-89EA-4973-8536-D6A02EFD7624@syndicat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/1OzLVOfTbp5JCKi_U9BUDWZBBgM>
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 06:25:02 -0000

On 06/01/2015 11:18 PM, Niels Dettenbach (Syndicat.com) wrote:
> -----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...

have you looked at your cable TV lately? Or your DAB radio?
>
>> 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.

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.

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.
>
> 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...

It's more comparable with the transition from bang-path addresses to DNS 
notation, yes.
>
> 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...

Not a part of this proposal.
>
> 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-----
>