Re: https at ietf.org

John C Klensin <john-ietf@jck.com> Wed, 06 November 2013 14:01 UTC

Return-Path: <john-ietf@jck.com>
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 5B1CF21E8120 for <ietf@ietfa.amsl.com>; Wed, 6 Nov 2013 06:01:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.594
X-Spam-Level:
X-Spam-Status: No, score=-103.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 I5SNMnVb+FL8 for <ietf@ietfa.amsl.com>; Wed, 6 Nov 2013 06:01:13 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 500E921E8117 for <ietf@ietf.org>; Wed, 6 Nov 2013 06:01:07 -0800 (PST)
Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1Ve3fO-000An8-CS; Wed, 06 Nov 2013 09:01:06 -0500
Date: Wed, 06 Nov 2013 09:01:05 -0500
From: John C Klensin <john-ietf@jck.com>
To: Eric Burger <eburger@standardstrack.com>, IETF-Discussion Discussion <ietf@ietf.org>
Subject: Re: https at ietf.org
Message-ID: <F90A86F78597803A1EB14DC2@JCK-EEE10>
In-Reply-To: <B3AE10BB-3A50-42A6-A7A1-E76257D9A39A@standardstrack.com>
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>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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: Wed, 06 Nov 2013 14:01:18 -0000

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