Re: Call for Adoption: Expect-CT

"Roy T. Fielding" <fielding@gbiv.com> Fri, 09 December 2016 20:16 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 903A41293E1 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 9 Dec 2016 12:16:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.897
X-Spam-Level:
X-Spam-Status: No, score=-9.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gbiv.com
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 zvoBbsnHq9B6 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 9 Dec 2016 12:16:21 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9F99127076 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 9 Dec 2016 12:16:21 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cFRYL-0000rW-QW for ietf-http-wg-dist@listhub.w3.org; Fri, 09 Dec 2016 20:13:57 +0000
Resent-Date: Fri, 09 Dec 2016 20:13:57 +0000
Resent-Message-Id: <E1cFRYL-0000rW-QW@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <fielding@gbiv.com>) id 1cFRYC-0000oL-QJ for ietf-http-wg@listhub.w3.org; Fri, 09 Dec 2016 20:13:48 +0000
Received: from sub5.mail.dreamhost.com ([208.113.200.129] helo=homiemail-a94.g.dreamhost.com) by titan.w3.org with esmtps (TLS1.1:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from <fielding@gbiv.com>) id 1cFRY6-0007Yl-0U for ietf-http-wg@w3.org; Fri, 09 Dec 2016 20:13:43 +0000
Received: from homiemail-a94.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a94.g.dreamhost.com (Postfix) with ESMTP id 418F2801970B; Fri, 9 Dec 2016 12:13:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=52Q8wpGogeB01Ek6dBq1V98obYg=; b=LgW5lP2WGJqNPRT26H0XyZSkxuKf YiJSM/y1nHZOH1CcB05MbqoDbQ56esrieIDEApPrzQzRICuzlBTvkcy3hNB2bPj2 qXOZQWDKNcIlaUj9MN5O1VKcBCyGX/+8azkyb+rH1tinoJHlF060TUQSszzKUAqi Vkbbhlq2u8m/+/g=
Received: from [192.168.1.3] (ip68-228-71-159.oc.oc.cox.net [68.228.71.159]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a94.g.dreamhost.com (Postfix) with ESMTPSA id 289818019638; Fri, 9 Dec 2016 12:13:16 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: "Roy T. Fielding" <fielding@gbiv.com>
In-Reply-To: <6B6FE4E1-D020-44B1-9F45-07202552E606@mnot.net>
Date: Fri, 09 Dec 2016 12:13:15 -0800
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Patrick McManus <mcmanus@ducksong.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <972514F9-6237-4420-97AB-000655A0662E@gbiv.com>
References: <6B6FE4E1-D020-44B1-9F45-07202552E606@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
X-Mailer: Apple Mail (2.2104)
Received-SPF: none client-ip=208.113.200.129; envelope-from=fielding@gbiv.com; helo=homiemail-a94.g.dreamhost.com
X-W3C-Hub-Spam-Status: No, score=-7.8
X-W3C-Hub-Spam-Report: AWL=1.196, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, URIBL_BLOCKED=0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1cFRY6-0007Yl-0U e092ff4e2203ba0355190bbdc4c6a224
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Call for Adoption: Expect-CT
Archived-At: <http://www.w3.org/mid/972514F9-6237-4420-97AB-000655A0662E@gbiv.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33147
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

> On Dec 7, 2016, at 8:05 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 
> Again, there seemed to be strong support in Seoul, and now on the list, for adopting this draft:
> 
> <https://tools.ietf.org/html/draft-stark-expect-ct>
> 
> Please comment / express support on list.

I don't have a problem with someone at IETF working on a solution to the
problem, but I have serious issues with this draft as it currently stands:

 1) It effectively adds a binary TLS control option in the form of a
    verbose HTTP response header field to be sent in ALL https responses.
    That doesn't make any sense, on so many levels.

    a) it's a layer violation (wrong code parses it);
    b) it's incredibly inefficient to send the information every time
       when it only needs to be received once;
    c) it's processing is in the critical path of response handling
       even though the information is only useful for "future connections"
       (and ignored by all non-implementators);
    d) the same control might be desirable for non-HTTP uses of TLS.

 2) The header field is poorly named (see Expect), doesn't limit itself to
    responses (aside from having no definition for other contexts), and has
    a field value syntax matching that of Set-Cookie (FFS).

Why is this not a TLS option, preferably signaled by an attribute of the
certificate itself?  The other information could be supplied at a well-known
location or by reference to a third-party reporting mechanism.

What is the justification for sending this information in HTTP response
header fields when it is independent of the current response and only
useful for later connections?  As a general design rule, we use links
for that.

I know HTTP is "comparatively easy" when it comes to adding all sorts
of fun options, but does this extension justify its own cost?  Why can't
it be accomplished via the certificate management mechanism, entirely
outside the scope of this working group?

....Roy