Re: https at ietf.org

Chris Inacio <inacio@cert.org> Thu, 07 November 2013 17:29 UTC

Return-Path: <inacio@cert.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B94611E8264 for <ietf@ietfa.amsl.com>; Thu, 7 Nov 2013 09:29:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.289
X-Spam-Level:
X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osOI1Bg1hSa7 for <ietf@ietfa.amsl.com>; Thu, 7 Nov 2013 09:28:58 -0800 (PST)
Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7041B11E818D for <ietf@ietf.org>; Thu, 7 Nov 2013 09:28:50 -0800 (PST)
Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id rA7HSnTs008477; Thu, 7 Nov 2013 12:28:49 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1383845329; bh=wZHnFXHqzsAh0lPTb0G96AEwFgzC0Z/W81OH5jR8DcM=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-ID:Content-Transfer-Encoding:MIME-Version: Sender:Reply-To; b=CPdtmX1DlZ/Ksd7qRDnEzH6BTJDWcWejk4jx2NNoxW3hB5fr2jBcWFLdpmen9e8l/ pKdplAFj7rs7XLVnQnLD64zkAeF+llck7WuDztUM8Qs9PLZH8akotv2IxfwjHwpeqy RfQVx4NxSKJCCnsUe5T2pYqNnuAwHO/zvLY7+QSk=
Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id rA7HSns7000882; Thu, 7 Nov 2013 12:28:49 -0500
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Thu, 7 Nov 2013 12:28:48 -0500
From: Chris Inacio <inacio@cert.org>
To: John C Klensin <john-ietf@jck.com>
Subject: Re: https at ietf.org
Thread-Topic: https at ietf.org
Thread-Index: AQHO2ogVwwpu+Gz+rUel02YqqVRNy5oXv8CAgAACwQCAAM2FgIABzFsA
Date: Thu, 07 Nov 2013 17:28:48 +0000
Message-ID: <C7ACC5D4-AFC7-427C-9AE4-C57A5CF098CC@cert.org>
References: <CAHBU6ivbrk=NXgd4_5Upik+8H0AbHRy3kJnN=8fcK+Bz3pOV9Q@mail.gmail.com> <alpine.LRH.2.01.1311051733570.4200@egate.xpasc.com> <B3AE10BB-3A50-42A6-A7A1-E76257D9A39A@standardstrack.com> <F90A86F78597803A1EB14DC2@JCK-EEE10>
In-Reply-To: <F90A86F78597803A1EB14DC2@JCK-EEE10>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.100.100]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <50E0E5130D0EF149ACDC96F78507BDFC@sei.cmu.edu>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF-Discussion Discussion <ietf@ietf.org>, Eric Burger <eburger@standardstrack.com>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 07 Nov 2013 17:29:02 -0000

+1

I don’t care about the transport to get a public document if the goal is to ensure the document hasn’t been tampered with.

Personally, I think HTTPS is a totally missing the point.

To that effect, if we’re really serious about this stuff, shouldn’t we want all email on the lists signed as well?


--
Chris Inacio
inacio@cert.org



On Nov 6, 2013, at 6:01 AM, John C Klensin <john-ietf@jck.com> wrote:

> 
> 
> --On Tuesday, 05 November, 2013 20:45 -0500 Eric Burger
> <eburger@standardstrack.com> wrote:
> 
>> Because would not someone retrieving an RFC want to know it
>> really came from the IETF, especially when it says    The
>> protocol MUST provide provisions for lawful intercept and
>> MUST post a notification when traitorous speech is detected.
>> 
>> ;-)
> 
> Eric,
> 
> I think your joke illustrates the other part of the problem.  If
> I really want to "know it really came from the IETF", then I
> want a digital signature on the document that I can verify after
> it is retrieved, regardless of the retrieval mechanism used.  
> 
> At least until and unless we (and the rest of the community)
> manage to clean up the server CA mess --including both killing
> off the CAs with bad behavior patterns and making sure that all
> HTTPS clients do really careful cert validation-- https may give
> me a warm and fuzzy feeling, but it doesn't guarantee document
> authorship and integrity.    Worse, part of the problem today if
> that, if those HTTPS-related tools work well, there is some
> history of false negatives (e.g., letting certs expire) that
> keep people from getting to documents for no good reason.
> 
> I believe in eating our own dogfood, but think an appeal to that
> principle requires careful attention to whether the food is
> suitable for purpose and safe and nutritious for canine
> consumption.  In today's environment, claims about HTTPS for
> document authenticity and/or integrity fail that test.
> 
> I strongly defend keeping HTTPS available for those who want it,
> but oppose getting rid of it to punish those who have reasons to
> not use it.
> 
>     john
>