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

"Roland Dobbins" <rdobbins@arbor.net> Mon, 01 June 2015 22:44 UTC

Return-Path: <rdobbins@arbor.net>
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 8C1B51A1A6C for <ietf@ietfa.amsl.com>; Mon, 1 Jun 2015 15:44:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 xYgPBTPaRW4Y for <ietf@ietfa.amsl.com>; Mon, 1 Jun 2015 15:44:25 -0700 (PDT)
Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CDD61A1A4F for <ietf@ietf.org>; Mon, 1 Jun 2015 15:44:25 -0700 (PDT)
Received: by pdjm12 with SMTP id m12so35084408pdj.3 for <ietf@ietf.org>; Mon, 01 Jun 2015 15:44:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=DszTZ1YTV8GX21GSCcx1Er4trXTI3sUwStgbi+YDocY=; b=nsNLy+PawP/y+3yJ96FfcjCQdKeLPZea7afdOTbGk3K2IuH4HsgcZUjtNb1JtsvEZX 4Y+AmYCVj/c0AaUKo21L7mL1bnid6cX0tk72MLU1QCbwbsfbjTEgKGx2FdpSvgAbub8X qLIBaDY7wSqWU23mr6eklglJoQA3v6YQRwaUs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=DszTZ1YTV8GX21GSCcx1Er4trXTI3sUwStgbi+YDocY=; b=SM+Eh98SqKZsWtdCAwKkwuMUz1+llLcP+AuBzl6yPXvu/jlOP6h/k4hFZfy2RaRpy2 NBifmj57HJ2BGJMgcjdzF9rR4F8taQyDhnraLteJhRnUOR11YOGYRFAOvd/dVAN71Wni eGguohD/pxrK0iucW/WLO48gzo1cZEA/jqMan+frfQC1UwjAtU8MarcBvvRPOBA2GFSc BH3eRBhnKPXuCwNpj+eKDSbDISEupRaLhUWqiHUhX0Vl+Gy6xK1q99rEkQViTbZLJyfQ rkrnEaB4h/eGU9TbT8B8olv9iAlhaBzHDeAF0vEk++ZD7qlvrNfdN0hOya9z9EaF50dx JYCw==
X-Gm-Message-State: ALoCoQn7Mpq/345BAks22R8Y9rPohrZm+1bz7Lq9Cv+FOSLcYF2yCY3uCZw+Q7W/FhJFjOOxpjiQ
X-Received: by 10.66.154.111 with SMTP id vn15mr43956523pab.108.1433198665066; Mon, 01 Jun 2015 15:44:25 -0700 (PDT)
Received: from [172.19.254.136] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by mx.google.com with ESMTPSA id he9sm15320684pbc.7.2015.06.01.15.44.23 for <ietf@ietf.org> (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 01 Jun 2015 15:44:24 -0700 (PDT)
From: Roland Dobbins <rdobbins@arbor.net>
To: ietf@ietf.org
Subject: Re: Proposed Statement on "HTTPS everywhere for the IETF"
Date: Tue, 02 Jun 2015 05:44:20 +0700
Message-ID: <2CD5D3F9-35B4-49C7-9254-395F51FC134E@arbor.net>
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-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.1r5084)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/0CezpIw-o7OvS9hGW9mTpW_LjF8>
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 22:44:26 -0000

On 2 Jun 2015, at 3:13, Harald Alvestrand wrote:

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

However, as noted in my previous reply, other classes of worries are 
added.

TANSTAAFL.

-----------------------------------
Roland Dobbins <rdobbins@arbor.net>